Oracles
A blockchain cannot see outside itself. Anything a contract needs to know about the world must be told to it, and whoever tells it holds real power.
A smart contract can read its own chain's state and nothing else. It cannot check a price, a temperature, an election result or whether a delivery arrived. Every node must reach an identical result, so contracts cannot simply call a website — different nodes would get different answers at different moments and consensus would break.
The oracle problem
An oracle is a system that publishes outside information to the chain so contracts can read it. However it is constructed, there is a party or set of parties whose honesty and correctness the contracts now depend on. A system described as trustless generally has one of these at its centre. See what trustless means.
The designs
- Single publisher. One party posts the data. Simple, cheap, and a complete point of failure.
- Decentralised networks. Many independent nodes report, with outliers discarded and reporters bonded against misbehaviour. The standard approach for price feeds.
- On-chain observation. Derive the price from a pool on the same chain. No external trust, and directly manipulable by anyone who can move that pool.
- Time-weighted averages. Use an average over a window rather than the instantaneous price, making brief manipulation far more expensive. Standard defensive practice, at the cost of lagging real moves.
How manipulation attacks work
- A lending protocol values collateral using the price in a particular pool.
- An attacker borrows a very large sum within a single transaction — a flash loan, which requires no collateral because it must be repaid before the transaction ends.
- They trade against that pool, moving the reported price dramatically.
- In the same transaction, they borrow against collateral the protocol now believes is worth far more, or trigger liquidations at a false price.
- They repay the flash loan and keep the difference. Everything happens atomically, in one block.
This category of attack has drained a great many protocols, and in most cases the code contained no bug at all. It trusted a price that could be moved cheaply. That is why oracle choice is a first-order security decision rather than a configuration detail, and why a thin on-chain pool should never be a price source for anything that matters.
The wider point
The oracle problem bounds what this technology can do on its own. A contract can settle a bet on a football result only if some party reports the result. It can pay an insurance claim on a flight delay only if some party attests to the delay.
So a great many proposals to put real-world agreements on-chain reduce, on inspection, to trusting a data provider. The automation is real and the trust was relocated, not removed — which is not a reason to dismiss the idea, only a reason to look for where it went.