> For one, Ethereum is unable to access real time data from outside the blockchain. Developers need to rely on trusted third party data providers, called oracles, to provide smart contracts with outside information like weather, random numbers, or currency values.
I feel like this is more of a feature than a bug. If you're weaving applications into the blockchain, would it really be wise to have that chain communicate with abstract data off of the chain itself? Seems an unnecessary burden for the chain to bare!
Great article. I've recently gotten into Ethereum Dev and Solidity. It's really fun, fun stuff. This isn't directly addressed in the Ethereum portion of the article, but it's good to keep in mind that these things are all works in progress. Limitations today are non-such tomorrow; we don't quite know where the train is headed.
You, Developer, can help it get to wherever you feel it needs to go. Remember that before deciding not to contribute. :)
What I don't understand is how Ethereum can describe their dapps as "trustless" when all the trust is still centralized in an oracle. This can even happen accidentally, such as with the Mayweather/McGregor smart contract breakage. [0]
But now imagine if BoxRec had intentionally reported false results from their website in order to make a lot of money on the bet. People would lose their money, and there would be no recourse.
Plus, it's not like bribing oracles is unheard of. Herodotus, who lived 2500 years ago, already reports instances of bribery affecting the predictions of the Oracle at Delphi: https://archive.org/stream/jstor-3287085/3287085_djvu.txt
A lot of dapps don't need oracles to run. Anything that does is still more trustless than a centralized solution would be, reducing the counterparty risk to the oracle alone.
As mentioned elsewhere, a lot of work is also being done on decentralizing the oracles. Like PoW / PoS protection, this raises the cost of an oracle attack high enough to reduce the risk to acceptable levels for more sensitive applications.
If your code doesn't reach out beyond the blockchain, then there's very little it can actually do. You are limited to twiddling balances of coins. This turns out to be great for making casinos and ponzi schemes, but little else.
To do anything more meaningful, code needs to interact with the real world. And this is generally the point at which blockchain apps lose all of their purported benefits, like decentralization, immutability, reliability and so on.
> If your code doesn't reach out beyond the blockchain, then there's very little it can actually do.
Asset issuance, voting, wills, identity/reputation systems, land registries.
Fundamentally, a blockchain is just public, transparent immutable data history. Of the above sample cases, all it takes is for the powers to be to recognize the data as a reflection of the real world; which is a barrier outside of the technology.
And sidenote, decentralized oracles will literally tie outside world to the blockchain.
Asset issuance, voting, wills, identity/reputation systems, land registries.
All of which reach beyond the blockchain. No-one is going to care that a 'smart contract' says that Alice owns a plot of land when Bob holds the real-world deeds.
The real world and the blockchain can only be linked when, as you say, 'the powers that be' decide to recognise the data. But then you've lost all of the advantages that the blockchain was claimed to possess. For example, if we need an entity to recognise that the land registry smart contract is valid, there's no more decentralization, and we might as well let that entity store the land registry in their own simple database. The blockchain becomes pointless and wasteful.
> But then you've lost all of the advantages that the blockchain was claimed to possess.
That's a very wide brush stroke to paint. You just have to analyze each use case independently.
In the same example of land registry, just a transparent history is a huge value add when dealing with corrupt government officials. Here's a case study https://s3.amazonaws.com/ipri2016/casestudy_collindres.pdf . Voting transparency even with the government as the part of centralization is a huge value add imo.
Further, even allowing centralization in certain points, like a SpaceX IPO (which should def be centralized), allows whoever holds a share to make arbitrary, trustless mediums and rules of exchange.
How does the blockchain ensure that I can both verify that my vote was counted but can't sell my vote? https://youtu.be/BYRTvoZ3Rho describes one electronic voting system that's supposed to have those important properties, even though I don't fully all the details yet.
Depends on the specific implementation. Just because you do it on a blockchain doesn't mean you can't require people to show up to a polling center and sign transactions in person.
With Ethereum, one way to do it is to make the voting weight non-transferable, meaning to give someone else your vote you'd need to give your private key.
It would be of course crazy to do that; like giving someone your bank card and PIN number to give them cash.
> Several data providers respond to this service agreement with a bid in the form of a data reply — when enough data providers have responded, the majority response is taken (or average depending on the request), outliers are removed, and data is fed into the contract.
What's to stop me from setting up 10,000 different data providers that initially provide good data to get a good reputation score, but then slowly corrupt them over time? It doesn't matter how many data providers you average if I can set up millions of them in seconds. I don't see any way to solve Sybil attacks here.
Bingo. Most cryptocurrencies/contracts/anything in the field/realm -- they don't attack the problem of "person" vs address/wallet/account. ChainLink might think they are clever but like you said..when accounts in your network are free, then don't expect any kind of consensus to work. Accounts or rather, more abstractly, entry into your network -- needs to cost something that can't be easily done to gain majority. Another way to attack the issue is to do antes..so accounts dont cost anything unless the account holder is caught doing something bad -- ie. every entry requires a refundable collateral.
One thing that these networks don't seem to protect well against are fake peers that request data but dont provide it. These currencies and coins have been lucky in that regard and have prevented some of it by seeding their own trusted peers as the initial peer neighborhood. But is this true decentralization? Seems a bit obtuse. To add to the baffle, IPFS started using bitcoin and ethereum for storing the initial peer data for new clients to connect to. Its a web... maybe thats ok. Are things allowed to be this tangled? ;-)
In 2014, the IPFS protocol took advantage of the Bitcoin blockchain protocol and network infrastructure in order to store unalterable data, remove duplicated files across the network, and obtain address information for accessing storage nodes to search for files in the network.
Ah, thanks - you're half right :) The plan for Filecoin was initially (in 2014) to be based on Bitcoin, but since then this changed to its own Proof-of-Replication and Proof-of-Spacetime, reusing parts of Ethereum.
IPFS itself has never had any cryptocurrency integration, although there are external services that store your data on their IPFS nodes in exchange for Bitcoin.
There's a penalty payment that each node puts up into escrow for each assignment of data, and if the data is not accurate in relation to all the other providers of that same data, the node will lose the payment.
There will also likely be a small amount fo LINK required to start a node with enough reputation to gain assignments which would also increase the cost of a Sybil attack.
> There's a penalty payment that each node puts up into escrow for each assignment of data, and if the data is not accurate in relation to all the other providers of that same data, the node will lose the payment.
So, a prisoner's dilemma situation here? If one person objects, everyone loses their money? Who gets the payment? Are the coins permanently burned? If so, seems harsh in the face of accidents. If not, seems open to abuse if someone could be both the smart contract creator and a data provider. I create 100 data providers, and a smart contract, and when I detect someone new has joined my pool, cause them to lose their coins which are sent to me.
> There will also likely be a small amount of LINK required to start a node with enough reputation to gain assignments which would also increase the cost of a Sybil attack.
Ah, so an economic majority that successfully scams others and acquires a mass of tokens can use them to launch more data providers.
Mmm, what would stop me from just grabbing the data the other oracles made available, and pretending I did the actual calculation/check/api-call/whatever?
So the oracle is incentivized to tell the truth because lying will hurt the value of their tokens? What happens when someone offers them more than their tokens are worth if they lie?
Imagine a blockchain operated by a consortium of five companies. There are also second-grade members in the pool.
For the sake of example, imagine this is a market that is being used to trade fishing rights for a region off Iceland.
Each of the five has a holding of Consortium Coin on this chain. This give them voting power in any decisions that have to be made of the chain. None of the second-grade members have any Consortium Coin.
The second-grade members trade in Fish Coin and Boat Coin.
Each of the five operates an oracle feeding to the consortium. It provides fisheries stocking data, and records of dock inspections of member boats. Each piece of incoming oracle data is signed to indicate that it is backed by the Consortium Coin holdings of the operator (proof-of-stake).
A simple election/raft algorithm decides that Oracle advice is true once it passes a threshold of so-much Consortium Coin.
There are contracts signed in western countries where the five firms are listed. These contracts say - essentially - that they will operate in good faith on the chain. (If they did not, they could be sued in the usual way).
There is a direct line out of this chain into the regulator, who runs analysis algorithms against the reported behaviour, and compares that to their independent mechanisms.
Bribery could still exist off-chain. But that is not new, and we do alright at protecting against that through current systems of governance. In this scenario, the thing your proof of stake is protecting against is a non-consortium blockchain member setting up a rogue oracle.
Why is this valuable? If ppl get the model right, you can run sophisticated markets like this without any civil servants being involved. It may turn out to be policy-wonk heaven. You can cut the size of the civil service, and yet have much more nuanced regulation, and better game-theory for operating markets.
Next: a social network going where people indicate trust of one another, and act as semi-guarantors for people they have vouched for.
Next: operate sections of the legal and judicial system over the chain.
Human actions captured on a cheap, secure, distributed ledger.
(I'm explaining the dream here. If I knew what I was talking about, I would have done it.)
If the blockchain community gets the contract/language issues sorted out, a small dev team could knock out a first-stage system like the fisheries system in three months and in two layers of technology (contracts, oracles). It would be trivial to operate and resilient to server failure (less-so the oracles). Ten years later, it would still be just the same two layers of code.
In this world, contracts make custom APIs obsolete. There is a new career path for a developer who lives and breathes async contract code.
The way of implementing such a system now is db-centric. Business problems tend to be event-driven, but databases are not. So we need many more layers of technology: ERD, stored procedures, 'backend', partner API, hosting complexity, business continuity complexity, further layers to assist support and deployment and API onboarding.
The database company takes on a life of its own, it is expensive to fund and delivers a bad customer experience.
So the thing that blockchain adds: you will able to reliably build significant systems with two-person teams in domains where we currently struggle to do adequate work with firms of twenty or forty people. We will be able to engage with more complex domains than we can at the moment, and there will be network effects from this.
So it sounds like what you really want is a better centralized database that has those properties, rather than a slow, energy-inefficient ledger providing features you don't need like reward tokens, mining, and decentralization.
You don't have mining in proof-of-stake. (Mining is for proof-of-work.)
My focus is multiple-host, centralised async systems. I think this is the future, and that databases will be marginalised. Comment here elsewhere gives more details.
I may turn out to be wrong. In that case, we will end up in the kind of blockchain world described in my earlier comments. I suspect it will hinge on whether it is possible to create a good-enough high-level language.
Verifiable oracles are extremely hard to create. In fact I think that the creation of verifiable oracles is the single biggest challenge facing science and engineering. Full disclosure, I am quite biased about this since part of my PhD work is to create a language to specify measurement processes.
How do you know whether the numbers you are getting reflect something about the real world? How do you know that your data hasn't been tampered with intentionally or unintentionally?
Data provenance is extremely difficult, and that is only half the problem. The other half of the problem is determining whether you have actually measured what you think you have measured. (Note: there may be some additional halves lurking around as well.)
To give some concrete examples. You find a picture of a CEO groping someone, how do you know whether it is real? Does it matter if you want to short the stock of the company, given that you know that other people will not verify it? What if the photographer's camera automatically pushed a stream of hashes of sensor contents and GPS locations to a source with a verifiable timestamp?
How about the equivalent for a microscope sensor to ensure that the raw data from the sensor was verifiable, and that all transformations of that data needed to be published in a form that would allow anyone to verify that the raw data could be transformed to the final data?
How about a contract that specifies that if a freezer temperature rises above X degrees C for more than 3 minutes then the freezer owner must pay Y dollars to the owners of the contents of the freezer. What does it take to build sensors that the owner of the freezer would trust enough to enter into such a contract?
tl;dr Verifiability of data from oracles is extremely difficult, and much a bigger challenge than building a blockchain that could make use of it. GIGO will be a big stumbling block.
Maybe I'm just dumb, but is this a bigger problem than it is offchain? Data is forged all the time, we have fake news, people lie, people are jailed with false accusations.
If the owner of the fridge in your example eventually discovers that the sensor has been tampered with, s/he can get the money back using the judicial system offchain, maybe reflected in some inchain contract.
Answering to my own initial question, the speed of the system could make a difference. An automated way to scam people with an oracle could make it easier to get the money and disappear.
The major difference is that offchain we use contracts verified (and written to be verified) by humans. For a fridge that might mean that you need to send photo evidence and have a mechanic look at the fridge. In case of disagreement a human court will decide the outcome. It's not always going to get it right, but it's a lot harder to scam systematically. For smart contracts to bring the value of machine verified contracts without human intervention we need the data provided to the system to be verified. Without verification that all parties agree on we will always need human intervention in case of a dispute.
If you anyway assume a legal system to resolve issues, then just go for traditional contracts and money transactions. Why then bother with blockchain-based contracts in the first place?
I took this as a point of explaining what Oracles are/do. Too often Ethereum proponents skip talking about Oracles when it comes to discussing attack vectors on Eth smart contracts.
> Developers need to rely on trusted third party data providers, called oracles
It's ironic that they mention Augur by name in the article, but are apparently unaware its main innovation is the decentralized oracle that just so happens to have a prediction market built on top of it.
> I feel like this is more of a feature than a bug.
That is indeed 100% by design. All smart contract code in Ethereum has to be deterministic to guarantee computational consensus, and of course this can only be done by having a closed EVM.
I feel like this is more of a feature than a bug. If you're weaving applications into the blockchain, would it really be wise to have that chain communicate with abstract data off of the chain itself? Seems an unnecessary burden for the chain to bare!
Great article. I've recently gotten into Ethereum Dev and Solidity. It's really fun, fun stuff. This isn't directly addressed in the Ethereum portion of the article, but it's good to keep in mind that these things are all works in progress. Limitations today are non-such tomorrow; we don't quite know where the train is headed.
You, Developer, can help it get to wherever you feel it needs to go. Remember that before deciding not to contribute. :)