Galaxy: Understanding the Next Catalyst of the Ethereum Network - Pectra

Author: Christine Kim, Galaxy; Translator: Baishui, Golden Finance

Foreword

In this report, we provide an overview of the Pectra upgrade and its expected timeline to mainnet activation in October with validators, ETH holders, and investors. Finally, the report shares insights into protocol developments taking place in parallel with Pectra, such as history expiration, built-in proposer-builder separation (ePBS), and verkle tree migration.

How It Starts

Prague—Electra, or “Pectra” for short, is the name of the next Ethereum upgrade. Aside from the name, all other details about the upgrade have been in flux since developers began planning it back in November. However, when discussing what to include in Pectra, it became clear that developers were unanimous about what the top priorities for the Ethereum protocol should be outside of the Verkle transition. Developers agreed that the Verkle transition should be the focus of the upgrade after Pectra, but it was unclear which code changes should be prioritized before Verkle.

As background, the Verkle transition is a major overhaul of Ethereum’s state data structure. State refers to the current balances of all Ethereum accounts, the contract code that controls them, and the data stored. 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 can more easily pass them to other nodes. In the future, developers envision users running nodes that don’t have to maintain Ethereum state records, called “stateless clients.” These lightweight nodes, which can run on resource-constrained devices, will receive the necessary information to verify 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 complexity of restructuring Ethereum’s state database, developers agreed to leave the next upgrade after Pectra (called Fulu-Osaka, or “Fusaka” for short) exclusively to Verkle. They agreed that Verkle would not make other major changes to the protocol to minimize the technical risks of the upgrade’s implementation. Developers expect Pectra to be a small upgrade that they can complete with ease before focusing their full attention on the more arduous task of implementing the Verkle transition.

How it’s going

By the end of August 2024, Pectra will be the largest upgrade in Ethereum’s history in terms of the number of Ethereum Improvement Proposals (EIPs). Developers agreed to include 20 EIPs in Pectra, with more to be considered for inclusion in that list in early September. However, the large scope of Pectra has been a source of controversy and concern for Ethereum developers and other stakeholders. Due to its size, Pectra requires extensive testing and simulations to ensure that the 20 EIPs planned for implementation do not contain hidden bugs or vulnerabilities, especially when implemented in tandem.

Back in May 2024, the EthPandaOps team, a group of Ethereum Foundation engineers tasked with organizing testing efforts for Ethereum upgrades, shared a blog post suggesting that the Pectra upgrade be split in two. At the time, the idea was not seriously considered due to concerns that this could delay the Verkle transition that was scheduled to occur after Pectra was activated. Ethereum Foundation researcher Alex Stokes brought up the idea again at the All Core Developers Execution call #196 in early September. This time, the developers were more in favor of the idea, insisting that doing so would allow them to deliver the first part of the upgrade within six months.

As a result, all of the EIPs included in Pectra are scheduled to be implemented over two hard forks instead of one. The scope of the first hard fork will include eight of the 20 EIPs in the Pectra list. For the other 12 EIPs in the list, developers will continue to develop them in parallel so that they can be implemented on the mainnet after the initial eight EIPs.

Pectra Overview

As of October 2024, developers have agreed to expand the scope of Pectra to include one additional code change, EIP 7742. Incorporating 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 the mainnet in early 2025 and may include the following 10 code changes:

Overall, Pectra includes a series of updates to Ethereum that are expected to achieve three results:

• Fix key flaws in the protocol as a proof-of-stake blockchain

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

• Increase Ethereum’s data availability capabilities

On the surface, the UX improvements and Ethereum’s ability to serve as a proof-of-stake blockchain are a good start. Layer improvements are intended to encourage end users to no longer interact with smart contracts on Ethereum, but rather interact with smart contracts on rollups in a cheaper manner. However, improvements to Ethereum’s UX are likely to have a “trickle-down effect,” meaning that they are likely to be adopted by Rollups as a result of their implementation on mainnet, benefiting both Rollups and Ethereum’s end users.

Notably, Pectra did not make any code changes designed to reinforce the narrative of ETH as “sound money” or a store of value. Additionally, none of the EIPs directly improve the quality of Ethereum as a censorship-resistant blockchain, an issue that has become a priority for developers since the merge upgrade as the number of known regulated entities involved in the block construction process has increased.

Over 50% of blocks on Ethereum are generated by OFAC-compliant relays, meaning that the entities responsible for creating these blocks intentionally exclude transactions that interact with Ethereum addresses listed on the U.S. market.

Developers are working on code changes to reduce ETH issuance and improve censorship resistance in future upgrades. However, they are not the focus of Pectra.

Fusaka Overview

The name of the next upgrade after Pectra is Fusaka. It is difficult to estimate the timeline for Fusaka as the developers have not yet finalized the scope of the upgrade. Currently, developers are keen to prioritize the other 12 code changes in the original Pectra EIP set for Fusaka, namely the EOF code change and PeerDAS. However, after the Pectra upgrade is complete, the developers will re-evaluate the EIPs based on Fusaka's priorities and readiness.

For reference, below is a list of 12 code changes that were originally included in Pectra but have since been removed from the upgrade.

Note that except for the first EIP, the other 11 EIPs are code changes that alter various aspects of the Ethereum Virtual Machine (EVM). Together, these EVM-centric code changes implement the "EVM Target Format," or EOF for short. EOF makes important changes to the way the EVM builds and processes code, and is expected to improve the smart contract developer experience 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:

Except for Account Abstraction and Verkle, all of 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, significant research is still required before their designs are ready for implementation. The last column in the table above ranks the readiness of the above code changes from 1 to 3, with 3 being ready for immediate implementation and 1 being in the early stages of R&D.

Of the above initiatives, inclusion in the inventory 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 path to full account abstraction on Ethereum remains unclear and many parts of that roadmap will be impacted by EIP 7702 in Pectra.

Given the uncertainty associated with these parallel initiatives, it is not useful to assess their readiness for mainnet or impact on the value of ETH at this time. However, it is very likely that a series of 10 code changes will impact Ethereum stakeholders by 2025.

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

Critical and non-critical fixes

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

A simulation of Ethereum by engineers at the Ethereum Foundation (EF) showed that the protocol experienced severe network problems at 1.4 million validators. EIP 7251 is expected to ease network pressure by incentivizing the consolidation of staked ETH. To learn more about the problems of large validator set sizes, read this Galaxy Research report.

The rationale behind 32 ETH validators

The Beacon Chain was originally designed for validators with a maximum effective balance of 32 ETH, as the protocol developers wanted to encourage a large number of participants to participate in the Proof of Stake consensus protocol. Developers conservatively estimated that at 32 ETH, the Beacon Chain would attract approximately 312,500 validators, and the aggregated cryptographic signatures generated by these validators would be sufficient to secure the nascent chain.

The price of ETH was around $600 when the Beacon Chain went live in December 2020, meaning that users with less than $20,000 in funds could run their own validators and earn Stake rewards independently. At the time, staking rewards did not include rewards from transaction fees or MEV, and staking was quite risky as users could not withdraw their funds.

In addition to encouraging participation, the effective balance of 32 ETH was chosen because the original design of scaling the Beacon Chain through "sharding" required each validator to maintain the same effective balance. If all users need to maintain a staking balance above 32 ETH, developers worry that there won’t be enough validators to secure the chain. If all users maintain a staking balance below 32 ETH, there are concerns that there will be too many validators, placing an unnecessary burden on the Ethereum network layer.

In addition to the maximum effective balance of 32 ETH, developers have set a large number of other constants and parameters in the protocol that are based on rough estimates of Ethereum’s future staking needs. If the developers’ estimates are wildly inaccurate, they believe that the chain’s economics and staking parameters can be adjusted through subsequent hard forks. Today, the rapid adoption of liquid staking solutions such as Lido and Coinbase has sparked discussions among developers to lower Ethereum’s issuance curve.

Finally, there may be false assumptions about the true capacity of Ethereum’s network layer. Ethereum founder Vitalik Buterin wrote in a 2021 blog post that the design specifications of the beacon chain can feasibly support the overhead of 4.1 million validators, or staking the entire ETH supply, with a maximum effective balance of 32 ETH. In reality, due to various upgrades and changes to client implementations, it is unlikely that Ethereum’s network layer will ever support 1.4 million validators, let alone over 4 million.

Implementation Details of EIP 7251

EIP 7251 is a complex code change to implement. It fundamentally changes the way the protocol calculates validator rewards, penalties, and withdrawals. Instead of making these calculations based on the number of active validators, the protocol will make them based on the combined effective balances of the validators, each of which may vary from at least 32 ETH to 2048 ETH.

In particular, during the process of changing the associated slashing penalties, developers discovered an edge case where validators with smaller effective balances were disproportionately penalized compared to validators with larger effective balances. This edge case has been addressed during the Pectra testing process. As of October 2024, developers are still identifying bugs in the EIP 7251 specification and working to resolve them.

In addition to updating the calculation, the EIP introduces new actions for validators to consolidate existing validators and adjusts the initial slashing penalty for validators with larger effective balances downward to encourage consolidation.

Once activated, it is unclear how quickly large staking entities will be able to consolidate their validators and reduce strain on the network. There is concern that any spikes in validator set size between now and when validator consolidation takes effect could negatively impact network health and network participants running validators on lower-grade hardware or in locations with limited internet bandwidth.

The following chart illustrates the growth in the number of active validators since the Dencun upgrade. The Dencun upgrade refers to the reduction in the maximum number of validator entries per epoch on Ethereum from 15 to a constant value of 8. The chart below provides a forecast of Ethereum’s validator set growth based on the activity of new validator entries since the validator entry churn rate dropped to 8. It is important to note that the following forecast is conservative and does not take into account potential future catalysts for staking demand, such as the maturation of restaking protocols such as Eigenlayer on Ethereum.

Non-critical fixes

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

• EIP 7549, moving committee indexes outside of attestations - In order to make the CL client software more efficient, this code change introduces a refactoring of validator attestation messages. It is expected to reduce the network load on validator nodes, although to a lesser extent than EIP 7251.

• EIP 6110, Providing Validator Deposits On-Chain – This code change moves the responsibility of validating new staked ETH deposits from CL to EL. In doing so, developers can increase the security of deposits, reduce protocol complexity for CL clients, and improve the staking user experience by reducing the latency between depositing 32 ETH on EL and newly activating a validator on CL.

• EIP 2935, Providing Historical Block Hashes from State – Introduces a change to EL so that proofs of historical blocks can be generated from state. It may provide some additional functionality to smart contract developers, as they will be able to access information about the Ethereum state from previous blocks. Mainly, this is a necessary code change to prepare for the Verkle transition.

• EIP 7685, Generic Execution Layer Requests – Creates a generic framework for storing requests to CL triggered by smart contracts. As smart contract based staking pools grow in popularity, 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 so that CL can easily handle them.

Expected Impact

The critical and non-critical fixes activated in Pectra will primarily affect validator node operators, who will have to update their operations to take advantage of the higher effective balances of EIP 7251, the efficiency improvements of EIP 7549, and the minor UX improvements 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 status quo 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. They are positive for the value of the protocol in the long term, as they ensure that it continues to operate securely and smoothly. However, they do not introduce new features that materially improve the user experience for end users, smart contract developers, or aggregates. Therefore, they are not expected to have an outsized impact on the value of ETH.

As with any network-wide upgrade on Ethereum, ETH volatility may increase before and after Pectra, and the price may experience negative movement if there are any unexpected bugs or failures related to the upgrade. To be clear, there is a low chance that the Pectra upgrade will not be successful, given that these code changes were heavily battle-tested before being activated in the event of a mainnet disruption to the network. Therefore, barring temporary volatility in ETH before and shortly after the upgrade, the code changes in Pectra related to fixing various parts of the protocol are not expected to have a long-term positive or negative impact on the value of ETH.

Affected Stakeholders: Validation Node Operators

Expected Impact on ETH: Neutral

UX Improvements

There are three EIPs in Pectra that will introduce UX improvements for Ethereum’s end users and smart contract developers. While pursuing a rollup-centric roadmap, developers are also making a concerted effort to improve Ethereum’s value proposition as a leading general-purpose blockchain.

EIP 2537, Precompiles for BLS12-381 Curve Operations –Adds new functions to efficiently perform operations on the BLS12-381 curve, an algebraic structure widely used for zero-knowledge cryptography. Zero-knowledge cryptography can provide multiple benefits to 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 Triggerable Withdrawals – EIP 7002 creates stateful precompiles, a mechanism to modify the EVM state for validator withdrawals. Currently, validators on the beacon chain can only be exited through intervention by the validator withdrawal key owner (usually the validator operator). EIP 7002 introduces a mechanism for smart contracts to possess validator withdrawal credentials and use them to trigger validator exits without manual intervention from the validator operator. It will enable more trustless designs for staking applications and enable existing staking applications to remove trust assumptions about the honest behavior of their validator node operators and the security of these applications.

EIP 7702, Set EOA Account Code – Creates new transaction types for end users to add short-term functionality to their user-controlled Ethereum accounts, such as:

• Transaction batching, authorizing multiple on-chain actions by signing a single transaction

• Sponsorship, paying transaction fees on behalf of another account

• Privilege downgrade, authorizing specific spending conditions on account balances

Given that most users perform transactions on Ethereum through wallet providers, wallet developers will need to leverage the new transaction types and add these features to their designs in a way that is easily accessible to users.

Expected Impact

Unlike critical and non-critical fixes, these code changes will enable more feature-complete application development directly on Ethereum. EIPs 7002, 2537, and 7702 will enable more trustless staking pool designs, privacy-enhanced 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 small increase in the blob gas target to improve Ethereum's scalability as a data availability (DA) layer. There are a number of larger, more complex code changes associated with improving DA functionality with the EIP 7594 (PeerDAS) upgrade. However, since EIP 7549 will no longer be activated in Pectra, it has been suggested that a simpler change be introduced to reduce DA costs.

Currently, Ethereum can process up to 6 blobs per block and dynamically adjusts the cost of these blobs to include a target of 3 blobs per block on average. The proposal from Francis Li, a developer at Layer-2 rollup Base, 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 noted that even a conservative increase in the target blob count to 4 instead of 3 would help Rollup teams building on Ethereum. Developers largely support Pectra’s blob target increase. However, confirmation of this view and the formal inclusion of DA improvements in Pectra remain to be decided in a future ACD call. For now, developers have agreed to incorporate EIP 7742 into Pectra, which would pave the way for changing Ethereum’s blob capacity by adjusting CL.

• EIP 7742, decouple blob counts between CL and EL - max and target blob limits are constantly hardcoded on both EL and CL. EIP 7742 enables CL to dynamically adjust max and target blob limits so that future changes to DA capacity do not require a hard fork of both layers, but can be adjusted exclusively through CL.

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

• EIP 7762, Increase MIN_BASE_FEE_PER_BLOB_GAS – The protocol automatically adjusts the mandatory base cost of blobs upward when demand for blobs exceeds a target rate (currently 3 blobs per block). EIP 7762 adjusts the minimum base cost of blobs higher so that the blob fee market can be more sensitive to fluctuations in blob demand and achieve faster price discovery for blobs.

• EIP 7623, Increase Call Data Cost – In addition to blobs, rollups can also publish arbitrary data to Ethereum using the call data field of a transaction. However, leveraging the calldata field of a transaction is generally more expensive for rollups. EIP 7623 aims to further increase the cost of calldata in order to reduce the maximum size of Ethereum blocks. As Ethereum developers increase block sizes by increasing blob capacity, they want to prevent edge cases where a validator with a large amount of calldata and a maximum number of blobs propagates an abnormally large block.

Increasing blob throughput in Pectra is a controversial topic among developers, as it could negatively impact Ethereum’s decentralization by reducing the number of independent stakeholders operating on the network. A independent staker is a user who stakes their own ETH and runs their own staking operation from home or through a cloud provider, rather than relying on a staking pool or other intermediary service for staking. Independent stakers are users who operate validators on the most resource-constrained devices compared to other types of stakers.

Increases in blob throughput could increase the computational requirements to operate a validator, causing some independent stakers to shut down their machines. At ACDE #197, developers shared anecdotal evidence that some solo stakers are already struggling to operate post-Dencun validators. Developers have agreed to conduct a data-driven study of the health of solo staking operations before deciding to increase Pectra’s blob capacity.

Expected Impacts

In the short term, Ethereum’s DA improvements are expected to reduce protocol revenue from Layer-2 rollups (L2), increase margins for L2 collators, and reduce transaction fees for L2 end users. These impacts are expected to be similar to those seen following 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 the blob fee market changes are not ultimately included in the upgrade. These two code changes are unlikely to be included in Pectra due to the potential increase in blob capacity in Pectra. They are EIP 7782 and EIP 7782, proposed by Nethermind developer Ben Adams, would reduce Ethereum slot time from 12 seconds to 8 seconds. This slot time change would effectively increase Ethereum's transaction throughput by 50% and reduce transaction confirmation speed by 33%. The concern raised by developers on ACDE #198 and ACDC #144 about the proposal is that it could increase the state growth rate, making the Verkle transition more difficult. In addition, Francesco D'Amato, a researcher at the Ethereum Foundation, said that the slot time change could negatively impact active research initiatives such as the built-in proposal builder separation (ePBS) and the inclusion list (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 the Gas target over time. Increasing the Gas target will increase the maximum number of transactions that can be included in a block. Rebuffo's proposal does not specify a specific Gas target, but simply suggests a mechanism for developers to choose a target and gradually and safely increase it to this threshold. During a recent call in October 2024, developers discussed the potential for implementing EIP 7783 shortly after the Pectra upgrade.

Any new EIPs added to Pectra could delay the activation of the upgrade on mainnet. Additionally, the longer developers delay deciding on the final scope of Pectra, the longer it will take for developers to upgrade the public Ethereum testnet. As of October 2024, developers do not appear to be close to finalizing the scope of Pectra. Therefore, it is unlikely that the public testnet upgrade for Pectra will go live before the end of this year.

Assuming that the scope of Pectra is finalized in January or early February of next year, developers will need to test any additions to Pectra on private test networks (also known as development networks) before moving on to upgrades to the public Ethereum testnet. By setting aside at least a month’s budget to test other code changes to Pectra, it is suggested that developers could begin public testnet upgrades in March in order to provisionally activate the mainnet upgrade sometime in April or May.

These timeline estimates are subject to change depending on how quickly 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

To date, Pectra is a mix of code changes, some of which are expected to enhance the experience for users and smart contract developers. Due to the simplified scope of Pectra, this upgrade is not expected to have much impact on ETH value. In addition to Pectra, there are more follow-up updates to Ethereum that may more directly affect ETH value, such as initiatives to reduce issuance and implement PeerDAS. However, as mentioned earlier in this report, it is difficult to predict when these changes may be activated on mainnet.

It is worth noting that as Ethereum further pursues DA's scaling improvements under the "Rollup-centric Roadmap", protocol upgrades on Ethereum should have less and less impact on ETH value over time. In the long run, as applications and users migrate to L2, Ethereum's revenue may be driven primarily by user activity on L2. Upgrades occurring on L2 can improve user experience, interoperability, decentralization, and security on these networks, which is more important to the value of Ethereum than optimizations and improvements at the base layer. While upgrades like Pectra will further enhance the decentralization and usability of the protocol, they are unlikely to attract a new wave of users and drive adoption of decentralized applications, as Rollups can scale to meet this demand, while Ethereum cannot. Therefore, when evaluating what drives the value of ETH, applications built on Rollups, as well as Rollup-based protocol upgrades that further enhance the functionality of applications built on Rollups, are key to analysis.

A common pushback to a Rollup-centric roadmap is the fear that Ethereum may become too cheap due to the DA layer, or that revenue from Rollups will be too small to support the value of ETH. These arguments underestimate the total potential market for decentralized applications. Currently, the use case for cryptocurrencies is 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 all industries, as the technology fundamentally changes the way digital content is generated in all industries.

Although scalability improvements such as EIP 4844 or PeerDAS will reduce protocol revenue in the short term. They are laying the foundation for Ethereum to support more on-chain activities than what is possible on Ethereum L1. Gaming, fundraising, decentralized finance, and social media are just a few examples of the types of applications that have historically led to a surge in Ethereum transaction volume and fees. These applications take advantage of Ethereum's network effects, decentralization, censorship resistance, and composability. In theory, applications on Rollups will be able to take advantage of all of these benefits on Ethereum, in addition to significantly lower fees and enhanced functionality such as different types of virtual machines, programming languages, and account management.

However, in practice, Rollups do not meaningfully inherit Ethereum's properties such as decentralization, censorship resistance, or composability. While they can effectively reduce transaction fees, they do so at the expense of decentralization and security. In other words, beyond reducing transaction costs, Rollups do not scale Ethereum in a meaningful way. There are too many tradeoffs for users to make when migrating their activities and applications from L1 to L2. Other scaling solutions like Rollups developed on alternative layer 1 blockchains are in the works, as well as re-collateralization solutions and infrastructure projects like ZKVM. Until Rollups mature as a technology and benefit from Ethereum’s decentralized nature, pure DA improvements likely won’t drive a new wave of adoption for Ethereum or Rollups built on top of it.

Conclusion

Despite the uncertainty around Pectra’s scope and timeline, Ethereum remains the frontrunner in ushering in the Web 3 era, where human coordination is primarily conducted via decentralized blockchain technology rather than centralized internet protocols. To achieve this, Ethereum must continue to scale as a decentralized technology while fighting centralized forces like Maximum Extractable Value (MEV) and transaction censorship. While Ethereum certainly has competitors in achieving this vision, dominating the Web 3 blockchain space remains a losing game for Ethereum.

Ethereum continues to have the highest network effects of any general-purpose blockchain. It remains the most battle-tested blockchain for smart contract developers and the most studied blockchain among researchers and developers for solving challenges related to scaling, MEV, censorship, user experience, and more. However, as Ethereum developers pursue a Rollup-centric roadmap, the importance of Ethereum as a technology and Ethereum upgrade should diminish, as solutions to the biggest problems facing Web 3 will be inherited by Rollups.

Pectra will introduce user experience-centric code changes that are expected to attract new users and smart contract developers to the Web 3 space. However, this may be one of the last few remaining upgrades where code changes on the protocol directly impact users and ETH holders. As users migrate to Rollups and protocol revenues become increasingly driven by Rollup activity, the most important code changes to Ethereum stakeholders will be those made on Rollups. To this end, it is important to analyze the maturity of Rollups as a technology and their ability to meaningfully inherit Ethereum’s security and scale it to millions of new users.