What Solidity Devs Should Know about Ethereum’s Merge

Changes to be aware of

• block.difficulty has a new source
• Block times will be shorter by 1-2 seconds
• Less new ETH being added to the ecosystem
• Multi-block MEV == new possible attack vectors

block.difficulty has a new source

In Solidity's PoW era, the global variable block.difficulty existed as a way to access the current difficulty level of the PoW's algorithm. As we shift to PoS and no longer have a concept of 'work' we also no longer have a difficulty level to source block.difficulty from.

To keep the previous Solidity code functioning, the Ethereum Foundation decided to change block.difficulty's underlying opcode 0x44 to return a new PoS field named prevrandao.

In the PoS world, this value is produced by the beacon chain and is used to help determine who the next set of validators are in the block proposal and attestation process. The “prev" part of prevrandao is derived from its value being the previous block’s outputted randao value.

Do I need to take any action?

• If you were using block.difficulty to help create randomness in your code, firstly, don’t do this because it is not actually random. Ultimately, your code should run the same.
• If you were relying on block.difficulty to be in the previous PoW sensible range of 0-2^64, your code could break. block.difficulty will now range from 0-2^256.
• If you had specialized logic to have your contract act differently based on the block.difficulty level, your code will not behave as intended as block.difficulty is now pseudorandom with an increased range.
• Bonus: if you want to write up logic that behaves differently pre and post-merge, you can use block.difficulty's value to reasonably determine if the merge has occurred or not. Values less than 2^64 could be used to see that the chain is still PoW.

Can I use this newfangled prevrandao instead of the fancy techniques like Chainlink’s VRF when I want stronger randomness?

The consensus in the security community is a firm ‘no’. Use existing VRF infrastructure for security critical randomness needs.

Validators who are chosen to propose blocks will be able to know the value of prevrandao while selecting the transactions to construct their blocks out of. In other words, block proposers could choose to add or censor transactions if they find it beneficial to do so based on the current block’s value of prevrandao.

Block times will be shorter by 1-2 seconds

A common misconception about the merge is that it will result in noticeably more capacity. This is not true. Capacity will increase a tiny bit, as block times will decrease from an average of 13 seconds (with a wide variation) to almost exactly every 12 seconds. Important to note: blocks can be skipped if a validator goes offline or chooses to not submit a block when it is their turn. This currently happens < 1% of the time.

Do I need to take any action?

• If your code assumes a block cadence of 13 seconds, be prepared for it to run faster than expected.

Less new ETH being added to the ecosystem

According to the Ethereum Foundation, the change to PoS will slow down the creation of new Ether by a drastic amount: from a current 4.1% per year to a projected 0.3%-0.4% per year.

• In the current PoW system ~14,600 new ETH is produced and ~1,600 ETH is burned each day.
• In PoS, it’s projected that ~1,600 ETH will be produced and ~1,600 ETH will continue to be burned, resulting in a non-inflationary total ETH supply.

Do I need to take any action?

• This is a major change to the native currency in the ecosystem and could have large long-term impact on the value of ETH.
• If you are in the practice of hardcoding ETH values into your protocols, consider adding options in the future to change the required amount of ETH to interact with your projects.

Multi-block MEV == new possible attack vectors

In PoW it is prohibitively computationally expensive to know who the next miner of a block will be. This is changing dramatically in PoS: validators are selected and announced by the beacon chain in schedules of 32. Furthermore, according to FlashBots, it is possible that validator pools could have direct control over consecutive blocks.

Many PoW-era protocols rely on the security assumption that no one in the system can ensure that they will have control across multiple blocks. This has been used as a fundamental building block in protocol designs.

Take, for example, the common pattern of Automated Market Makers (AMMs). Protocols such as Uniswap use a time weighted average price (TWAP) across blocks to serve as a price oracle. If an actor can know that they will have control over a set of blocks, they could use this information to sway the TWAP price to exclusively benefit themselves.

Do I need to take any action?

• Exactly how and if MEV groups will use the new PoS architecture to create new market opportunities is an open question.
• Currently, the only courses of action are:

1. Be aware that new Multi-block MEV opportunities could come into existence using control over consecutive blocks, and
2. Adopt the new PoS protocol system designs which will emerge to accommodate the new security landscape.

Conclusion

The switch from PoW to PoS will be a substantial win for the Ethereum ecosystem but will not change your life as a Solidity developer in a major way.

Remember to:

• Practice good randomness hygiene
• Keep up to date on new MEV strategies, and
• Stay up to date for the Ethereum Foundation to roll out the rest of the planned next-gen Ethereum upgrades.

---

Extended Learnings

If reading this has tickled your curiosity and you are itching to learn more, we love that! Here are the sources that we used to construct this post to help you dive deeper:

• Ethereum’s previous and planned execution upgrades. This is the place to look to see which EIPs are planned to be included in the next upgrade. Here is the spec specific to the PoS ‘Paris’ upgrade.
• EIP-3675: Included in the Paris upgrade, this EIP explains all of the major changes to the execution environment required to change from PoW to PoS.
• EIP-4399: Also included in the Paris upgrade, this EIP changes the opCode 0x44 from returning the difficulty field to the prevrandao field. Solidity’s block.difficulty global variable compiles down to opCode 0x44.
• An information goldmine on how the beacon chain constructs the randao value which prevrandao refers to.
• An in-depth FAQ on the merge unrelated to Solidity changes. Useful as a starting source if you want to learn how to participate in staking ETH with a validator.
• A blog of all of the application layer changes due to the merge. Good to read if you’re responsible for more than just your protocol’s Solidity code.
• A fun web app showing the current and merge-simulated ETH issuance and burn rates.
• For the hardcore learners, here is one of the Ethereum Engineering Group’s information stuffed video on the PoW to PoS upgrade. This is an in-depth video directly from the people who are writing the EIPs for the merge.