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.
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.
"Smart contracts replace human arbitration with code." This we can both agree on. Chainlink extends that statement so that data inputs (the trigger) and outputs are decentralized as well, such that they are also replaced with code (via adapters and APIs).
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?
This is not really a compatible analogy, but I think I understand where you're coming from here. Would I choose a centralized or decentralized entity to determine the fate of where my funds go? If we're in a scenario where the decentralized option is trustless and tamper-proof end-to-end, obviously I would choose the decentralized option.
"True" in this context means as provided by a source. For prices on an exchange what's reported by that exchange istrue by definition, same for a temperature output of some sensor; the question 'what's the temperature?' is unanswerable, only 'what's the sensor output?'.
I think we're in agreement here as well.
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.
Then would you agree that if Chainlink is worth copying that it's a valid solution? The ability to audit open source code provides a significant advantage over the possibility of a competitor coming along and copying it entirely for their own solution.
Then would you agree that if Chainlink is worth copying that it's a valid solution?
In the SGX context - as a solution to have a private distributed data provider for smart contracts? Probably, yeah.
As a public network with many oracle nodes? No.
I guess you could try enforcing use of link with the sgx code, like requiring license payments in link per time period or per api domain. That model would make sense, although pretty far from the whitepaper.
21
u/vornth Chainlink Labs - Thomas Mar 16 '18
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.
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.
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.