A Step-By-Step Overview of Ethereum’s Merge Upgrade and Associated Risks
The Merge upgrade is Ethereum’s long-awaited transition from a proof-of-work (PoW) consensus protocol to proof-of-stake. As the network’s most complex and radical code change to date, the activation process for the Merge is unlike any previous hard fork procedure completed on Ethereum. It contains three main steps and requires node operators to begin operating two software clients, as opposed to one. This report dives into how the Merge upgrade will be activated on Ethereum and what execution risks are associated with this unprecedented code change.
Introduction
Developers are preparing to implement Ethereum’s most ambitious hard fork upgrade known as the Merge. The upgrade will overhaul Ethereum’s existing proof-of-work (PoW) consensus protocol to a new proof-of-stake (PoS) consensus protocol and in doing so, significantly change all core functionalities of Ethereum including block production, transaction finalization, and network issuance. As the world’s largest general purpose blockchain by market capitalization, as well as total value locked, there is a lot of value and reputation at stake for Ethereum as it undergoes such a massive transition.
Read our other coverage on Ethereum’s forthcoming merge upgrade here:
Ethereum All Core Developers Call #140 & Consensus Layer Call #89 Writeup
Ethereum All Core Developers Call #139 & Consensus Layer Call #88 Writeup
In this report, we look at the execution risks associated with Ethereum’s Merge upgrade. To understand the risks associated with the Merge, it is important to first understand the processes that will take place to initiate this transition to PoS.
How the Merge Works
Currently, transactions on Ethereum are finalized through a Proof-of-Work (PoW) consensus protocol known as ethash. Running in parallel to Ethereum’s PoW chain is the Beacon Chain, a separate blockchain that has been running Ethereum’s new Proof-of-Stake (PoS) consensus protocol, Gasper, since December 2020.
The goal of the Merge is to fuse together both chains such that Ethereum’s existing blockchain (currently PoW) relies exclusively on the Beacon Chain for creating network consensus and jettisons proof-of-work entirely. Ethereum as we know it today will cease processing transactions through ethash and function only as an execution layer (EL) for decentralized applications (dapps) and users to broadcast their transactions. The Ethereum Virtual Machine (EVM), which is the computation engine of Ethereum, will continue to be operate and function on the EL as normal.
The Beacon Chain will become Ethereum’s consensus layer (CL) where transactions from the EL are sent, processed, and ultimately finalized. It will become the responsibility of Beacon Chain validators to bundle EL transactions into blocks and finalize them through Ethereum’s PoS consensus protocol, Gasper. To follow along with the Ethereum chain post-Merge, all validators and full node operators will be required to operate two software clients, an EL and CL client.
Three Main Steps to Activate the Merge
Step One: Bellatrix
First, the CL of Ethereum undergoes a hard fork known as Bellatrix. The Bellatrix upgrade on the CL implements a new Beacon Chain block structure to accommodate blocks containing transactions initiated on the EL. It also contains instructions so that CL nodes do not begin filling up Beacon blocks with EL transactions until a specific Terminal Total Difficulty (TTD) is reached on the EL. All CL nodes will be required to upgrade to Bellatrix by a specific slot height, which is equivalent to a block height on a PoW chain. Once the Bellatrix hard fork is complete on the CL chain, CL nodes will begin listening for a TTD.
Step 2: Reach TTD
The terminal total difficulty (TTD) is a measure of the accumulated mining difficulty of the EL of Ethereum. Difficulty in this context refers to how hard it is for miners to append a new block to the blockchain and represents the number of combinations that a miner usually needs to guess to find the correct hash for creating the next block. Difficulty automatically increases as the computational power, also called hashrate, being expended by miners to process blocks on Ethereum grows. TTD is calculated by summing up the mining difficulty of all previous blocks in Ethereum’s history. Historically, hard fork activations on the EL have not relied on reaching a specific TTD, but rather on a predetermined block height. This method has been abandoned for the Merge because of the potential for a “fast fork” attack, where a potential attacker could use a minority of hashrate to fork the EL and mine to the designated block number faster than the canonical chain.
If such an attack were to occur, the CL could mistakenly activate the Merge with the attacker’s minority chain rather than the canonical chain. Thus, developers have opted to use TTD as a threshold for activating the Merge, given that it is significantly harder to manipulate by bad actors. However, one downside to using TTD as the threshold for activating the final steps of the Merge upgrade is that TTD is a difficult value to predict. This makes predicting the timing of the Merge activation process after the Bellatrix hard fork also a tricky and inaccurate science. The consequences of inaccurately predicting when TTD will be hit were made evident when core developers first tried to activate the Merge on the Ethereum test network known as Ropsten.
The original TTD value for Merge activation on Ropsten was reached two weeks earlier than anticipated due to the mining activity of one Ropsten miner who caused hashrate to soar 20x overnight. This caught developers off guard as they had not expected the TTD to rise so dramatically in such a short period and had not by that time launched a dedicated Beacon Chain for the Ropsten test network. As such, developers were forced to issue an override to the original TTD value set in Ropsten nodes. After this incident, developers have agreed to issue two TTD values in the Merge activation process to introduce more predictability to Merge activation timing.
The first TTD will be an extremely high and unreachable value that is later overridden with a second TTD value after the Bellatrix upgrade is complete. Once CL nodes are ready for Merge activation through the Bellatrix hard fork, they will be fed a second TTD value that is more accurately calculated based on the latest trends in mining activity and hashrate. The second TTD will not require node operators to issue another full upgrade to their EL and CL client software. Node operators will be able to manually override the first TTD value through adding a single line code.
On test networks in particular, this dual TTD value method is meant to deter bad actors from attempting to game the TTD by making it impossible to reach the specified TTD too early. However, on mainnet where it is significantly more difficult for one miner to influence the TTD, developers have agreed that it is best practice to follow the same procedure for Merge activation as practiced on testnets to not introduce any new variables to the mainnet Merge activation process. Once a TTD value is reached on the EL chain, the last and final step of the Merge activation is triggered; that is, the Paris upgrade.
Step Three: Paris
The second upgrade to release in the Merge activation process is the Paris hard fork, which is for the EL nodes. Paris contains two Ethereum Improvement Proposals (EIPs) targeted at upgrading the EL chain. The first proposal is EIP-3675 which simply removes dependance on the PoW mining algorithm ethash and introduces new dependencies on the activities of the Beacon Chain. The second proposal is EIP-4399, which changes the way randomness is generated on chain and abandons the dependency on mining difficulty to generate random integers for dApps. Both EIPs get activated once the TTD threshold on the EL is reached. In addition, the CL nodes that have been waiting and listening for this TTD value from the EL also begin processing transactions from the EL at this moment.
Client Releases
It is important to also note the timing of client releases and communication to stakeholders about each step of Merge activation. In preparation for the Bellatrix hard fork, the Ethereum Foundation is expected to release a blog post containing the client releases for both the Paris and Bellatrix upgrades a few weeks in advance for node operators to start downloading. These initial client releases for EL and CL nodes will contain the abnormally large TTD value as a placeholder. Since the Bellatrix hard fork activates at a specific slot height, the date and expected time of this upgrade will also be communicated to stakeholders.
Once the Bellatrix upgrade is complete on the CL, a new TTD value will be communicated again through a blog post to node operators for a second time. This new TTD value will not require node operators to issue another full upgrade to their CL or EL software clients. It will only require, at the minimum, a manual override to the previous TTD value through the addition of a single line of code in both the CL and EL software clients. There may be an optional upgrade for CL or EL software clients available to node operators at this point to download, but this will be at the discretion of each independent client team and will by no means be a mandatory release needed to follow along with the final steps of Merge activation.
Once the TTD override is communicated, there will be a period of waiting for the new TTD threshold to be met. While there will be rough estimations for when the TTD value is expected to hit, the precise date and time for Paris activation, which depends on a TTD, will not be known. Ideally, the period between activation of Bellatrix and Paris will only last between one to two weeks. Post-Merge, all Ethereum validators and full node operators will be required to operate two nodes, an EL and CL node.
Execution Risks Associated with Merge Activation
Given the complex nature of this transition to PoS and all the moving parts between the EL and CL, the following are four primary risks associated with executing the Merge activation:
Miscommunication/Lack of communication. Communication is key to ensuring a smooth Merge activation process. Node operators will need to be especially attentive to the messages being relayed from EL and CL client teams given that there will be multiple action items for operators to adhere to on a strict timeline. Any confusion about the correct TTD value, the expected ETA for reaching TTD, or deliberate misinformation being spread by malicious actors about either of these topics could cause a portion of validators on the Beacon Chain and node operators on the EL to fail to upgrade for the Merge. If a large portion of nodes fail to upgrade due to confusing messaging around when and how to follow along with Merge activation, this could stall network consensus and temporarily halt on-chain transaction activity.
User error. Even with clarity from client teams around how to upgrade nodes for the Merge and effective campaigning against misinformation about the Merge upgrade process, there is the possibility of user error. Given there are multiple stages to Merge activation, it is possible that node operators mistakenly enter an incorrect TTD value or fail to give enough time for their CL nodes to sync before TTD hits on the EL. The burden on node operators to do more than simply upgrade their machines before a specific block height may cause a portion of nodes on Ethereum’s EL and CL to drop off unintentionally at some point during the Merge transition. As explained above, if enough nodes fail to upgrade for the Merge, this could have dire consequences on network consensus and transaction finalization in the near term.
Client failures. Over the course of multiple developer test networks, 7 mainnet shadow forks, and a public testnet launch of the Merge on Ropsten, developers have been battle-testing the EL and CL client releases for the Paris and Bellatrix upgrades, as well as the software that will facilitate communication between EL and CL clients known as the Engine API. As of June 27, client teams are working to resolve various bugs and issues in their implementation of the Bellatrix and Paris upgrades. In addition, client teams are working on the Engine API, which is a software to support more efficient communication between EL and CL software clients. While the likelihood of a new bug being discovered in a client release or the Engine API is unlikely, there is the potential as with any man-made software that some aspect of the release is overlooked and causes a portion of nodes to drop off from the network during the Merge activation process. The consequences of a bug in a client release on the network will vary depending on how widely used a certain client software is. In lead-up to the Merge, there has been a lot of effort and campaigning within the Ethereum community to diversify client software usage on both the EL and CL. It is expected that there will be four production-ready EL clients and four-production-ready CL clients for users to choose when upgrading their infrastructure for the Merge.
Services and applications breaking down. There is a vast ecosystem of both centralized and decentralized services and applications being run atop Ethereum. As much as developers insist the operations of the EL will remain largely the same for these applications and services running on Ethereum post-Merge, there may be repercussions from changes in CL operations that ultimately impact existing infrastructure. Consider the case of staking-as-a-service businesses that stake ETH on behalf of users. After the Merge, priority fees and MEV from processing transactions will be awarded to validators. These earnings will be immediately liquid and available for validators to transfer to other accounts on the EL. This is because earnings from priority fees and MEV will be automatically deposited to validator accounts on the EL, not the CL. Validator earnings from new ETH issuance on the Beacon Chain will, however, remain illiquid after Merge activation is complete. A subsequent hard fork will be required to enable withdrawals of staked ETH and new ETH issuance on the Beacon Chain. For more information about validator reward dynamics post-Merge, read this Galaxy Digital research report. There is the potential that existing infrastructure in certain staking-as-a-service businesses are not set-up to support the distribution of staking rewards from MEV and priority fees post-Merge. They must update how rewards from staking are doled out to their users to ensure their services as a staking platform are functioning appropriately. In addition, some decentralized applications on Ethereum may need to update their assumptions about block times and transaction confirmation speeds. Post-Merge, blocks will begin finalizing in slots and epochs, instead of block heights. A slot is processed by validators every 12 seconds, and an epoch, which is a bundle of 32 slots, is reached every 6.4 minutes. Finality for transactions on the Beacon chain is reached after 2 epochs, which is approximately 12.8 minutes. For exchanges, DEXs, and other DeFi applications that may operate on different assumption for transaction finality and confirmation speeds, these upcoming changes to the network must be anticipated and prepared for in advance to prevent any functionality from breaking or being exploited.
Conclusion
Ethereum’s transition from Proof-of-Work to Proof-of-Stake is the most high-profile and consequential layer 1 blockchain upgrade in the history of cryptocurrencies. No network of Ethereum’s size and importance has undergone such a dramatic change. While the likelihood of any of these risks severely impacting Ethereum users and dapps is slim due to the immense amount of testing and preparation being dedicated to the Merge by developers, the execution risks associated with the Merge upgrade described above all have the potential to negatively impact Ethereum’s value and reputation as a general purpose blockchain, especially if any of the potential scenarios that were described end up creating a need for an emergency hard fork on the network to roll back the upgrade.
Thus, all stakeholders should be aware of these risks and take steps to mitigate the impact of any issues on their network usage, such as by halting or freezing deposits and withdrawals during key windows of possible disruption. In addition, validators, dapps, and service providers on Ethereum should prepare for the Merge by participating in forthcoming activations of the upgrade on the Sepolia and Goerli testnets. This will ensure node operators are up to date on best practices when following along with the Merge upgrade and bring to light any issues with the process before mainnet activation. Finally, it will be particularly important for the Ethereum Foundation, client teams, and trusted media outlets to be watchful of misinformation around the Merge during its activation. This means being wary for any incorrect TTD values, client releases, expectations around timing, and necessary action items for relevant stakeholders, as well as coordinating quickly to clearly communicate what stakeholders need to be prepared for next until the Merge upgrade is complete.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsement of any of the stablecoins mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2022. All rights reserved.