Proof of Stake is coming
Ethereum’s Merge is coming soon™ and will be moving the network from PoW to PoS. This is a consensus layer change and will have relatively few effects on the application layer.
However, there is a consensus layer change that can affect the security model of certain smart contracts: The way that blocks are produced.
Smart contract developers need to take MEV into account if they are developing contracts that assume the existence of competition, where all users should have access to the same on-chain information immediately.
Block producers are known ahead of time
In PoW, miners produce blocks probabilistically. Unless selfish mining is used, it’s impossible to know who will produce the next block.
In PoS, the block proposer per slot is chosen deterministically and ahead of time.
From Vitalik’s annotated spec: “The randao mix at the start of epoch N is used to compute the seed for epoch N+1; this ensures that the proposer and committee roles are known one epoch ahead of time, giving validators a chance to prepare.”
At the time that the last block of epoch N-1 is produced, the block producers of all 64 blocks contained in epoch N and N+1 are already known. This means it is possible to know the block producer up to 12.8 minutes ahead of time. (Sidenote: In some rare cases, validator balance changes (e.g. due to slashing) can still change the proposers for epoch N+1. Epoch N proposers are guaranteed.)
This is a fundamental change that opens new possibilities for potential attacks. One possible attacker is an entity that runs validators and knows that it controls the next block. This means they can censor any transactions for that block or simply decide the ordering, also known as MEV.
The most well-understood attack that is enabled by this is oracle manipulation.
TWAP oracles
Many DeFi applications, such as lending protocols, critically rely on price oracles to tell them the value of on-chain assets. One such price oracle, which is popular due to being fully on-chain, is the Uniswap V2 TWAP (time-weighted average price) oracle.
TWAP oracles are fairly simple: They record the price of an asset on Uniswap at the end of every block over many blocks, then sum them up and divide by the number of blocks. This gives the average price over the TWAP period. The TWAP is a lot harder to manipulate than the price in a single block, as there is more time for arbitrageurs to see the imbalanced market and make a risk-free profit by bringing it back to the “true price”.
Oracle manipulation
The naive way to manipulate a TWAP is to just buy tokens on Uniswap to increase the price. At the beginning of every block, arbitrageurs will sell the asset bringing it back to the “true price”, so an attacker needs to re-manipulate the price in every single block. This is expensive.
A cheaper alternative (for sufficiently long TWAPs) is to do the manipulation in a single block. Let’s say the “true price” of an asset is 1 and we want to manipulate a 100-block TWAP to report a price of 2. Instead of manipulating the price to 2 100 times, we just manipulate it to 101 in the first block, record that value at the beginning of the second block, then leave it at 1 for the other 99 blocks. This will give us an average price of 200/100 = 2. Since this attack is possible within 2 blocks, transaction ordering (MEV) in those blocks becomes extremely important.
Multi-block MEV attack
The cost of TWAP manipulation comes almost entirely from losses to arbitrageurs. If it was possible to hide the manipulated prices in between 2 blocks and rebalance the market again in the second block, it would become essentially free. This is possible in PoS Ethereum, if the attacker runs validators and happens to propose 2 blocks in a row. If this is the case, they can do the following:
- In the first block, manipulate the Uniswap market to a high value without sending the transaction to the public mempool.
- After the block is published, bots will see the arbitrage opportunity and submit transactions to seize it.
- Since the attacker also controls the second block, they put their own transaction to rebalance the price at the top of the block, ensuring that they do not lose any money.
Now, how difficult is it to control 2 blocks in a row? Surprisingly easy. Since stakers know ahead of time when they will be proposing blocks, they can just wait until they happen to get 2 in a row. The expected number of blocks before proposing 2 blocks in a row given that you control p share of Ethereum’s stake is: ((p^(-2)-1)/(1-p)). Let’s take an example attacker that controls 0.15% of Ethereum’s stake, which as of August 2022 has a capital cost of approx. $35 million. Plugging in p=0.0015, we get that on average the attacker will propose 2 blocks in a row every 62 days, with no opportunity cost compared to normal staking. This enables manipulating a TWAP with virtually no cost (but high capital requirements).
Conclusion
The security of Uniswap TWAP oracles comes from arbitrageurs rebalancing uniswap pools. By knowing that they will control the next block, an attacker can hide information from arbitrageurs for long enough to ensure that they cannot make a transaction before the opportunity disappears. The consensus level change has an effect on the execution layer, by changing the assumptions that the smart contract system must make about attackers.
Smart contract developers need to take MEV into account if they are developing contracts that assume the existence of competition, where all users should have access to the same on-chain information immediately.
Additional notes
- If the attacker has access to a darkpool, to submit transactions privately to the first block’s proposer and is confident that it will not leak, the MEV attack can be done by only controlling the second block, not both.
- Uniswap V3 oracles are much more resilient to single-block manipulations than V2 oracles, as they use a geometric mean instead of an arithmetic mean, which is less affected by outliers. To manipulate a V3 oracle, the attack can be repeated multiple times to create multiple outliers. The attack can be repeated as many times as the attacker controls blocks within one TWAP period. The capital requirements shrink dramatically with repeated attacks, as each manipulation can be smaller.
- The attacker’s second block could be reorged. In this case the arbitrage opportunity could be captured and the cost would be equivalent to the single-block attack without Multi-block MEV.
This post is based on TWAP Oracle Attacks: Easier Done than Said? (Mackinga, Nadahalli, Wattenhofer, 2022), expanding on the effects of PoS on the described attacks. The full paper contains more in-depth information on TWAP oracle manipulation.