When Ethereum changes from proof-of-work to proof-of-stake, there are a few changes to the application layer that developers should be aware of. Some of these changes could impact the security of protocols that are currently safe under ETH 1 but not on ETH 2.
TL;DR
- Block time is decreasing from a variable ~13 seconds to exactly 12 seconds. If your contract relies on the average block time in its formula, consider updating it to reflect this change.
- The 0x44 DIFFICULTY opcode is being supplanted by PREVRANDAO. This
change is backwards compatible with contracts that use
block.difficultyas a source of pseudorandomness, so developers do not have to make changes. - Most importantly, consecutive slot miner extractable value (MEV) may invalidate prior security assumptions. Developers should presume that an attacker may control two consecutive blocks and reassess their security logic with this in mind.
In this article, we’ll cover each of these changes in depth as well as potential scenarios in which they could cause problems. We will progress through the changes from the least to the most important because the last two are interrelated.
Block time
The simplest change for developers to consider is the reduction in block time. Block time↗ refers to the amount of time it takes to mine a new block.
The average block time will change from ~13 seconds with a fair amount of variance to exactly 12 seconds except when a slot is missed due to a validator being offline or not submitting a block in time.
Suggestions for developers:
If your smart contract uses the average proof-of-work block time you may want to consider incorporating the 12-second proof-of-stake block time in your calculations.
Many popular DeFi applications use formulas that rely on the average block time. For example, Compound’s formula↗ to calculate interest payments uses a blocksPerYear value↗ that is derived from a ~15-second block time. After the merge, this formula could be updated to use a 12-second block time to calculate interest payments more accurately.
Randomness using block.difficulty
If your contract relies on block.difficulty to construct
pseudorandomness, here’s another small change to be aware of.
Developers commonly use the value returned by block.difficulty as a
source of pseudorandomness in their applications by mixing it with other
values.
Most developers are aware that true randomness cannot be generated on-chain since the EVM is deterministic. However, sometimes a pseudorandom number is good enough if the economic value being protected is less than the amount an attacker receives by influencing the randomness.
Post merge, the EVM 0x44 opcode, which currently returns DIFFICULTY, will be supplanted by PREVRANDAO, which is the output of the randomness beacon provided by the beacon chain in the previous block. Be aware that PREVRANDAO should not be used as a source for true randomness. If the security of a contract relies on a truly random number, then an oracle service such as Chainlink VRF↗ should be used to pull that data on-chain.
Suggestions for developers:
This update is backwards compatible, so contracts that use the DIFFICULTY opcode for pseudorandomness will work the same post merge.
There is an unlikely caveat: if your contract requires block.difficulty
to return a value that is representable within 64 bits (i.e., < 2^64),
that will be problematic because PREVRANDAO will return a value within
the full 256-bit field↗.
Multi-block miner extractable value
The most important change that developers should be aware of is the increased likelihood of a validator, which is akin to a miner in ETH 1, controlling two consecutive blocks.
In ETH 2, validators↗ will take over the responsibility of transaction sequencing from miners. Validators will both propose and validate emerging blocks. According to research from Flashbots↗, it is likely that a large validator pool will produce two consecutive slots within one epoch. Quoting from the same article, “This could enable multi-block MEV extraction by creating a meta-slot out of the number of continuous slots held by a single entity, and might open up new vectors of attacks”.
Even with a low probability of producing two consecutive blocks, since proposer slots are assigned and known at the beginning of each epoch, a market may evolve for bribing a proposer to include or remove a transaction in a block.
This is an emerging area of research, so the security recommendations are still evolving. Let’s explore a few scenarios where multi-block MEV (MMEV) may impact the security of protocols that would otherwise be safe under ETH 1.
Time-weighted average price (TWAP) manipulation MMEV
One likely avenue for attack using MMEV is described in TWAP Oracle Attacks: Easier Done than Said?↗.
An attacker that controls two continuous blocks can profit by manipulating a TWAP price basically for free:
In block 1:
- Deposit a large amount of tokens in a Uniswap V2 pool to manipulate the TWAP price. Uniswap V2 pools update the TWAP price at the end of the previous block↗ to protect against flash-loan attacks.
In block 2:
- At the beginning of the block, withdraw the tokens you deposited in the previous block. Since you control the transaction ordering within this block, there is no risk of being front run by an arbitrageur.
- Profit by liquidating users in a lending protocol that relies on the price data from the manipulated TWAP.
Torgin Mackinga, one of the authors of TWAP Oracle Attacks: Easier Done than Said?↗, points out↗ that under POS, an attacker can perform this attack, given knowledge that they control the next block, by simply using Flashbots to submit their first transaction.
Since MMEV will create lucrative new value extraction scenarios, Flashbots will likely accommodate these new opportunities. Hence, this attack opportunity is likely to be incorporated into Flashbot searchers’ transaction-ordering algorithms.
Randomness manipulation MMEV
As a reminder from what we covered earlier, ETH 2 is replacing the 0x44 opcode DIFFICULTY with PREVRANDAO.
How does PREVRANDAO work?
The PREVRANDAO opcode, like its name suggests, returns the previous block’s RANDAO value.
From the eth2book↗, “A RANDAO is simply an accumulator that incrementally gathers randomness from contributors. So, with each block, the proposer mixes in a random contribution to the existing RANDAO value.”
The beacon chain uses RANDAO to generate reasonably random numbers, which are important for the security of proposer selection and committee assignments for each epoch. If you are interested in the particulars, I highly recommend reading the eth2book’s randomness chapter↗ for a very digestible explanation.
MMEV opportunities using PREVRANDAO
It is possible for a proposer to influence PREVRANDAO for a limited amount of time until the first honest RANDAO reveal is made after the manipulation. The proposer’s influence is relative to the amount of slots they are able to control through honest proposal selection or bribery.
For example, suppose a proposer is selected for two consecutive blocks. Prior to their first block, they place a bet in a game contract that relies on block.prevrandao to generate pseudorandomness to select the winner. Since the proposer controls two consecutive slots, they can explore four possible outcomes of the value that relies on block.prevrandao and propose whichever is most advantageous to their profit. That could mean not proposing a block in slot 1 or proposing in both slot 1 and slot 2 or any permutation of these.
Furthermore, since proposers control which transactions are included in a block, they may censor a transaction “to force it to be included into the next block, thus force it to use a RANDAO mix that the proposer knows in advance.”↗
Suggestions for developers:
The EIP-4399 proposal↗ suggests that developers “make your applications rely on future randomness with a reasonably high lookahead” by using the formula K + N + E where K is the end of an epoch, N is a lookahead in epochs, and E is a few slots into epoch N + 1.
In practice, developers should implement a time delay between committing (i.e., bidding) and using pseudorandomness (i.e., rolling a pair of dice) to choose a particular outcome.
The EIP uses an example of a four epoch lookahead, which is about 25 minutes. At this time it is unclear what the tradeoff is between using a shorter lookahead time.
If you are a developer who is planning on using PREVRANDAO, then the example portion of this presentation↗ by Mikhail Kalinin, one of EIP-4399’s authors, may be helpful.
About Us
Zellic specializes in securing emerging technologies. Our security researchers have uncovered vulnerabilities in the most valuable targets, from Fortune 500s to DeFi giants.
Developers, founders, and investors trust our security assessments to ship quickly, confidently, and without critical vulnerabilities. With our background in real-world offensive security research, we find what others miss.
Contact us↗ for an audit that’s better than the rest. Real audits, not rubber stamps.