As we enter the Web 3 era, Ethereum remains a leader.
Written by: Christine Kim, Galaxy
Compiled by: Bai Shui, Golden Finance
In this report, we will outline the Pectra upgrade and its anticipated timeline for mainnet activation as of October for validators, ETH holders, and investors. Finally, the report shares insights into parallel protocol development alongside Pectra, such as historical expirations, built-in proposer builder separation (ePBS), and Verkle tree migration.
How it Starts
Prague-Electra, abbreviated as 'Pectra,' is the name of the next Ethereum upgrade. Aside from the name, all other details regarding the upgrade have been continuously changing since developers began planning it as early as November. However, when discussing what to include in Pectra, it became clear that developers should reach consensus on the protocol's top priorities outside of the Verkle transition. Developers unanimously agree that the Verkle transition should be the focus of upgrades after Pectra, but it remains unclear what code changes should be prioritized before Verkle.
As background, the Verkle transition is a significant reform of Ethereum's state data structure. State refers to the current balances of all Ethereum accounts, the contract code that controls them, and stored data. Developers plan to migrate all state data from the Merkle Patricia Tree structure to the Verkle structure. This will enable nodes to generate smaller proofs about state data and pass them more easily to other nodes. In the future, developers envision nodes run by users not having to maintain Ethereum's state records, referred to as 'stateless clients.' These lightweight nodes, which can run on resource-constrained devices, will receive the necessary information to validate blocks and rely on proofs generated by other nodes in the network that store state records (called 'stateful clients') to advance the chain. Essentially, the Verkle transition aims to improve Ethereum's decentralization by making it easier for users to run nodes.
Due to the complexities of restructuring Ethereum's state database, developers agreed to reserve the next upgrade after Pectra (named Fulu-Osaka, abbreviated as 'Fusaka') solely for Verkle. They agreed that Verkle would not introduce any other significant changes to the protocol to minimize the technical risks of implementing the upgrade. Developers anticipate that Pectra is a small upgrade they can easily complete before focusing fully on the more challenging task of implementing the Verkle transition.
How is progress
By the end of August 2024, based on the number of Ethereum Improvement Proposals (EIPs), Pectra will be the largest upgrade in Ethereum's history. Developers agreed to include 20 EIPs in Pectra and considered adding more EIPs to the list in early September. However, the large scope of Pectra has been a source of contention and concern among Ethereum developers and other stakeholders. Due to its size, Pectra requires extensive testing and simulations to ensure that the planned implementation of the 20 EIPs does not contain hidden bugs or vulnerabilities, especially when implemented in tandem.
As early as May 2024, a group of Ethereum Foundation engineers responsible for organizing Ethereum upgrade testing, the EthPandaOps team, shared a blog post suggesting splitting the Pectra upgrade into two. At the time, the idea was not taken seriously due to concerns that it could delay the planned Verkle transition after Pectra activation. Ethereum Foundation researcher Alex Stokes brought this idea up again during the All Core Developers Execution call #196 in early September. This time, developers were more in agreement, insisting that doing so would allow them to deliver the first part of the upgrade within six months.
Therefore, all EIPs included in Pectra are planned to be implemented across two hard forks instead of one. The scope of the first hard fork will include 8 of the 20 EIPs from the Pectra list. For the remaining 12 EIPs on the list, developers will continue to develop them in parallel so that they can be implemented on the mainnet after the initial 8 EIPs.
Pectra Overview
As of October 2024, developers have agreed to expand the scope of Pectra to include an additional code change, EIP 7742. Including this code change in Pectra makes it possible for developers to also increase blob capacity in Pectra. There are now nine EIPs. The Pectra upgrade is tentatively scheduled to activate on the mainnet in early 2025 and may include the following 10 code changes:
Overall, Pectra includes a series of updates for Ethereum that are expected to achieve three outcomes:
Fixing the protocol as a key flaw of the proof-of-stake blockchain
Improving the user experience (UX) when interacting with smart contract applications on Ethereum
Enhancing Ethereum's data availability capabilities
On the surface, the user experience improvements and enhancements to Ethereum as a DA layer are designed to encourage end users to interact with smart contracts on rollups in a cheaper manner rather than directly on Ethereum. However, improvements in Ethereum's user experience may create a 'trickle-down effect,' meaning that due to their implementation on the mainnet, they are likely to be adopted by Rollups, benefiting both Rollup and Ethereum end users.
Notably, Pectra does not contain any code changes aimed at reinforcing ETH as a 'sound currency' or a store of value. Furthermore, no single EIP can directly improve Ethereum's quality as a censorship-resistant blockchain, an issue that has become a priority for developers to address since the merge upgrade, due to the increased number of known regulated entities participating in the block-building process.
Over 50% of blocks on Ethereum are generated by relays compliant with OFAC standards, meaning that the entities responsible for creating these blocks deliberately exclude transactions interacting with Ethereum addresses listed in the US market.
Developers are working on code changes to reduce ETH issuance and improve censorship resistance in future upgrades. However, these are not the focus of Pectra.
Fusaka Overview
The next upgrade after Pectra will be named Fusaka. As developers have not yet finalized the scope of the upgrade, it is difficult to estimate the timeline for Fusaka. Currently, developers are keen to prioritize the 12 additional code changes originally concentrated in the Pectra EIPs, namely EOF code changes and PeerDAS. However, after the Pectra upgrade is completed, developers will reassess the EIPs based on the priority and readiness for Fusaka.
For reference, below is a list of 12 code changes that were initially included in Pectra but later removed from the upgrade.
Please note that, aside from the first EIP, the other 11 EIPs are code changes that alter various aspects of the Ethereum Virtual Machine (EVM). These EVM-centric code changes collectively realize the 'EVM Target Format' or EOF for short. EOF makes significant changes to how the EVM builds and processes code, and it is expected to improve the experience of smart contract developers by making the execution of smart contract code more predictable, secure, and cost-effective.
Aside from PeerDAS and EOF, below is a list of all potential code changes that could be considered for inclusion in Fusaka as of October 2024:
Aside from account abstraction and Verkle, all initiatives listed above have been discussed as potential candidates for the Pectra upgrade but were not included due to a lack of consensus on the code changes. For many of these initiatives, significant research still needs to be conducted before their designs are ready for implementation. The last column in the table ranks the readiness of the above code changes from 1 to 3, where 3 is ready for immediate implementation and 1 is in the early stages of development.
Among the initiatives mentioned above, the inclusion of the listing and SSZ transition is the most mature. Of all the parallel initiatives, account abstraction is by far the least likely to be ready for Fusaka, as the path to implementing full account abstraction on Ethereum remains unclear, and many parts of that roadmap will be affected by EIP 7702 in Pectra.
Given the uncertainties associated with these parallel initiatives, it is currently useless to assess their readiness for the mainnet or their impact on ETH value. However, by 2025, a series of 10 code changes are likely to affect Ethereum stakeholders.
The next part of this report will explain in more detail the expected impact of EIPs in Pectra on network stakeholders and ETH value.
Critical and non-critical fixes
There is one EIP in Pectra that is critical for the operation of Ethereum as a proof-of-stake blockchain. EIP 7251 increases the maximum effective balance of validators from 32 ETH to 2048 ETH and allows existing validators with a maximum effective balance of 32 ETH to consolidate their stakes. This is expected to reduce the number of Ethereum validators, which exceeded 1 million as of September 2024.
Simulations conducted by Ethereum Foundation (EF) engineers have shown that the protocol encounters serious network issues at 1.4 million validators. EIP 7251 is expected to alleviate network pressure by encouraging the consolidation of staked ETH. For more information on issues related to the size of large validator sets, please read this Galaxy Research report.
Fundamentals behind 32 ETH validators
The beacon chain was initially designed for validators with a maximum effective balance of 32 ETH, as protocol developers aimed to encourage a significant number of participants to engage in the proof-of-stake consensus protocol. Developers conservatively estimate that with 32 ETH, the beacon chain will attract approximately 312,500 validators, whose aggregated cryptographic signatures will be sufficient to secure the nascent chain.
When the beacon chain launched in December 2020, the price of ETH was around $600, meaning users with less than $20,000 could run their own validators and earn staking rewards independently. At that time, staking rewards did not include transaction fees or MEV rewards, and staking carried considerable risks as users could not withdraw their funds.
In addition to encouraging participation, the choice of a 32 ETH effective balance is due to the original design of the beacon chain requiring each validator to maintain the same effective balance for 'sharding' scalability. If all users need to maintain a staking balance above 32 ETH, developers would worry about not having enough validators to secure the chain. If all users maintain their staking balances below 32 ETH, there are concerns about an overabundance of validators, unnecessarily burdening the Ethereum network layer.
In addition to the maximum effective balance of 32 ETH, developers have set a number of other constants and parameters in the protocol based on rough estimates of Ethereum's future staking needs. If developers' estimates are significantly inaccurate, they believe that adjustments to the chain's economics and staking parameters can be made through subsequent hard forks. The rapid adoption of liquid staking solutions like Lido and Coinbase has sparked discussions among developers about lowering Ethereum's issuance curve.
Finally, there may be erroneous assumptions about the actual capacity of the Ethereum network layer. Ethereum founder Vitalik Buterin wrote in a blog post in 2021 that the design specifications of the beacon chain could realistically support the overhead of 4.1 million validators or stake the entire ETH supply with a maximum effective balance of 32 ETH. In reality, due to various upgrades and changes in client implementations, the Ethereum network layer is unlikely to support 1.4 million validators, let alone over 4 million.
Implementation details of EIP 7251
EIP 7251 is a complex code change that needs to be implemented. It fundamentally alters the way the protocol calculates validator rewards, penalties, and withdrawals. The protocol will make these calculations based on the combined effective balance of validators rather than the number of active validators, with each validator's effective balance ranging from at least 32 ETH to 2048 ETH.
Particularly in the process of changing the relevant reduction penalties, developers found an edge case where validators with smaller effective balances would be disproportionately penalized compared to those with larger effective balances. This edge case has been addressed during Pectra testing. As of October 2024, developers are still identifying errors in the EIP 7251 specification and are committed to resolving these issues.
In addition to updating calculations, the EIPs also introduce new operations for validators to consolidate existing validators and reduce the initial reduction penalties for validators with larger effective balances to encourage consolidation.
Once activated, it remains unclear how quickly large staking entities will be able to integrate their validators and reduce network pressure. There are concerns that any peaks in validator set size from now until the integration of validators takes effect could negatively impact the network health and the participants operating validators in resource-constrained hardware or internet bandwidth-limited locations.
The following graph illustrates the growth in the number of active validators since the Dencun upgrade. The Dencun upgrade refers to the maximum number of validator entries per epoch on Ethereum being reduced from 15 to a constant value of 8. The following projections provide an estimated entry loss rate of the Ethereum validator set based on the activity of new validator entries since the validator. Notably, the following projections are conservative and do not account for potential future staking demand catalysts, such as the maturation of re-staking protocols like Eigenlayer on Ethereum.
Non-critical fixes
Aside from EIP 7251, the protocol has some non-critical fixes and improvements that will be activated in the Pectra upgrade. They include:
EIP 7549, moving committee index off-chain – to make CL client software more efficient, this code change introduces a restructuring of validator proof messages. It is expected to reduce network load on validator nodes, albeit to a lesser extent than EIP 7251.
EIP 6110, providing validator deposits on-chain – this code change shifts the responsibility of validating new staked ETH deposits from CL to EL. By doing so, developers can enhance deposit security, reduce protocol complexity for CL clients, and improve the staking user experience by reducing the delay between depositing 32 ETH on EL and activating new validators on CL.
EIP 2935, providing historical block hash values from state – introduces changes to EL so that historical blocks can be generated from state. It may provide some additional functionality for smart contract developers, as they will be able to access information about Ethereum state from previous blocks. Primarily, this is a necessary code change to prepare for the Verkle transition.
EIP 7685, universal execution layer requests – creates a universal framework for storing requests to CL triggered by smart contracts. As smart contract staking pools become increasingly popular, there is a need to enable smart contracts to directly trigger validator withdrawals (EIP 7002) and merges (EIP 7251) on CL. This code change introduces a protocol framework to store these types of requests for easy handling by CL.
Expected Impact
The critical and non-critical fixes activated in Pectra will primarily affect validator node operators, who will need to update their operations to leverage the higher effective balances of EIP 7251, efficiency improvements from EIP 7549, and minor user experience enhancements from EIP 6110. The former will benefit node operators in future upgrades when stateless clients become a reality, while the latter improves the implementation of code changes like EIP 7251 but does not otherwise enhance the current state of the network.
End users and ETH holders are not expected to directly benefit from these five code changes. These changes primarily benefit the health and resilience of Ethereum as a proof-of-stake blockchain. In the long run, they hold a positive outlook on the protocol's value, as they ensure that the protocol can continue to operate securely and smoothly. However, they do not introduce new features that can substantially improve the user experience for end users, smart contract developers, or rollups. Therefore, they are not expected to have a significant impact on ETH value.
As with any network-wide upgrades on Ethereum, volatility in ETH may increase before and after Pectra, and prices may experience negative fluctuations if any unexpected errors or failures related to the upgrade occur. It is important to clarify that given the extensive battle testing these code changes have undergone before activation on the mainnet, the likelihood of the Pectra upgrade being unsuccessful is minimal. Therefore, unless there are temporary fluctuations in ETH before and shortly after the upgrade, the code changes related to various parts of the fixing protocol in Pectra are not expected to have a long-term positive or negative impact on ETH value.
Affected stakeholders: validator node operators
Expected impact on ETH: neutral
User experience improvements
Pectra includes three EIPs that will introduce user experience improvements for Ethereum's end users and smart contract developers. While pursuing a rollup-centric roadmap, developers are also working together to enhance Ethereum's value proposition as a leading general-purpose blockchain.
EIP 2537, precompiled operations for BLS12-381 curve – adds new functions to efficiently perform operations on the BLS12-381 curve, an algebraic structure widely used in zero-knowledge cryptography. Zero-knowledge cryptography can provide numerous benefits for blockchain-based applications, including stronger privacy guarantees, security, and scalability. The ability to perform operations on the BLS curve will benefit applications and rollups built on Ethereum that have already used zero-knowledge proof systems or are seeking to integrate such systems into their operations.
EIP 7002, a withdrawal triggered at the execution layer – EIP 7002 creates a stateful precompile, a mechanism for modifying the EVM state for validator withdrawals. Currently, validators on the beacon chain can only exit through the intervention of the validator withdrawal key owner, usually the operator of the validator. EIP 7002 introduces a smart contract mechanism that can own validator withdrawal credentials and use them to trigger validator exits without the manual intervention of the validator operator. It will provide more trustless designs for staking applications and allow existing staking applications to eliminate the trust assumptions about the honest behavior of their validator node operators and the security of these applications.
EIP 7702, set EOA account code – create a new transaction type for end users to add short-term features to Ethereum accounts they control, such as:
Transaction batching, authorizing multiple on-chain operations by signing a single transaction
Sponsorship, paying transaction fees on behalf of another account
Permission degradation, conditions for specific expenditures of authorized account balances
Given that most users execute transactions on Ethereum through wallet providers, wallet developers will need to leverage new transaction types and incorporate these functionalities into their designs in a way that users can easily access.
Expected Impact
Unlike critical and non-critical fixes, these code changes will directly enable more complete application development on Ethereum. EIPs such as 7002, 2537, and 7702 will implement a more trustless staking pool design, enhanced privacy for decentralized finance protocols, and secure user-controlled accounts, respectively.
Affected stakeholders: end users, smart contract developers
Expected impact on ETH: positive
DA improvements
As mentioned earlier in this report, another code change may be included in Pectra. Developers are considering a slight increase in blob Gas targets to enhance Ethereum's scalability as a data availability (DA) layer. Several larger, more complex code changes are related to improving DA capabilities through the EIP 7594 (PeerDAS) upgrade. However, since EIP 7549 will no longer be activated in Pectra, there are suggestions to introduce simpler changes to lower DA costs.
Currently, Ethereum can handle a maximum of 6 blobs per block, dynamically adjusting the cost of these blobs to aim for an average of 3 blobs per block. A proposal by Layer-2 rollup developer Francis Li is to increase the target number of blobs per block to 5, raising the maximum number of blobs per block to 8.
In Li's proposal, he noted that even conservatively increasing the target blob count to 4 instead of 3 would assist in building Rollup teams on Ethereum. Developers largely support increasing Pectra's blob target. However, confirmation of this viewpoint and the formal inclusion of DA improvements in Pectra remain to be decided in future ACD calls. Currently, developers have agreed to include EIP 7742 in Pectra, which will pave the way for changing Ethereum's blob capacity through CL adjustments.
EIP 7742, decoupling blob counts between CL and EL – maximum and target blob limits are continuously hard-coded in both EL and CL. EIP 7742 allows CL to dynamically adjust maximum and target blob limits so that future changes to DA capacity do not require hard forks on both layers but can be adjusted specifically through CL.
In addition to EIP 7742 and blob capacity increases, developers are weighing two additional code changes related to optimizing Ethereum's DA capabilities in Pectra or Fusaka:
EIP 7762, increase MIN_BASE_FEE_PER_BLOB_GAS – when the demand for blobs exceeds the target rate (currently 3 blobs per block), the protocol will automatically adjust the mandatory base cost of blobs upwards. EIP 7762 raises the minimum base cost for blobs so that the blob fee market can respond more sensitively to fluctuations in blob demand and achieve price discovery for blobs more quickly.
EIP 7623, increasing call data costs – aside from blobs, rollups can also publish arbitrary data to Ethereum using the call data field of transactions. However, utilizing the call data field of transactions is generally more expensive for rollups. EIP 7623 aims to further increase the cost of call data to reduce the maximum size of Ethereum blocks. As Ethereum developers increase block size by enhancing blob capacity, they hope to prevent edge cases where validators containing a large amount of call data and the maximum number of blobs propagate excessively large blocks.
Increasing blob throughput in Pectra is a contentious topic among developers, as it may reduce the number of independent stakers operating on the network, adversely affecting Ethereum's decentralization. Independent stakers are users who stake their own ETH and run their staking operations at home or through cloud providers, rather than relying on staking pools or other intermediary services. Compared to other types of stakers, independent stakers operate validators on the most resource-constrained devices.
An increase in blob throughput may raise the computational requirements for operating validators, potentially leading some individual stakers to shut down their machines. In ACDE #197, developers shared anecdotal evidence indicating that some individual stakers have struggled to operate after the Dencun validator. Developers have agreed to conduct data-driven research on the health of individual staking operations before deciding to increase Pectra's blob capacity.
Expected Impact
In the short term, Ethereum's DA improvements are expected to reduce protocol revenue from Layer-2 rollups (L2), increase the profit margins of L2 sequencers, and lower transaction fees for L2 end users. These impacts are expected to be similar to those observed after the activation of EIP 4844 in the Dencun upgrade.
Affected stakeholders: Layer 2 rollups, L2 end users, ETH holders
Expected impact on ETH: negative
Pectra Timeline Analysis
Developers have discussed two alternative code changes to include in Pectra in case changes to the blob fee market are ultimately not included in the upgrade. As the blob capacity in Pectra may increase, these two code changes are less likely to be included in Pectra. They are EIP 7782 and
EIP 7782, proposed by Nethermind developer Ben Adams, reduces Ethereum's slot time from 12 seconds to 8 seconds. This change in slot time will effectively increase Ethereum's transaction throughput by 50% and reduce transaction confirmation times by 33%. Developers raised concerns during ACDE #198 and ACDC #144 regarding this proposal, suggesting that it could accelerate the rate of state growth, making the Verkle transition more challenging. Additionally, Ethereum Foundation researcher Francesco D'Amato indicated that a change in slot time could negatively impact positive research initiatives such as built-in proposer builder separation (ePBS) and inclusion lists (IL).
EIP 7783, proposed by Erigon developer Giulio Rebuffo, is a relatively easier code change for developers to implement as it does not require a hard fork. EIP 7783 creates a mechanism for client teams to gradually increase Gas targets over time. Increasing Gas targets will raise the maximum number of transactions that can be included in a block. Rebuffo's proposal did not specify specific Gas targets but suggested a mechanism for developers to choose targets and gradually increase them safely to this threshold. In a recent call in October 2024, developers discussed the potential for implementing EIP 7783 shortly after the Pectra upgrade.
The addition of any new EIPs in Pectra could delay the mainnet activation of the upgrade. Moreover, the longer developers delay finalizing the scope of Pectra, the longer it will take them to upgrade the public Ethereum testnet. As of October 2024, developers do not appear to be close to finalizing the scope of Pectra. Therefore, the public testnet upgrade for Pectra is unlikely to go live before the end of this year.
Assuming the scope of Pectra is finalized by January or early February next year, developers will need to test any new content of Pectra on a private test network (also known as a development network) before proceeding to upgrade the public Ethereum testnet. At least a month’s budget should be reserved to test other code changes in Pectra, and developers are advised that they can start the public testnet upgrade in March to tentatively activate the mainnet upgrade sometime in April or May.
These timelines are estimates and may change based on the timing of developers finalizing the scope of Pectra in the coming months and the complexity of the code changes they decide to ultimately add to the upgrade.
Other catalysts for ETH value
So far, Pectra is a mixed code change, with some expected to enhance the experience for users and smart contract developers. Since the scope of Pectra has been simplified, this upgrade is not expected to have a significant impact on ETH value. Besides Pectra, Ethereum has more follow-up updates that may more directly affect ETH value, such as reducing issuance and implementing PeerDAS initiatives. However, as noted earlier in this report, it is difficult to predict when these changes can be activated on the mainnet.
It is noteworthy that as Ethereum pursues DA scalability improvements under the 'rollup-centric roadmap,' the impact of protocol upgrades on ETH value should diminish over time. In the long run, as applications and users migrate to L2, Ethereum's revenue may primarily be driven by user activity on L2. Upgrades occurring on L2 can enhance user experience, interoperability, decentralization, and security on those networks, which are more critical to Ethereum's value than optimizations and improvements at the base layer. While upgrades like Pectra will further enhance the protocol's decentralization and usability, they are unlikely to attract a new wave of users and drive the adoption of decentralized applications, as Rollups can scale to meet this demand while Ethereum cannot. Therefore, when assessing the factors driving ETH value, applications built on Rollup and protocol upgrades based on Rollup (which further enhance the capabilities of applications built on Rollup) are key to the analysis.
A common resistance to the rollup-centric roadmap is the concern that Ethereum may become too cheap due to the DA layer, or that revenue from Rollups may be too low to sustain ETH value. These arguments underestimate the overall potential market for decentralized applications. Currently, the use cases for cryptocurrency are disrupting every industry in the world, as public blockchains have the potential to fundamentally change human coordination activities, just as artificial intelligence (AI) has the potential to disrupt every industry by fundamentally changing the way digital content is generated.
While scalability improvements like EIP 4844 or PeerDAS will reduce protocol revenue in the short term, they are laying the groundwork for Ethereum to support more on-chain activity than Ethereum L1. Gaming, fundraising, decentralized finance, and social media are just a few examples of application types that have historically driven spikes in Ethereum's transaction volume and fees. These applications leverage Ethereum's network effects, decentralization, censorship resistance, and composability. Theoretically, aside from significantly lower costs and enhanced functionalities (such as different types of virtual machines, programming languages, and account management), applications on rollups will be able to leverage all these advantages on Ethereum.
However, in practice, rollups do not meaningfully inherit properties such as decentralization, censorship resistance, or composability from Ethereum. While they can effectively lower transaction costs, they do so at the expense of decentralization and security. In other words, aside from reducing transaction costs, rollups do not meaningfully scale Ethereum. Users have to weigh too many trade-offs when migrating their activities and applications from L1 to L2. Infrastructure projects like Rollups developed on alternative layer 1 blockchains and rebonding solutions and ZKVM are underway. Pure DA improvements may not drive a new wave of adoption for Ethereum or Rollups built upon it until Rollup technology matures and benefits from Ethereum's decentralized characteristics.
Conclusion
Despite uncertainties surrounding the scope and timeline of Pectra, Ethereum remains a leader as we enter the Web 3 era, where human coordination primarily occurs through decentralized blockchain technology rather than centralized internet protocols. To achieve this goal, Ethereum must continue to scale as a decentralized technology while combating centralized forces such as maximum extractable value (MEV) and transaction censorship regimes. While Ethereum certainly faces competition in achieving this vision, it remains a zero-sum game for Ethereum to dominate the Web 3 blockchain space.
Ethereum continues to maintain the highest network effects among all general-purpose blockchains. For smart contract developers, it remains the most battle-tested blockchain and the most researched blockchain among researchers and developers for addressing challenges related to scalability, MEV, censorship, user experience, and more. However, as Ethereum developers pursue a rollup-centric roadmap, the importance of Ethereum as a technology and the significance of Ethereum upgrades are likely to diminish, as solutions to the biggest challenges facing Web 3 will be inherited by Rollups.
Pectra will introduce user experience-centered code changes expected to attract new users and smart contract developers into the Web 3 realm. However, this may be one of the last few upgrades where code changes on the protocol directly impact users and ETH holders. As users migrate to Rollup, protocol revenue is increasingly driven by activity on Rollup, and the most crucial code changes for Ethereum stakeholders will be code changes made on Rollup. To this end, it is essential to analyze the maturity of Rollup as a technology and its ability to meaningfully inherit Ethereum's security and scale to millions of new users.
