0. Oracle Introduction

Blockchains have two sources of data: on-chain data (e.g. the amount of ETH held by an address), and off-chain data (e.g. the current price of ETH on the exchange). To get the latter, the oracle needs to tell this data to the smart contract.

Why does the Internet also need to have “offline” data, but doesn’t have the oracle problem? Because data on the blockchain needs to be secured, so the data uploaded to the oracle needs to be trusted, whereas data on the Internet (Web2) is inherently centralized.

The oracle needs to solve the trust problem from data source to processing and feeding, not usually the problem of the data itself.

1. Off-chain Oracle

The trust problem of the oracle consists of data source and data processing and feeding, and the following solutions are available for each of them:

a) Data Source: Trusted Party / Decentralized Network

I think the most important point of the oracle’s trust issue is the trustworthiness of the data source, but a lot of this data is off-chain, and there is no way to prove that the off-chain data is completely trustworthy, just like you can’t prove that the price of ETH on certain exchange must be a certain value. Neither a trusted party nor a decentralized network of oracle can generate a price with no arbitrage or OEV at all.

The only way to solve the problem of trustworthy data sources is to go full on-chain prophecy (Uniswap TWAP) in the future when most of the liquidity and economic activity is happening on the chain, not on the exchange, so that the data sources are “crypto-native” and fully trustworthy and verifiable. .

b) Data Processing and Feeding: Trusted Computing

Town Crier uses SGX to ensure that the data processing is credible; Empiric uses contracts on StarkNet to ensure that the data processing and calculation is credible, and the data source sends price data directly to the oracle contract on StarkNet to make it first-hand data, to ensure the credibility of the data source; Redstone’s SmartWeave contracts allow anyone to be a data processor and use Arweave to store price data so that it is trusted and can be verified later; Chainlink uses the Chainlink network’s on-chain aggregation contracts to calculate data results and send them to the blockchain.

Any application that is supposed to be on the chain will eventually be on the chain, thus satisfying the transparent, verifiable, permissionless, decentralized nature of the blockchain.

A fully on-chain oracle will completely solve the problem of data sources and data processing and feeding, allowing DeFi applications to bring freedom of economic activity to all.

2. TWAP (Time-Weighted Average Price)

TWAP is an oracle from Uniswap. Its data source comes entirely from the Uniswap protocol’s own trading data. The data is obtained and processed entirely on chain. Developers can use Uniswap TWAP directly on chain for token price calculations.

The principle of TWAP is based on the token price at the last tx of each block, combined with the block time, to calculate the sum of the price of a token over the entire history of the protocol, so that an average price can be calculated when the oracle is used.

The reason for using the price at the last tx is to make the attacker’s cost of attack unpredictable, thus increasing the oracle’s security. This is because even if an attacker controls the price at the last transaction of a block, he cannot predict the information such as the ordering of the related activities in the next block. According to on-chain analysis, this kind of multi-block attack has not happened yet. (Spoiler alert, in PoS, it doesn’t seem to be the same).

The time variable is added to further increase the cost of the attack, and to maintain the overall stability and security of the price by sacrificing the reflection of the immediate price on the TWAP price.

3. Uniswap V2 TWAP

V2 TWAP can be used by directly getting the total price change over a time period and dividing it by a set time period t to get an average price as the token price. At regular intervals (not necessarily t, you can use the sliding window algorithm, which has a smaller delay on price change), the price is retrieved for the latest time period.

For TWAP, the longer the time parameter, the slower the updates, but the higher the security, since the cost of price manipulation is essentially the overhead of arbitrage and the gas of sending transactions on each block during the time interval.

4. Uniswap V3 TWAP

V2 uses the total price (price * time) in the time period, V3 uses the total tick (tick * time) in the time period.

In V2 we mentioned the need to re-fetch prices every so often, which may require the involvement of a Keeper, Uniswap V3 solves this problem.

V3 stores block timestamps and total ticks directly in an array of definable length (depending on demand and network timestamp behavior), which is updated when swapping and other interactions happen to the contract, without the need for active trigger from the Keeper.

In addition, you need to convert the tick to a price when using it, which is a little harder to use than V2.

5. TWAP’s Limitation

If TWAP works so well, is so trustworthy and verifiable, and is completely decentralized, then why is Chainlink so widely adopted?

The motivation for writing this article was actually seeing someone on Twitter say that Euler Finance’s switching from TWAP to Chainlink is an upgrade (note the person’s ID… ==).

He claims that TWAP is very insecure because in PoS attacker can perform multi-block oracle manipulation, which is actually completely solvable.

In contrast, I think the advantages of TWAP being fully decentralized and fully on-chain are much better than Chainlink, and in the long run, if there are no significant differences in application demand (e.g. you want to move weather data to the chain), then TWAP is the best choice.

A comparison of TWAP and Chainlink:

TWAP is being crushed across the board, but I personally believe that decentralization and security are the leading 1, and the other factors are the trailing 0. Completely on-chain is a trend. Anyone can make a smart contract platform that is very much faster, cheaper, and supports more programming languages than Ethereum, but it can’t kill Ethereum.

6. After the Merge, TWAP’s risk

The problem of attacks on TWAP oracle in PoS networks, as described by ChainLinkGod, has also been considered by Uniswap engineers and Euler Finance’s engineers.

In PoS, since the block producer is more predictable, it is easier to perform multi-block attacks in the following ways combined:

• Validators with large stakes may be assigned blocks consecutively

• Private tx sent via Flashbot

• Multi-block bundle

In the case of PoW and PoS, TWAP for a 30 minute time window (144 blocks) for the V3 ETH/USDC pair, the following costs are required to manipulate the price to cause 30% volatility:

• PoW: $23.7 trillion

• PoS (with 2 blocks in a continuous control window): $23.7 trillion

• PoS (with 3 blocks in a continuous control window): $9.5 billion

• PoS (with 5 blocks in a continuous control window): $103 million

The more blocks under control, the significantly lower the cost of manipulation, so what’s the solution?

A temporary solution to the risk of manipulation of TWAP after PoS would be:

1. choose a larger time window

2. choose a pool with better liquidity.

A complete solution to the manipulation risk of TWAP after PoS is:

• use Median instead of Average.

This would require the manipulator to control more than half of the blocks in order to manipulate the price, compared to the case above, which would require controlling 73 blocks, a number that should be too large to type.

7. Next-gen Oracle

I think in the future, a perfect “oracle” is needed:

• Fully verifiable data sources from the blockchain (then it should be based on TWAP), and support for multi-chain.

• Data processing and processing via ZK or full on-chain trusted computing.

But these may require dealing with the following existing or emerging glitches:

• On-chain data for variety, precision, and timeliness (of course, Chainlink and others have the same problem of price delays)

• Complete solution to TWAP data source price manipulation (deeper pools, larger windows, use median instead of average)

• Elimination of trust shortcomings across the oracle (multi-sig? Nakamoto coefficient? Unreliable Fisherman mechanism?)

• Cross-chain access and feeding of data, and trusted transmission of data on the chain in multi-chain scenarios

• Data source diversity (e.g., using only Uniswap V2 or V3 is not good)

• Keeper execution in trusted environment (if keepers needed)

I believe that in the future, more and more economic activities will take place on the chain, more and more price data and transaction pairs will exist on DEX, Uniswap will be able to provide a better TWAP, and there will be other solutions to achieve my vision of a perfect oracle based on TWAP, and eventually a 100% decentralized financial system.

Related Links

0:

1b:

2:

3:

4:

5:

6:

7: