Oracles and the oracle problem - how a blockchain learns about the outside world

A blockchain is a closed world. A contract knows everything recorded on the blockchain and nothing about what happens beyond it: the dollar rate, the weather, a match result, whether a parcel has been delivered. To use such data an intermediary is needed - an oracle. And here the main problem arises: if the oracle errs or lies, the contract will faithfully execute the wrong thing. Context on smart contracts is in the article what a smart contract is.

Why a contract cannot "look for itself"

Every node on the network must get an identical result when executing (consensus). If a contract could visit a website, different nodes would receive different answers at different times and the network would never agree. So external data must be written into the blockchain as a transaction, after which all nodes see the same thing.

What the oracle problem is

An oracle is the very "trusted link" that a blockchain originally wanted to get rid of. A contract can be flawless, but its decisions depend on its inputs. If the oracle:

• errs (a failure, stale data);
• is hacked;
• is bribed;
• is manipulable (the price can be shifted artificially),

the contract will cause harm despite "correct" code.

Kinds of oracles

1. Centralised. One source publishes data. Simple, but a single point of failure.

2. Decentralised networks. Many independent nodes get data from different sources and publish it, and an aggregator contract takes the median. An example is Chainlink price feeds. Manipulation requires bribing a majority of nodes.

3. On-chain price oracles. The price is taken from a decentralised exchange (AMM). The simplest form is vulnerable: the instantaneous price can be moved with a flash loan. So TWAP is used - the average price over a period, which is costlier to distort.

4. Optimistic oracles. A result is accepted if nobody disputes it within a period; disputers post a deposit. Suited to events that cannot be expressed as a number.

5. A human. For decisions that cannot be formalised (whether the buyer received goods of proper quality) the oracle is a person or group.

Example: reading a Chainlink price

(, int256 answer, , uint256 updatedAt, ) = priceFeed.latestRoundData();
require(answer > 0, "bad price");
require(block.timestamp - updatedAt <= 1 hours, "stale price");
uint256 price = uint256(answer);          // usually 8 decimals

Minimum checks:

• a positive value (negative or zero is a failure);
• freshness of data (updatedAt): feeds update on a timer and on price deviation;
• decimals - bring to one scale (integer math);
• a fallback plan for an oracle failure.

Price manipulation and flash loans

A flash loan is an uncollateralised loan that must be repaid in the same transaction. The attack:

1. Take a flash loan of a large sum.
2. Artificially shift a token's price in a small pool.
3. Call a contract that uses that "instantaneous" price: borrow more than allowed.
4. Repay the flash loan, keeping the profit.

It all happens in one block and you cannot react in time. The defence: do not use an instantaneous price from a single pool (catalogue of vulnerabilities, MEV).

What the escrow does not have: it needs no price oracle

The Coin-Trust contract holds specific amounts of a specific token and returns those same amounts. It needs no exchange rates, so there is no risk of price manipulation. But the escrow has its own oracle problem: how does the contract learn that goods were delivered or work was done? This cannot be seen from the blockchain.

The solution is a human oracle:

1. In the ordinary case the oracle is the buyer: they confirm receipt (confirmDelivery).
2. If the parties disagree, the guarantor becomes the oracle: they rule (resolveDispute) on the basis of evidence (arbitration).
3. If the guarantor is silent, the emergency exit applies, which requires no data at all.

This way the service moves the oracle problem from the zone of "cannot be checked" to the zone of "people determine, the contract executes". That is exactly why choosing a guarantor matters so much.

Takeaways

1. A contract does not see the outside world; data must be delivered.
2. The data source is part of the security system.
3. Decentralised oracles and price averaging raise the cost of an attack.
4. Always check the freshness and plausibility of data.
5. For non-formalisable events the oracle must be people, and trust must be structured.

What to read next

We will see how transaction order is undermined: MEV and front-running. Or how to optimise gas costs: gas optimization.