What you need to know to get ready for the Ethereum Merge: Infura Developers Edition
The Ethereum Merge to Proof of Stake is on the horizon and the Infura Ethereum API is ready. We've prepared a guide on how Infura users can prepare.
The Ethereum Merge to Proof of Stake is on the horizon and the Infura Ethereum API is ready. We've prepared a guide on how Infura users can prepare. [Updated on Monday September 26th to include Rinkeby, Ropsten, Kovan deprecation timelines and on October 5th in include information on Rinkeby, Ropsten, Kovan Stats deprecation]
First off, when is the Merge to Proof of Stake happening?
The Ethereum Merge to Proof of Stake is scheduled to occur at Total Terminal Difficulty (TTD) 58750000000000000000000, which was formally agreed upon in the August 18th, 2022, All Core Devs call.
This estimates the Merge will occur approximately between September 15th and 16th given the current hash rate of Ethereum, although the specific date and time will depend on hitting the TTD.
What is the Merge again?
The Merge is a planned upgrade of Ethereum that merges the existing execution layer with the beacon chain as detailed in EIP 3675: Upgrade consensus to Proof-of-Stake.
What do I need to do if I am a dapp or smart contract developer?
Infura’s Ethereum API will continue to operate as it does today. For the majority of our users, the Merge will not impact their daily operations and the transition to Proof of Stake will be seamless. However, it’s important to note, as called out by the Ethereum Foundation on their Upgrades: The Merge page, there will be changes to:
- Ethereum’s block structure
- block timing
- opcodes
- sources of on-chain pseudo-randomness
- concept of “safe” head and “finalized” blocks (changes to specific parameters in API calls)
- testnets
Below we review each of these changes to help you understand exactly what each means for you, as well as in our Merge Weekly Workshop on Dapp Developer Considerations. We also show how to deploy a smart contract to the Goerli testnet.
Ethereum’s Block Structure in Proof of Stake
Source: https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/
There are changes to Ethereum’s block structure under Proof of Stake, and the changes have been done in such a way to minimize the impact on existing smart contracts (and by extension, dapps) that have already been launched on Ethereum. The Execution Payloads that exist as part of a block under Proof of Work consensus are merged with the block structure of the Consensus Layer, also known as the Beacon Chain, once the Merge occurs; hence why it is called “the Merge”. This is best illustrated by the diagram below from Tim Beiko of the Ethereum Foundation.
Source: https://tim.mirror.xyz/sR23jU02we6zXRgsF_oTUkttL83S3vyn05vJWnnp-Lc
The following fields that are part of a block will become constants, like nonce. This is because the nonce is no longer required, due to there no longer being an Ethash function as part of the consensus mechanism.
- ommersHash
- mixHash
- nonce
- ommers
Further explanation of this can be found in EIP-3675: Upgrade consensus to Proof-of-Stake. Additional fields will see changes, which is discussed in the section below called, Opcode changes.
Block Timing
Block creation will change from occurring roughly every ~12 to 14 seconds to being consistently created every 12 seconds. This consistency in timing means that block production will be ever so slightly faster than prior to the Merge.
Opcode Changes
Source: https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/
The 0x44 opcode, which had been known as difficulty in Proof of Work, will now be known as PREVRANDAO in Proof of Stake. The impact of this change is that instead of this field returning the block difficulty, it will now return an output from the Consensus Layer. This will allow for backward compatibility for smart contracts that have used 0x44 as a source of pseudo-randomness.
Sources of On-Chain Pseudo-Randomness
Due to the above mentioned opcode change, any smart contract developer who intends to use this opcode for pseudorandomness will need to adhere to specific conditions as outlined in EIP-4399: Supplant DIFFICULTY opcode with PREVRANDAO and specifically following the instructions in the section “Security Considerations” of Ethereum Improvement Proposal 4399 .
These changes will not apply to all smart contract developers. However, we do think it is worthwhile for smart contract developers to be aware of this change and to read up on it.
Concept of “Safe” Head and Finalized Blocks: Changes to specific parameters in API calls
Within the Infura Ethereum API JSON-RPC methods documentation, once the Merge occurs, there will be new parameters available to be used within an API call. New parameters called “safe” and “finalized” will be added.
Flagging blocks as “latest” head versus “safe” head (“safe” lags “latest” head by 4 seconds or so) versus finalized head (“finalized”lags “latest” by one or two epochs, 64-128 blocks within.
edit: a previous version of this blog mentioned theunsafe
keyword as an alternative tolatest
. This was considered early on by the community but ultimately not adopted, users should continue to uselatest
for the time being.
Testnets
Prior to this point, the following networks have already merged:
- Ropsten Merge - June 8, 2022
- Sepolia Merge - July 6 2022
- Goerli Merge - August 10 2022
Infura supports Goerli and Sepolia as testnets. We recommend that you use Goerli to deploy and test your smart contracts before deploying to mainnet.You will see that all of our tutorials will now point to Goerli as the testnet to use.
Many of our L2’s and side-chains have also switched to using Goerli as their testnets, like Optimism and Arbitrum. Be sure that any smart contracts you are deploying to a testnet are deployed to Goerli instead of Rinkeby, Ropsten, or Kovan.
There will be a deprecation of Ropsten, Rinkeby, and Kovan from both Infura and the greater community. Infura will be deprecating these three networks from our Ethereum API on October 5th, 2022. We will announce the deprecation timelines via blog.infura.io, as well as communication to all Infura customers. There is no action required due to this deprecation, but if you intend to use a testnet going forward, use Goerli. Pyrmont, a Beacon Chain testnet, is also deprecated and has already been removed from the Infura UI.
The Ethereum Foundation has announced deprecation timelines for Ropsten, Rinkeby, and Kovan, and any public endpoints will also be deprecated according to that timeline.
What do I need to do if I am a Solo Staker?
Once the Merge occurs, an Ethereum Client will now consist of a Beacon Node driving an Execution Engine to produce a valid block when the validator is given their slot to propose a block. The Execution Engine, also referred to as the Execution Layer, is a client like Geth or Hyperledger Besu. Staking Node Validators will need to run both a Beacon Node aka Consensus Layer Client (like Teku) as well as an Execution Layer client in order to participate as validators and block producers in the network. These instructions are just for those who have Staked 32 Eth in order to participate as a Staking Node Validator. The Ethereum Foundation, in their webpage on preparing for the Merge specifically states that a Staking Validator (another term for Solo Staker) will need to:
1. Run both a consensus layer client and an execution layer client[...]
2. Authenticate both execution layer and consensus layer clients with a shared JSON Web Token (JWT) secret so they can securely communicate.
Not completing the first two items above will result in your node being seen as "offline" after The Merge until both layers are synced and authenticated.
3. Set a fee recipient address to receive your earned transaction fee tips/MEV.
Not setting a fee recipient will still allow your validator to behave as usual, but you will miss out on unburnt fee tips and any MEV you would have otherwise earned in blocks your validator proposes.
Our Merge Weekly Workshop on The Execution and Consensus Client guides you through the steps of running an Execution Layer client and a Consensus Layer client using Hyperledger Besu as the Execution client and Teku as the consensus client. This session also gives you tips directly from the author of the series “My Journey to Becoming a Validator on Ethereum 2.0” on the specific setup and recommendations for Solo Staking.
The series, cited below, are helpful guides that should give you an indepth understanding of what is needed to be done to be a validator:
- My Journey to Becoming a Validator on Ethereum 2.0
- My Journey to Becoming a Validator on Ethereum 2.0, Part 2
- How to Monitor Your Eth2 Validator and Analyze Your P&L
- How To Safely Migrate Your Ethereum 2.0 Validator Client
- My Journey to Becoming a Validator on Ethereum 2.0, Part 5
For additional tips and resources from a Solo Staker and Co-Founder of Infura, Michael Wuehler, you can watch our Merge Weekly Workshop called The Solo Stakers Forum: What You Need to Do to Get Ready. We also recommend reviewing the Merge Readiness Checklist on the Ethereum Foundation’s Launchpad page.
What do I need to do if I am Staking ETH via a Staking-as-a-Service provider?
If you are Staking ETH via a Staking-as-a-Service provider, you should ensure that your provider has taken the required steps that a Solo Staker needs to take that are outlined on the Ethereum Foundation webpage on preparing for the Merge. The specific instructions that a Staking Validator will need to do are:
1. Run both a consensus layer client and an execution layer client[...]
2. Authenticate both execution layer and consensus layer clients with a shared JSON Web Token (JWT) secret so they can securely communicate.
Not completing the first two items above will result in your node being seen as "offline" after The Merge until both layers are synced and authenticated.
3. Set a fee recipient address to receive your earned transaction fee tips/MEV.
Not setting a fee recipient will still allow your validator to behave as usual, but you will miss out on unburnt fee tips and any MEV you would have otherwise earned in blocks your validator proposes.
As the Staking-as-a-Service provider will be in control of your ETH, ensuring that it is clear what the agreement means for getting your unburnt fee tips/MEV will be important, as well as the agreement for being able to withdraw any ETH once the Shanghai fork occurs. Also ensuring that your Staking-as-a-Service provider is taking the necessary steps to prevent slashing, so that you have confidence.
Our Merge Weekly Workshop Running Multiple Validators and Staking-as-a-Service will give you a good overview of the steps that Codefi Staking has taken in running multiple validators as a Staking-as-a-Service provider.
What do I need to do if I hold ETH?
ETH holders do not need to do anything to prepare for the Merge. If you see any messaging about trading in your ETH for ETH 2.0, THIS IS A SCAM. Do not follow it.
We strongly recommend that you do not try to “game” any Proof of Work fork tokens that may be created if miners are to create a short-lived fork of the Ethereum blockchain. There are risks associated with doing so, which are detailed in this Reddit thread titled The Risks of Interacting with Prospective PoW Forks of Ethereum. Stick with the Ethereum roadmap and only use your ETH on the Proof-of-Stake chain once the Merge occurs.
What do I need to do if I have an NFT on Ethereum?
Similarly to above, NFT holders with NFTs on Ethereum do not need to do anything to prepare for the Merge. If you see any messaging about trading in your NFT to make sure it works on ETH 2, THIS IS A SCAM. Do not follow it.
We strongly recommend that you do not try to “game” any Proof of Work forks by selling any NFT that may be issued if miners are to create a short-lived fork of the Ethereum blockchain. There are risks associated with doing so, which are detailed in this Reddit thread titled The Risks of Interacting with Prospective PoW Forks of Ethereum. Stick with the Ethereum roadmap and only use your NFT on the Proof-of-Stake chain once the Merge occurs.
What do I need to do if I am a developer or user of an L2 or side- chain?
Ethereum Virtual Machine compatible L2’s and side-chains have taken steps to move their testnets to Goerli. If you are a developer using an L2 like Arbitrum or Optimism, Infura has made the endpoints for the new Goerli testnet available. If the side-chain is using their own specific testnet, like Polygon, no action is required.
L2’s and side-chains will continue to play an important role in scaling Ethereum post-Merge. If you see any messaging about trading in your L2 or side-chain tokens to make sure they work on ETH 2, THIS IS A SCAM. Do not follow it. Always verify any information with the specific communication channel of the L2 or side-chain.
What is Infura doing to prepare for the Merge?
Infura has been diligently preparing to ensure our Ethereum API continues to be the best for developers to build and scale their dapps on Ethereum. We have been and continue to do the following in order to prepare for the Merge:
- Following our Quality Assurance processes.
- Participating in the Ropsten, Sepolia, and Goerli merges and providing information back to the Ethereum Foundation and community.
- Ensuring that our client software is up-to-date with the latest releases.
- Applying the new method parameters to our implementation of the JSON-RPC specification on our Ethereum API.
- Sharing information with our customers and the community to prepare for the Merge.
- Updating our documentation and terminology to be ready for post-Merge Ethereum.
- Participating in community calls and coordination efforts.
Our Merge Weekly Workshop on QA and the Merge takes you through the steps we have taken and are taking to prepare for the Merge. We are confident that these steps will ensure the Ethereum API remains the best in the industry and continues to allow builders to develop their innovations.
What’s next?
This is a pivotal moment in the history of Ethereum, akin to the moon landing. After the Merge occurs, Ethereum will continue to follow the roadmap laid out by the Ethereum Foundation, and articulated by Vitalik Buterin in his talk “Thoughts on the longer-term future of the Ethereum Protocol” given at EthCC 2022 this summer.
Frequently Asked Questions
Over the seven weeks of The Merge Weekly Workshops, we heard a variety of questions and want to provide you with the answers to the most common.
What Testnets will be available on Infura?
Goerli and Sepolia. All of our Ethereum documentation will now use Goerli testnet as the example to deploy smart contracts to.
What is the deprecation timeline for Kovan, Rinkeby, and Ropsten?
Infura will be deprecating these three networks from our Ethereum API after the Ethereum Merge, specifically on October 5th, 2022. If you intend to use a testnet going forward, use Goerli. Your Stats related to Rinkeby, Ropsten and Kovan will continue to be available on the Infura Stats page through November 3rd, 2022. On November 4th, 2022, those Stats and references to Rinkeby, Ropsten, and Kovan will be removed from the Stats page.
Is Infura supporting an Ethereum Proof of Work fork?
Infura is supporting the Ethereum roadmap as stated, which means that Ethereum will merge to Proof-of-Stake at TTD 58750000000000000000000. Our Ethereum API will give users access to the Execution Layer API for Ethereum once the Merge occurs. We are excited for this moment!
In short, we are not supporting Proof-of-Work forks of Ethereum at the Merge.
What is the difference between a validator and a staker?
As discussed in our Merge Weekly Workshop: Running Multiple Validators and Staking-as-a-Service
- Validators are entities responsible for agreeing about the state on a Proof of Stake network
- In a permissionless network like Ethereum, they place some ‘value’ at risk to ensure they are honest. The Ethereum Proof-of-Stake Protocol requires 32 Eth per validator.
- Stakers are people or companies that lock their Eth in a validator
What is MEV and the impact that the Merge will have on MEV?
Originally coined as the term Miner Extratable Value in the Flashboys 2.0 paper, MEV now stands for Maximal Extractable Value. It is the additional value extracted from transactions by including them in a block. MEV will continue to exist after the Ethereum Merge occurs.
We had an in-depth discussion of MEV in our Merge Weekly Workshop on MEV Considerations and Factors, along with further definitions and an overview of MEV both historically and its relationship to Ethereum post-Merge.
Additional resources
Across all our workshops we have shared a variety of resources and have organized each to make them easy to access and learn from. These include all sources that we used to host all workshops, and by extension, this blog post.
General Merge Resources
CONSENSYS MERGE KNOWLEDGE BASE
https://consensys.net/knowledge-base/the-merge/
ETHEREUM FOUNDATION WEBSITE
https://ethereum.org/en/upgrades/merge/
MEGA MERGE RESOURCE LIST
https://notes.ethereum.org/Moiv99h9QTmI-imPL8pvQg?view
Ethereum History
https://ethereum.org/en/history/
All Core Devs Updated 007
https://tim.mirror.xyz/sR23jU02we6zXRgsF_oTUkttL83S3vyn05vJWnnp-Lc
BEACON CHAIN KNOWLEDGE BASE
Dapp Developer / Smart Contract Developer Resources
HOW THE MERGE IMPACTS ETHEREUM’S APPLICATION LAYER
https://blog.ethereum.org/2021/11/29/how-the-merge-impacts-app-layer/
Infura
Infura Ethereum API Documentation
https://docs.infura.io/infura/networks/ethereum
TRUFFLE
TRUFFLE DOCUMENTATION
https://trufflesuite.com/docs/
MetaMask
METAMASK DOCUMENTATION
https://docs.metamask.io/guide/
Staker Resources
Ethereum Launchpad
https://launchpad.ethereum.org/en/
SOLO STAKE YOUR ETH GUIDE
https://ethereum.org/en/staking/solo/
Codefi Staking
https://consensys.net/codefi/staking/
MEV Resources
ETHEREUM FOUNDATION WEBSITE
https://ethereum.org/en/developers/docs/mev/#miner-extractable-value
BLOGS, ARTICLES, VIDEOS
The Hidden World of Ethereum Snipers
Maximal Extractable Value (MEV) in Eth2
Flashbots Proof of Stake Architecture
Proposal/Builder Separation (PBS)
Increasing Censorship Resistance under PBS
The Hitchhiker’s Guide to Ethereum
CODE & SITES