Subjectivity, Ambiguity, and Decentralized Oracles
In an instant, hacks of financial protocols, or misunderstandings of the internal workings of a financial contract can lead to huge losses with often little recourse. Whether it’s traditional financial products that settled to LIBOR, traders who saw Crude go negative for the first time in history this year[1], or a derivatives contract that liquidates unsuspecting hedgers, settlement price or oracle manipulation has been a thing since long before Vitalik and flash loans.
How your oracle is structured and the data you’re retrieving are crucial specifications when creating a robust financial product. The seemingly straightforward question of “what price do you use?” is anything but. The nuance involved in selecting the correct definition of what truth is with regard to your input has security implications which will affect every aspect of your product.
The oracle non-problem
When placing a settlement price on a blockchain, you have two components:
– How to get it on-chain
– What to get on-chain
You see, oracles aren’t as strictly defined as blockchains. Rather, oracles relating to off-chain information are a social decision on a state not tied to consensus of the blockchain. To unpack this:
a) Truth is subjective. What a group of people agree upon (in a purely digital context) is the truth. How we arrive at this truth is some codified way to achieve “social consensus” (the subjective, agreed upon truth)
b) Layer 1 is social consensus.
c) Layer 1 consensus is only on a very specific set of opcodes and actions.
d) All actions on-chain must either be codified in Layer 1 instructions or have their own social consensus (e.g. a contract with an admin key is a specified form of authoritarian governance)
e) Oracles place data on-chain whose validity is not handled by the layer 1 consensus mechanism. Therefore, oracles must also have a human, social, or consensus element.
Oracles represent an interesting problem as they try to provide information relating to the occurrence of an event or the state of some system that is not native to the chain itself. Whereas a layer 1 consensus mechanism is strictly defined with certain operations and points of contention, oracle systems seek to extend the capabilities of the chain to arbitrary information not agreed upon by the base validators. The most common use case currently relates to the pricing of cryptocurrencies on centralized exchanges, followed by the events happening on other blockchains (blockheaders, data availability, etc.). Although it may seem straightforward to say what happened or what the state of some outside event is, the truth is that reality may be more subjective than proponents of codified solutions may like to admit.
What is a Price?
When protocols are choosing an oracle, they are choosing the social consensus mechanism to determine the accuracy of an input. For a given oracle design, you not only have differing thoughts on how to validate a given input, you have differing thoughts on what that input even is.
There’s a difference between the price of Bitcoin, the price of Bitcoin on Coinbase, the price of Bitcoin according to Coinbase’s API, and the price at which I can currently buy an entire Bitcoin on Coinbase.
Definitions matter.
Choosing the input (the price feed in this case) determines what your validators will be basing the accuracy upon. Tellor has a great article on settlement prices, but that’s an issue that isn’t limited to defi or blockchain, and has a robust literature of best practices.
Many oracle solutions are simply technology that grabs from an API or works to trustlessly bring information from that API on-chain. This is a great tool for builders or MVPs, but it’s not a complete oracle solution.
If you assume that the price from the API is always correct, you put complete trust in the operator of this price feed. The manipulability of these prices or the honesty / censorship resistance of the exchange’s API should be serious concerns for any project. The truth is that the transparency of the “read directly from an API” toolkit is also its downfall.
The security of the unknown
Knowing the rules of the game is important, but there are always unforeseen consequences when complex systems attempt to map out every potential scenario. As any developer whose software has failed in production can attest, code is hard to get right.
But it’s not just code, it’s laws and regulations in general.
This is a known problem in governance. If you try to write out what happens in every case, you get people finding loopholes and ways to get around the law. This is why we have judges and juries in the real world that come up with custom punishments on nuanced decisions. Specific rules for every situation is impossible and how we translate this principle to the digital universe is tough.
Protocol formalization is the idea that code requires no human input and doesn’t change. As we know from experience though, this leads to rigidity, unforeseen edge cases, and often an abandonment of the protocol as the narrative around its use case may need to change if the code does not. The ability of a community to respond to unspecified issues that may arise is critical for a system to actually solve a problem over time. How a community does this is where the social consensus arises.
This goes back to the principles of blockchain. Is blockchain “code is law” or is it a “community consensus”. Is it a way for communities to agree upon the truth or a mindless piece of code that operates much like a calculator would?
Oracle Manipulation
If you know the rules and can game the system without punishment, then the rules will be broken. Although transparency is desired, the exactness with regard to the derivation of the data is actually a bug in this scenario.
The idea that legalistic specifications are not necessary is something most take for granted. Even if it’s not specified in your rental agreement, if the roof blows away in a hurricane, your landlord is responsible to fix it in a timely fashion. Societies have laws preventing very general things (e.g. reckless driving, disorderly conduct, etc.); we don’t require an if/else statement for every scenario. If a person we trust (e.g. a police officer) sees you doing something stupid, they can put a stop to it. You don’t need to write out in the law that shooting a crossbow while riding a unicycle is illegal; we have ways to just use common sense.
Smart contracts work differently though. Parties who use too specific an oracle (the single API signer or even the Uniswap price), are subject to a higher risk of manipulation. We’ve seen several hacks happen where the oracle brings the data on chain correctly, but there are unforeseen consequences regarding that price as it has been manipulated. The community in these cases has no recourse. You’re stuck with what the code gave you and most of the time that means someone loses money. Trustlessly getting a feed doesn’t tell you that it’s correct with regard to a consensus of exchanges or a community and it can’t protect you if someone even finds a way to throw the price with regard to that data source.[2]
Despite the calls for “code as law” or the pain of working with communities and other protocols, you don’t want an oracle that is simply a piece of code. In the same way Ethereum or Bitcoin forks / reverts if the consensus protocol is attacked, a complete oracle should have flexibility in the case of an attack. You can have a form of community agreement (or a trial in very specific cases) around what is a good price. If the Coinbase API goes down, don’t use it. If a new source of liquidity pops up, make sure to include it. It’s not rocket science, but it is a manual process; one that will take time to get right, but one that isn’t limited by its own scope.
Tellor Community Social Consensus
Tellor provides a way to agree upon truth. The Tellor oracle is not some magical cryptographic technique for monitoring the outside world and relaying it to Ethereum. It’s a network of individual participants who are crypto-economically incentivized to report and validate accurate data.
It’s been well recognized there’s no solution to the “oracle problem”, but oftentimes this is to handwave over the difficult tradeoffs that a project needs to make when it comes to properly selecting a price feed and the security mechanisms around it.
If you’re a defi project looking to use solely centralized prices with known attack costs, you’d be better off skipping the community consensus piece of the protocol, and work to just allow the exchanges to write the price to your contract. If, however, you’re a project, or know of one, that might benefit from a robust, decentralized oracle, reach out and feel free to give www.tellor.io a look.
