Author: Christine Kim, Galaxy; Compiled by: Bai Shui, Golden Finance

Introduction

In this report, we will outline the Pectra upgrade and its expected timeline for mainnet activation as of October, along with implications for validators, ETH holders, and investors. Finally, the report shares insights into parallel protocol development occurring alongside Pectra, such as historical expirations, built-in proposer builder separation (ePBS), and Verkle tree migration.

How it all started

Prague-Electra, abbreviated as 'Pectra,' is the name of the next Ethereum upgrade. Aside from the name, all other details regarding the upgrade have continuously changed since developers started planning as early as November. However, when discussing what should be included in Pectra, it has become clear that developers should reach a consensus on priority issues for the Ethereum protocol beyond the Verkle transition. Developers unanimously agree that the Verkle transition should be a focus of upgrades after Pectra, but it remains unclear which code changes should be prioritized before Verkle.

As background, the Verkle transition is a significant reform of Ethereum's state data structures. The state refers to the current balances of all Ethereum accounts, the contract code controlling them, and the stored data. Developers plan to migrate all state data from the Merkle Patricia Tree structure to the Verkle structure. This will allow nodes to generate smaller proofs about state data and make it easier to pass them to other nodes. In the future, developers envision nodes run by users not needing to maintain Ethereum state records, termed 'stateless clients.' These lightweight nodes, which can operate on resource-constrained devices, will receive necessary information to validate blocks and rely on proofs generated by other nodes in the network that store state records (termed 'stateful clients') to advance the chain. Essentially, the Verkle transition aims to enhance Ethereum's decentralization by making it easier for users to run nodes.

Due to the complexity of restructuring Ethereum's state database, developers have agreed to reserve the next upgrade after Pectra (called Fulu-Osaka, abbreviated as 'Fusaka') specifically for Verkle. They agreed that Verkle would not introduce any other significant changes to the protocol to minimize the technical risks of upgrade implementation. Developers expect Pectra to be a small upgrade that they can complete easily before focusing all attention on the more challenging task of implementing the Verkle transition.

How progress is going

By the end of August 2024, based on the number of Ethereum Improvement Proposals (EIPs), Pectra will become the largest upgrade in Ethereum's history. Developers have agreed to include 20 EIPs in Pectra and are considering adding more EIPs to the list in early September. However, the large scope of Pectra has been a source of controversy and concern among Ethereum developers and other stakeholders. Due to its scale, Pectra requires extensive testing and simulations to ensure that the 20 planned EIPs do 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 parts. At the time, this idea was not seriously considered due to concerns that it might delay the planned Verkle transition after Pectra's activation. Ethereum Foundation researcher Alex Stokes brought up this idea again in early September during the All Core Developers Execution call #196. This time, developers agreed more on the idea and insisted that doing so would enable them to deliver the first part of the upgrade within six months.

Thus, all EIPs included in Pectra are planned to be implemented across two hard forks instead of one. The first hard fork's scope will include 8 out of the 20 EIPs on 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, namely EIP 7742. Including this code change in Pectra could also lead developers to increase blob capacity in Pectra. There are now nine EIPs. The Pectra upgrade is tentatively scheduled for activation on the mainnet in early 2025 and may include the following 10 code changes:

Overall, Pectra encompasses a range of updates for Ethereum that are expected to achieve three outcomes:

• Fixing the protocol's critical flaws as a proof-of-stake blockchain

• Improving the user experience (UX) of interacting with smart contract applications on Ethereum

• Enhancing Ethereum's data availability capabilities

On the surface, user experience improvements and enhancements to Ethereum as a DA layer aim to encourage end users to interact with smart contracts on rollups in a cheaper manner rather than directly on Ethereum. However, improvements to Ethereum's user experience may have 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.

It is worth noting that Pectra does not include any code changes aimed at reinforcing ETH as a 'sound currency' or a store of value narrative. Moreover, none of the EIPs are capable of directly enhancing Ethereum's quality as a censorship-resistant blockchain, a concern that has become a priority for developers since the merge upgrade, due to an increase in the number of known regulated entities participating in the block-building process.

More than 50% of blocks on Ethereum are generated by relays that comply with OFAC standards, meaning that the entities responsible for creating these blocks deliberately exclude transactions that interact 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 name of the next upgrade after Pectra is Fusaka. Since 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 additional 12 code changes from the original Pectra EIP set, namely EOF code changes and PeerDAS. However, after completing the Pectra upgrade, developers will reassess the EIPs based on Fusaka's priorities and readiness.

As a reference, here are 12 code changes that were initially included in Pectra but have since been removed from the upgrade.

Please note that, apart 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 implement the 'EVM Object Format' or EOF for short. EOF significantly changes how the EVM builds and processes code, and it is expected to enhance the experience of smart contract developers by making smart contract code execution more predictable, secure, and cost-effective.

In addition to PeerDAS and EOF, here is a list of all potential code changes that could be considered for inclusion in Fusaka as of October 2024:

Apart from account abstraction and Verkle, all the initiatives listed above have been discussed as potential candidates for the Pectra upgrade but were not included in the upgrade due to a lack of consensus on the code changes. For many of these initiatives, extensive research is still needed before their designs are ready for implementation. The last column of the above table ranks the readiness of the aforementioned 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 list and SSZ transition are the most mature. Of all the parallel initiatives, account abstraction is by far the least likely to be ready for Fusaka, as the pathway to implementing full account abstraction on Ethereum remains unclear, and many parts of that roadmap will be influenced by EIP 7702 in Pectra.

Given the uncertainties associated with these parallel initiatives, it is currently unhelpful to assess their readiness for the mainnet or their impact on ETH value. However, by 2025, a series of ten code changes are likely to affect Ethereum stakeholders.

The next section of this report will explain in greater detail the expected impacts of the EIPs in Pectra on network stakeholders and ETH value.

Critical and non-critical fixes

There is one EIP in Pectra that is critical for Ethereum's operation as a proof-of-stake blockchain. EIP 7251 increases the maximum effective balance for validators from 32 ETH to 2048 ETH and allows existing validators with a maximum effective balance of 32 ETH to consolidate their stake. This is expected to reduce the number of Ethereum validators, which exceeded 1 million as of September 2024.

Ethereum Foundation (EF) engineers' simulations of Ethereum show 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 the issues related to large validator set sizes, refer to this Galaxy Research report.

The fundamentals behind 32 ETH validators

The Beacon Chain was initially designed for validators with a maximum effective balance of 32 ETH because protocol developers wanted to encourage a large number of participants to engage in the proof-of-stake consensus protocol. Developers conservatively estimated that at 32 ETH, the Beacon Chain would attract around 312,500 validators, whose aggregated cryptographic signatures would be sufficient to secure the nascent chain.

When the Beacon Chain launched in December 2020, the price of ETH was around $600, meaning that users with less than $20,000 could run their own validators and independently earn stake rewards. At that time, staking rewards did not include transaction fees or MEV rewards, and there was considerable risk in staking due to users' inability to withdraw funds.

In addition to encouraging participation, the choice of 32 ETH as the effective balance was made because the original design requirement for scaling the Beacon Chain through 'sharding' necessitated each validator to maintain the same effective balance. If all users were required to maintain a staking balance above 32 ETH, developers would worry about not having enough validators to secure the chain. Conversely, if all users kept their staking balances below 32 ETH, there would be concerns about an excess of validators placing unnecessary burdens on the Ethereum network layer.

In addition to the maximum effective balance of 32 ETH, developers have also set a number of other constants and parameters in the protocol based on rough estimates of future staking demand on Ethereum. If the developers' estimates prove to be very inaccurate, they believe they can adjust the chain's economics and staking parameters through subsequent hard forks. Today, 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 Beacon Chain's design specifications could practically 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, it is unlikely that the Ethereum network layer will 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 not compute these based on the number of active validators, but rather based on the combined effective balances of validators, which may range from at least 32 ETH to 2048 ETH.

Particularly in the process of changing the related penalty reductions, developers discovered an edge case where validators with smaller effective balances were disproportionately penalized compared to those with larger effective balances. This edge case has been resolved during the Pectra testing process. As of October 2024, developers are still identifying bugs in the EIP 7251 specification and are working to address these issues.

In addition to updating calculations, the EIP also introduces new operations for consolidating existing validators and adjusting the initial penalty reductions for validators with larger effective balances to encourage consolidation.

Once activated, it remains unclear how quickly large staking entities can consolidate their validators and reduce network pressure. Concerns exist that any peaks in the size of the validator set from now until the consolidation of validators takes effect may negatively affect the health of the network and the network participants running validators on low-end hardware or bandwidth-constrained locations.

The chart below shows 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 chart predicts a decline in the inflow rate of Ethereum validator sets based on the activity of new validator entries since self-validation. It is noteworthy that the following predictions are conservative and do not account for potential future catalysts for staking demand, such as the maturation of restaking protocols like Eigenlayer on Ethereum.

Non-critical fixes

In addition to EIP 7251, the protocol includes several non-critical fixes and improvements that will be activated in the Pectra upgrade. They include:

• EIP 7549, moving the committee index outside of proofs – 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, although to a lesser extent than EIP 7251.

• EIP 6110, providing validator deposits on-chain – This code change shifts the responsibility for validating new staked ETH deposits from CL to EL. In doing so, developers can enhance the security of deposits, reduce the protocol complexity for CL clients, and improve the staking user experience by lowering the latency between depositing 32 ETH on EL and activating a new validator on CL.

• EIP 2935, providing historical block hashes from state – Introduces changes to EL so that historical block proofs 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's 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-based staking pools become increasingly popular, there is a need to enable smart contracts to directly trigger validator withdrawals on CL (EIP 7002) and merges (EIP 7251). This code change introduces a protocol framework to store these types of requests for easier handling by CL.

Expected impact

The critical and non-critical fixes activated in Pectra will mainly impact validator node operators, who will need to update their operations to leverage the higher effective balances of EIP 7251, the efficiency improvements of EIP 7549, and the minor user experience enhancements of 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 improve the current state of the network.

End users and ETH holders are not expected to benefit directly from these five code changes. These code 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 could substantively improve the user experience of end users, smart contract developers, or rollups. Therefore, they are not expected to have a significant impact on the value of ETH.

As with any upgrade across the Ethereum network, the volatility of ETH may increase around Pectra, and if any unexpected errors or failures related to the upgrade occur, the price may experience negative fluctuations. It is essential to clarify that given the extensive battle testing these code changes have undergone before activation on the mainnet, the likelihood of the Pectra upgrade failing is minimal. Therefore, unless ETH experiences temporary fluctuations shortly before and after the upgrade, the code changes related to the various fixes in Pectra are not expected to have long-term positive or negative impacts on ETH's value.

Affected stakeholders: Validator node operators

Expected impact on ETH: Neutral

User experience improvements

Pectra contains 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 the leading general-purpose blockchain.

EIP 2537, precompile for BLS12-381 curve operations – Adds new functions for efficiently executing operations on the BLS12-381 curve, an algebraic structure widely used in zero-knowledge cryptography. Zero-knowledge cryptography can provide various 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 already use zero-knowledge proof systems or are looking to integrate such systems into their operations.

EIP 7002, execution layer can trigger withdrawals – EIP 7002 creates a stateful precompile, which is 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 validator's operator). EIP 7002 introduces a smart contract mechanism that can hold validator withdrawal credentials and use them to trigger validator exits without manual intervention from the validator operator. It will provide more trustless designs for staking applications and enable existing staking applications to eliminate trust assumptions regarding the honest behavior of their validator node operators and the security of these applications.

EIP 7702, setting EOA account code – creates new transaction types for end users to add short-term functionalities to their user-controlled Ethereum accounts, such as:

• Transaction batching, authorizing multiple on-chain operations with a single transaction

• Sponsorship, representing another account to pay for transaction fees

• Permission downgrading, authorizing specific spending conditions on account balances

Given that most users execute transactions on Ethereum through wallet providers, wallet developers will need to leverage the 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 fully functional application development on Ethereum. EIPs like 7002, 2537, and 7702 will implement more trustless staking pool designs, 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 the blob gas target to enhance Ethereum's scalability as a data availability (DA) layer. Many larger and more complex code changes are related to improving DA functionality in Pectra or Fusaka through EIP 7594 (PeerDAS). However, since EIP 7549 will no longer be activated in Pectra, there have been suggestions to introduce simpler changes to lower DA costs.

Currently, Ethereum can handle a maximum of 6 blobs per block and dynamically adjusts the costs of these blobs to achieve an average target of 3 blobs per block. The recommendation made by Layer-2 rollup Base developer Francis Li is to increase the target number of blobs per block to 5 and the maximum number of blobs per block to 8.

In Li's proposal, he pointed out that even conservatively increasing the target blob count to 4 instead of 3 would help build Rollup teams on Ethereum. Developers largely support the increase in blob targets for Pectra. However, confirmation of this viewpoint and the formal inclusion of DA improvements in Pectra still needs 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 by adjusting CL.

• EIP 7742, decoupling blob counts between CL and EL - maximum and target blob limits are hardcoded in both EL and CL. EIP 7742 allows CL to dynamically adjust the 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 by CL.

In addition to EIP 7742 and the increase in blob capacity, developers are weighing two additional code changes related to optimizing Ethereum's DA capabilities in Pectra or Fusaka:

• EIP 7762, increasing MIN_BASE_FEE_PER_BLOB_GAS – When the demand for blobs exceeds the target rate (currently 3 blobs per block), the protocol automatically adjusts the mandatory base cost of blobs upwards. EIP 7762 raises the minimum base cost of blobs to make the blob fee market more responsive to fluctuations in blob demand and to achieve faster price discovery for blobs.

• EIP 7623, increasing the cost of call data – In addition to 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 costly 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 adding blob capacity, they hope to prevent edge cases where validators containing large amounts of call data and the maximum number of blobs propagate unusually large blocks.

Increasing blob throughput in Pectra is a contentious topic among developers, as it may reduce the number of independent stakers running on the network, negatively impacting Ethereum's decentralization. Independent stakers refer to users who stake their own ETH and run their staking operations at home or via cloud providers, rather than relying on staking pools or other intermediary services. Compared to other types of stakers, independent stakers are users operating validators on the most resource-constrained devices.

An increase in blob throughput could raise the computational requirements for operating validators, potentially causing some individual stakers to shut down their machines. In ACDE #197, developers shared anecdotal evidence that some individual stakers have been struggling 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), improve the profit margins of L2 sequencers, and lower transaction fees for L2 end users. These impacts are expected to be similar to those seen 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 for inclusion in Pectra in case the changes in the blob fee market are ultimately not included in the upgrade. Given that the blob capacity in Pectra may increase, it is unlikely that these two code changes will 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%. Concerns raised by developers in ACDE #198 and ACDC #144 regarding this proposal are that it may accelerate the rate of state growth, making the Verkle transition more challenging. Additionally, Ethereum Foundation researcher Francesco D'Amato indicated that changes in slot times 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 does not specify a particular gas target but merely suggests a mechanism for developers to choose a target and safely increase it to this threshold over time. In a recent call in October 2024, developers discussed the potential for implementing EIP 7783 shortly after the Pectra upgrade.

Adding any new EIPs in Pectra could delay the activation of the upgrade on the mainnet. Moreover, the longer developers delay in finalizing the scope of Pectra, the longer it will take to upgrade the public Ethereum testnet. As of October 2024, developers appear to be far from 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 early January or February next year, developers will need to test any new additions to Pectra on a private test network (also known as a development network) before proceeding to upgrade the public Ethereum testnet. At least a month should be reserved for testing additional code changes in Pectra, and it is recommended that developers aim to start the public testnet upgrade in March to tentatively activate the mainnet upgrade sometime in April or May.

These timelines are estimated and may change based on how developers finalize 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 hybrid of code changes, some of which are expected to enhance the experience for users and smart contract developers. Given that the scope of Pectra has been simplified, this upgrade is not expected to have a significant impact on the value of ETH. In addition to Pectra, Ethereum has more follow-up updates that may more directly affect the value of ETH, such as reducing issuance and implementing PeerDAS initiatives. However, as mentioned earlier in this report, it is difficult to predict when these changes may be activated on the mainnet.

It is noteworthy that as Ethereum further pursues scalability improvements in DA according to a 'rollup-centric roadmap,' the impact of protocol upgrades on the value of ETH is expected to diminish over time. In the long run, as applications and users migrate to L2, Ethereum's revenue may be primarily driven by user activity on L2. Upgrades occurring on L2 can enhance user experience, interoperability, decentralization, and security on these networks, which is more important for 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 factors that drive ETH value, applications built on Rollup and Rollup-based protocol upgrades (which further enhance the functionality 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 support ETH's 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, much like how artificial intelligence (AI) has the potential to disrupt all industries by fundamentally changing the way digital content is generated across all industries.

Although scalability improvements like EIP 4844 or PeerDAS may reduce protocol revenue in the short term, they are laying the groundwork for Ethereum to support more on-chain activity than on Ethereum L1. Gaming, fundraising, decentralized finance, and social media are just a few examples of the types of applications that historically have led to surges in Ethereum transaction volume and fees. These applications leverage Ethereum's network effects, decentralization, censorship-resistance, and composability. Theoretically, rollup applications will be able to utilize all these advantages of Ethereum, in addition to significantly lower fees and enhanced functionalities (such as different types of virtual machines, programming languages, and account management).

However, in practice, rollups do not meaningfully inherit properties like 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, rollups do not meaningfully scale Ethereum beyond just lowering transaction costs. Users have too much to weigh as they migrate their activities and applications from L1 to L2. Rollups, along with other scaling solutions developed on alternative layer 1 blockchains, restaking solutions, and infrastructure projects like ZKVM, are in progress. Pure DA improvements may not drive a new wave of adoption for Ethereum or rollups built on it until rollups as a technology mature and benefit from Ethereum's decentralized characteristics.

Conclusion

Despite uncertainties regarding the scope and timeline of Pectra, Ethereum remains a leader as the Web 3 era approaches, where human coordination primarily occurs through decentralized blockchain technologies rather than centralized internet protocols. To achieve this, Ethereum must continue to scale as a decentralized technology while combating centralized forces like maximal extractable value (MEV) and transaction censorship. While Ethereum certainly faces competitors in realizing this vision, maintaining dominance in the Web 3 blockchain space remains a zero-sum game for Ethereum.

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 studied 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 should diminish, as solutions to the biggest challenges facing Web 3 will be inherited by Rollups.

Pectra will introduce user experience-centric code changes, expected to attract new users and smart contract developers into the Web 3 space. However, this may be one of the last remaining upgrades where code changes on the protocol directly impact users and ETH holders. As users migrate to Rollup, protocol revenue is increasingly driven by activities on Rollup, and the most critical code changes for Ethereum stakeholders will be those occurring 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.