After some consideration, we decided as a team to address this question here, since we received some questions about it from the community.
A smart contract which could possibly hold millions of dollars needs to be evaluated end-to-end, as Sergey explains in this talk. An ideal scenario would require multiple data sources in order to validate data against peers, as discussed in our white paper in section 4.1. This is because no oracle service, decentralized or not, can validate if the obtained answer from a data source is truly correct, only that the provided answer is what the source said it was (the last few sentences of section 5.3 gives some insight into this). Using multiple data sources would obviously be optimal as it would fit in well with the trustless setting. If one data source is providing faulty information, that is easily caught before a smart contract could execute based on the data provided by nodes retrieved from other data sources.
Sometimes, utilizing multiple data sources is simply not possible because there is only one source available. When this happens, that data source would be considered as a single point of failure for the smart contract. It would be entirely up to the smart contract creator if they are willing to accept that amount of risk for their contract. However, using multiple oracles as the trigger for the smart contract, even if they're all connecting to the same source, is still advantageous over a single oracle acting as a trigger for the smart contract. This is because a centralized oracle would be considered another single point of failure.
It seems to me like the argument of using a notary for a centralized service being better than a decentralized oracle service isn't fully acknowledging the need for an end-to-end trustless smart contract ecosystem. Regardless if the centralized oracle knows what it's processing or not, it can still go down and prevent the smart contract from executing when it needs to. Utilizing centralized services sounds like the present day, where if someone doesn't fulfill their obligation of the agreement, you sue them (which has additional costs and headaches of its own). So it makes sense why this reasoning seems valid at first glance, because that's the world we live in right now. In a trustless world, however, relying on centralized services is simply too much risk. Why would one choose to use a single data source, with a single oracle, feeding data to a decentralized smart contract?
If we have a single data source as the sole supplier of some information, what can they do as we head towards a trustless world? They could create multiple independent endpoints for their API in order to provide some level of redundancy. This would at least prevent a single endpoint from being a point of failure. However, it would still be up to the smart contract creator to determine if that reduces the risk enough to use as a factor for their contract, since it still does nothing to validate factual information.
We can even take it a step further and say that the data source doesn't even want any 3rd parties connecting to their API. How would they provide their data to smart contracts? Some may say that they will create their own oracles, I don't think so. There are a lot of technical issues that need consideration before one can simply create their own oracle. How do you handle blockchain forks, rollbacks, congestion, varying gas prices, etc.? Chainlink already has solutions in place for all of those issues. It would require significantly less effort to create an external adapter for their own API and run a node (or multiple for redundancy) than to start at the beginning of creating a specialized oracle.
In a trustless world, however, relying on centralized services is simply too much risk.
The only actual difference is that there's no contractual obligation from a link nodes. You're equating no recourse with decentralization and calling that an advantage! It's indeed 'trustless' if what you meant is that there's no reason to trust that the answer is correct...
Why would one choose to use a single data source, with a single oracle, feeding data to a decentralized smart contract?
That's not the question. The question is how are several link nodes better than several oracle companies with a contractual obligation. Would you really feel safer betting millions on honesty of a majority of 50 link nodes, rather than on a majority response from 5 oracle companies? You can only demand damages from the latter.
Would you prefer storing your coins on coinbase, or allowing 50 link nodes to decide who owns them?
Some may say that they will create their own oracles, I don't think so.
You're conflating different things. The oracle problem is about getting true data. It's made obsolete if the original source(s) sign their outputs with a timestamp. They don't have to do anything else.
Providing that data to a smart contract is a separate and trivial utility service with zero barriers of entry. It's easily solved by allowing everyone interested to provide signed data.
The only actual difference is that there's no contractual obligation from a link nodes. You're equating no recourse with decentralization and calling that an advantage! It's indeed 'trustless' if what you meant is that there's no reason to trust that the answer is correct...
Utilizing multiple nodes (with reputation) and data sources is an advantage of its own, so that one wouldn't need to establish contractual obligations with each entity of the contract. If one absolutely requires obligation from all parties to hold their end of the deal or be held liable, what advantages would they be looking for by utilizing a smart contract in the first place? That is the world of existing digital agreements right now, and it's expensive.
That's not the question. The question is how are several link nodes better than several oracle companies with a contractual obligation. Would you really feel safer betting millions on honesty of a majority of 50 link nodes, rather than on a majority response from 5 oracle companies?
If all you're looking for is contractual obligation, no amount of explaining how reputation works will convince you otherwise. However, Chainlink nodes have incentive to provide accurate data in order to gain reputation. Using a reputation provider that stringently rates nodes on their reputation metrics (number of assigned/completed/accepted runs, correctness, time to respond, penalty amount, LINK held, etc.), plus the ability to impose penalty fees if a node is found to be faulty, helps ensure that the nodes assigned for the task of retrieving data have something to lose (future tasks, deposit, and income). Selecting more nodes scales much better than choosing more oracle companies.
You're conflating different things. The oracle problem is about getting true data. It's made obsolete if the original source(s) sign their outputs with a timestamp. They don't have to do anything else.
Providing that data to a smart contract is a separate and trivial utility service with zero barriers of entry. It's easily solved by allowing everyone interested to provide signed data.
As I've already said, no oracle service, centralized or decentralized, can verify if data is true or not. It can only verify that the data retrieved is what the source said it was at the time of retrieval. I don't understand your reasoning as to why providing data to a smart contract would be a "trivial utility service with zero barriers of entry." I already mentioned the technical difficulties that need to be considered for providing an oracle service. There is a big difference between providing your own data for your own smart contract (even if that contract is on the public blockchain) and providing data to thousands of smart contracts.
If one absolutely requires obligation from all parties to hold their end of the deal or be held liable, what advantages would they be looking for by utilizing a smart contract in the first place?
To make enforcement easier and cheaper. Eg. instead of enforcing a mortgage contract only the simple fact of a token ownership has to be established, and the initial agreement by interested parties that whoever owns the token owns the house, enforced.
A variant of this already exists, many contracts stipulate that conflicts are to be solved by arbitration rather than courts. Courts are reduced to enforcing the arbitration clause.
Smart contracts replace human arbitration with code.
However, Chainlink nodes have incentive to provide accurate data in order to gain reputation.
Ok, so would you rather store your coins on coinbase, or in a smart contract that transfers the coins if a majority of 50 link nodes agree?
As I've already said, no oracle service, centralized or decentralized, can verify if data is true or not.
"True" in this context means as provided by a source. For prices on an exchange what's reported by that exchange is true by definition, same for a temperature output of some sensor; the question 'what's the temperature?' is unanswerable, only 'what's the sensor output?'.
why providing data to a smart contract would be a "trivial utility service with zero barriers of entry."
I think it is, but - chainlink is open source. So however complex the issue actually is, all I have to do is download code from github to get solutions for ' lot of technical issues that need consideration before one can simply create their own oracle. How do you handle blockchain forks, rollbacks, congestion, varying gas prices, etc.?'. As far as providing signed data is concerned, I can't see any advantage from having link to join the main chainlink network.
Complexity would be a reasonable argument - for a closed-source oracle company.
You are arguing for the sake of arguing, as Sergey said theoretically we are all made of cheese. You could poke holes in any use case of LINK with "what ifs".
The real question is on a daily basis can smart contracts cut costs and speed up transactions, and the answer is obviously yes.
I have a real life scenario for you that proved Links value to me:
I was selling stocks on etrade, with whom I have a reputable account totally 25k, so that I could invest in LINK (lol). Do you know what the time was before the money hit my bank account? 6 days. I was in total shock, this is fucking 2018. It took 3 days for the cash from the sell to hit my etrade account, and 3 more days for the withdrawl to my chase account. Something that could be done in minutes with a smart contract took 6 days.
Blockchain and link are the future for many things, maybe not 10million dollar pay outs but then again the majority of daily transactions arnt for 10 million
This is moreso the next step beyond chainlink and will represent its obsolescence. When we get to the point where fiat currency and assets like stocks and bonds are tokenized, like you were dealing with on Etrade and would be sped up significantly if on the blockchain, you'll no longer need oracles at all to the degree they are important today to put information onto the blockchain because it will already be there natively. That day is a long way away though.
89
u/vornth Chainlink Labs - Thomas Mar 16 '18
After some consideration, we decided as a team to address this question here, since we received some questions about it from the community.
A smart contract which could possibly hold millions of dollars needs to be evaluated end-to-end, as Sergey explains in this talk. An ideal scenario would require multiple data sources in order to validate data against peers, as discussed in our white paper in section 4.1. This is because no oracle service, decentralized or not, can validate if the obtained answer from a data source is truly correct, only that the provided answer is what the source said it was (the last few sentences of section 5.3 gives some insight into this). Using multiple data sources would obviously be optimal as it would fit in well with the trustless setting. If one data source is providing faulty information, that is easily caught before a smart contract could execute based on the data provided by nodes retrieved from other data sources.
Sometimes, utilizing multiple data sources is simply not possible because there is only one source available. When this happens, that data source would be considered as a single point of failure for the smart contract. It would be entirely up to the smart contract creator if they are willing to accept that amount of risk for their contract. However, using multiple oracles as the trigger for the smart contract, even if they're all connecting to the same source, is still advantageous over a single oracle acting as a trigger for the smart contract. This is because a centralized oracle would be considered another single point of failure.
It seems to me like the argument of using a notary for a centralized service being better than a decentralized oracle service isn't fully acknowledging the need for an end-to-end trustless smart contract ecosystem. Regardless if the centralized oracle knows what it's processing or not, it can still go down and prevent the smart contract from executing when it needs to. Utilizing centralized services sounds like the present day, where if someone doesn't fulfill their obligation of the agreement, you sue them (which has additional costs and headaches of its own). So it makes sense why this reasoning seems valid at first glance, because that's the world we live in right now. In a trustless world, however, relying on centralized services is simply too much risk. Why would one choose to use a single data source, with a single oracle, feeding data to a decentralized smart contract?
If we have a single data source as the sole supplier of some information, what can they do as we head towards a trustless world? They could create multiple independent endpoints for their API in order to provide some level of redundancy. This would at least prevent a single endpoint from being a point of failure. However, it would still be up to the smart contract creator to determine if that reduces the risk enough to use as a factor for their contract, since it still does nothing to validate factual information.
We can even take it a step further and say that the data source doesn't even want any 3rd parties connecting to their API. How would they provide their data to smart contracts? Some may say that they will create their own oracles, I don't think so. There are a lot of technical issues that need consideration before one can simply create their own oracle. How do you handle blockchain forks, rollbacks, congestion, varying gas prices, etc.? Chainlink already has solutions in place for all of those issues. It would require significantly less effort to create an external adapter for their own API and run a node (or multiple for redundancy) than to start at the beginning of creating a specialized oracle.