Upcoming ETH Catalysts

Summary

In this report, we will give an overview of the Pectra upgrade and its expected timeline for mainnet activation as of October 2024. The report will also offer an analysis of the expected impact of Pectra on different stakeholders of Ethereum, including end-users, stakers and validators, and ETH holders and investors. Finally, the report shares insights on protocol development happening in parallel to Pectra, such as history expiry, enshrined proposer builder separation (ePBS), and the verkle tree migration.

How It Started

Prague-Electra, or “Pectra” in short, is the name of the next Ethereum upgrade. Other than the name, all other details about the upgrade have been in constant flux since developers started planning it as early as November 2023. Initially, developers envisioned Pectra to be a small upgrade that could be activated on mainnet the same year as Dencun. (Dencun is the name of the most recent Ethereum upgrade activated on mainnet on March 13, 2024.) However, during discussions about what to include in Pectra, it was clear that developers were not in agreement about what the top priority 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 what code changes to prioritize before Verkle.

As background, the Verkle transition is a major overhaul to the data structure of Ethereum state. State refers to the current balances of all Ethereum accounts, the contract code that controls them, and storage data. Developers are planning to move all state data from a Merkle Patricia Tree structure to a Verkle structure. This will enable nodes to generate smaller proofs about state data that they can more easily pass to other nodes. In the future, developers envision users running nodes that do not have to maintain records of Ethereum state, called “stateless clients”. These lightweight nodes that can run on resource-constrained devices will receive the necessary information to validate blocks and progress the chain by relying on proofs generated by other nodes in the network that store records of state, called “stateful clients”. In essence, the Verkle transition is aimed at improving the decentralization of Ethereum by making it easier for users to run nodes.

Due to the complexity of restructuring Ethereum’s state database, developers agreed to reserve the next upgrade after Pectra (called Fulu-Osaka, or “Fusaka” in short) exclusively for Verkle. They agreed no other material changes to the protocol could be coupled with Verkle to minimize the technical risks of upgrade implementation. Developers expected Pectra to be a small upgrade that they could easily complete 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 was shaping up to be the largest upgrade in Ethereum’s history by the number of Ethereum Improvement Proposals (EIPs) included. Developers agreed to include 20 EIPs in Pectra and in early September they weighed adding even more to this list. However, the large scope of Pectra was a source of controversy and concern among Ethereum developers and other stakeholders. Pectra, due to its size, required extensive testing and simulation to ensure that the 20 EIPs slated for implementation would not contain hidden bugs or vulnerabilities, especially when implemented in tandem.

Back in May 2024, a group of Ethereum Foundation engineers responsible for organizing testing efforts for Ethereum upgrades called the EthPandaOps team, shared a blog post recommending the Pectra upgrade be split in two. At the time, the idea was not seriously considered due to concerns this could then delay the Verkle transition scheduled to occur after Pectra activation. The idea was raised again by Ethereum Foundation Researcher Alex Stokes in early September on All Core Developers Execution call #196. This time, developers were more agreeable to the idea and insisted that doing so would enable them to ship the first part of the upgrade within six months.

Thus, all the EIPs included in Pectra were scheduled for implementation across not one, but two hard forks. The scope of the first hard fork will include eight out of the 20 EIPs in the Pectra list. These were the eight that developers had already started to implement on developer-focused test networks, also called devnets, as early as July 2024. For the other 12 EIPs on the list, developers will continue to work on them in parallel for implementation on mainnet after the initial eight.

Pectra Overview

As of October 2024, developers have agreed to expand the scope of Pectra to include one additional code change, EIP 7742. The inclusion of this code change in Pectra makes it likely that developers will also move to include a blob capacity increase in Pectra, alongside the now nine EIPs. The Pectra upgrade, tentatively scheduled for mainnet activation in early 2025, is likely to include the following 10 code changes:

In aggregate, Pectra contains a mixed bag of updates to Ethereum that are expected to achieve three outcomes:

1. Fix critical shortcomings of the protocol as a proof-of-stake blockchain

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

3. Increase Ethereum’s data availability capacity

At face value, UX improvements and improvements to Ethereum as a DA layer are opposed to each other as improvements to Ethereum as a DA layer are designed to encourage end-users to migrate away from interacting with smart contracts on Ethereum and instead interact with smart contracts more cheaply on rollups. However, improvements to Ethereum’s UX are likely to have a “trickle up” effect, meaning they are likely to be adopted by rollups due to their implementation on mainnet, benefitting the end-users of both rollups and Ethereum.

Notably, there are no code changes in Pectra targeted at hardening the narrative of ETH as “sound money” or a store of value. Further, none of the EIPs directly improve the qualities of Ethereum as a censorship-resistant blockchain, which since the Merge upgrade has become a higher priority for developers to address because the number of known, regulated entities involved in the block-building process has increased.

Over 50% of blocks on Ethereum are produced by OFAC-compliant relays, meaning the entities responsible for creating these blocks deliberately exclude the inclusion of transactions interacting with Ethereum addresses that are listed on the U.S. OFAC sanctions list.

There are efforts by developers to include code changes that 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 given that the scope of the upgrade has not yet been finalized by developers. For now, developers are keen on prioritizing the other 12 code changes in the original set of Pectra EIPs for Fusaka, namely EOF code changes and PeerDAS. However, developers will re-evaluate EIPs for Fusaka based on their priority and readiness after the Pectra upgrade is complete.

For reference, the following is a list of the 12 code changes that had initially been included in Pectra but have since been removed from the upgrade.

Note that aside from the first EIP, the other eleven are code changes changing aspects of the Ethereum Virtual Machine (EVM). Together these EVM-focused code changes implement the “EVM Objective Format” or EOF, in short. EOF introduces important changes to the way code is structured and processed by the EVM that are 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, the following is a list of all the potential code changes that could be considered for inclusion in Fusaka, as of October 2024:

All the initiatives listed above, except for account abstraction and Verkle, had been discussed as potential candidates for the Pectra upgrade but did not make it into the upgrade due to a lack of consensus on the code changes. For many of these initiatives, there is still a significant amount of research needed on them before their designs are ready for implementation. The last column of the table above ranks the readiness of the above code changes from 1 to 3, 3 being ready for immediate implementation and 1 being in an early stage of research and development.

Of the initiatives above, inclusion lists and the 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 enabling full account abstraction on Ethereum remains unclear and many parts of this roadmap will be influenced by the impacts of EIP 7702 in Pectra.

Given the uncertainty related to these parallel initiatives, it is not useful to assess their readiness for mainnet or impact on ETH value at this time. However, in 2025, there is a series of 10 code changes that have a high likelihood of impacting Ethereum stakeholders.

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

Critical and Non-Critical Fixups

All critical and non-critical fixups will be implemented in the first part of the Pectra upgrade as early as Q1 2025. There is one EIP in Pectra that is critical to the operations 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 stake. This is expected to reduce the number of validators on Ethereum, which as of September 2024 exceeds 1 million.

Simulations of Ethereum conducted by Ethereum Foundation (EF) engineers have revealed that the protocol runs into severe networking issues at 1.4 million validators. EIP 7251 is expected to relieve networking pressures by encouraging the consolidation of staked ETH. To learn more about the problems of a large validator set size, read this Galaxy Research report.

The Rationale 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 high number of participants in the proof-of-stake consensus protocol. Developers conservatively estimated that at 32 ETH, the Beacon Chain would attract roughly 312,500 validators and the aggregated cryptographic signatures generated by these validators would be sufficient to secure the nascent chain.

The price of ETH at the launch of the Beacon Chain in December 2020 was around $600 USD, meaning that users with less than $20,000 USD of funds could operate their own validator and independently earn staking rewards. At the time, staking rewards did not include rewards from transaction fees or MEV and there was considerable risk to staking due to the fact users could not withdraw their funds.

Aside from encouraging participation, an effective balance of 32 ETH was chosen because the original design to scale the Beacon Chain through “sharding” required that every validator maintain the same effective balance. If all users were expected to maintain staked balances higher than 32 ETH, developers were concerned that there would not be enough validators to secure the chain. If all users were expected to maintain staked balances lower than 32 ETH, the concern was there would be an excessive number of validators unnecessarily burdening the networking layer of Ethereum.

Along with a maximum effective balance of 32 ETH, there was a slew of other constants and parameters that developers set in the protocol that were based on rough estimations of future staking demand on Ethereum. If developers’ estimations were wildly inaccurate, they figured they could tweak the economics and staking parameters of the chain through subsequent hard forks. Today, the rapid adoption of liquid staking solutions like Lido and Coinbase has motivated discussions among developers to adjust the issuance curve of Ethereum lower.

Finally, there may have been incorrect assumptions about the true capacity of the networking layer of Ethereum. Founder of Ethereum Vitalik Buterin wrote in a blog post in 2021 that the design specifications of the Beacon Chain could feasibly support the overhead of 4.1 million validators, or the entire ETH supply staked, with a maximum effective balance of 32 ETH. In practice, due to various upgrades and changes in client implementations, the networking layer of Ethereum is unlikely to be able to support 1.4 million validators, let alone larger than 4 million.

Implementation Details of EIP 7251

EIP 7251 is a complex code change to implement. It fundamentally changes how the protocol calculates validator rewards, penalties, and withdrawals. The protocol will not base these calculations on the number of active validators, but rather on the combined effective balance of validators which can vary per validator from a minimum of 32 ETH to 2048 ETH.

In the process of changing correlated slashing penalties in particular, developers have identified an edge case that would have disproportionately penalized validators with smaller effective balances than validators with larger effective balances. This edge case has since been addressed in the Pectra testing process. As of October 2024, developers are still identifying bugs in EIP 7251 specifications that they are working on addressing.

Aside from updating calculations, the EIP introduces new operations for validators to consolidate existing validators and adjusts the initial slashing penalty of validators with large effective balances downwards to encourage consolidation.

Once activated, it is unclear how quickly large staking entities will be able to consolidate their validators and reduce networking pressures. There is a concern that any spikes in the validator set size between now and when validator consolidations take effect could negatively impact network health and network participants who are operating validators on low-grade hardware or in locations with restricted internet bandwidth.

The following is a chart illustrating the growth in the number of active validators since the Dencun upgrade. The Dencun upgrade was when the maximum number of validator entries per epoch on Ethereum was reduced from 15 to a constant value of 8. The chart below offers a projection of the growth in Ethereum’s validator set based on the activity of new validator entries since the validator entry churn dropped to 8. It is important to note that the projections below are conservative and do not consider potential future catalysts to staking demand such as the maturation of restaking protocols like Eigenlayer on Ethereum.

Non-Critical Fixups

Aside from EIP 7251, there are a handful of non-critical fixups and improvements to the protocol that will be activated in the Pectra upgrade. They include:

• EIP 7549, Move committee index outside attestation – In an effort to make CL client software more efficient, this code change introduces a refactoring of validator attestation messages. It is expected to reduce the networking load on validator nodes, albeit to a lesser degree than EIP 7251.

• EIP 6110, Supply validator deposits on chain – This code change shifts the responsibility of validating new staked ETH deposits from the CL to the EL. In doing so, developers can increase the security of deposits, reduce protocol complexity in CL clients, and improve staking UX by decreasing the delay between when a deposit of 32 ETH is made on the EL and when a validator is newly activated on the CL.

• EIP 2935, Serve historical block hashes from state – Introduces a change to the EL such that proofs of historical blocks can be generated from the state. It may offer some additional functionality for smart contract developers as they will be able to access information about Ethereum state from prior blocks. Mainly, it is a necessary code change in preparation for the Verkle transition.

• EIP 7685, General purpose execution layer requests – Creates a general-purpose framework for storing smart contract triggered requests to the CL. Due to the increasing popularity of smart contract-based staking pools, there is a demand to enable smart contracts to directly trigger validator withdrawals (EIP 7002) and consolidations (EIP 7251) on the CL. This code change introduces a framework for the protocol to store these types of requests for easy processing by the CL.

Expected Impacts

The critical and non-critical fixups activated in Pectra will primarily impact validator node operators, who will have to update their operations to take advantage of higher effective balances from EIP 7251, efficiency gains from EIP 7549, and minor UX improvements from EIP 6110. There is little immediate benefit to node operators from the other two fixup EIPs, EIP 2935 and EIP 7685. The former will benefit node operators in a future upgrade where stateless clients become a reality, while the latter offers an improvement to 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 directly benefit from these five code changes. These bundle of code changes primarily benefit the health and resiliency of Ethereum as a proof-of-stake blockchain. Long-term, they are positive about the value of the protocol as they ensure that the protocol can continue to operate safely and smoothly. However, they do not introduce new features that materially improve the user experience for end-users, smart contract developers, or rollups. Therefore, they are not expected to have an outsized impact on ETH value.

As with any network-wide upgrade on Ethereum, there will likely be heightened volatility in ETH around the time of Pectra and the potential for negative swings in price should there be any unexpected bugs or failures related to the upgrade. To be clear, the likelihood of an unsuccessful Pectra upgrade is slim given the extensive amount of battle testing these code changes undergo before activation on mainnet and the extensive experience of Ethereum protocol developers when it comes to executing these types of backward-incompatible code changes without disruption to the network. Therefore, barring temporary volatility in ETH leading up to and shortly following the upgrade, the code changes in Pectra related to fixing various parts of the protocol are not anticipated to have a prolonged positive or negative impact on ETH value.

Impacted stakeholders: Validator node operators

Expected impact on ETH: Neutral

UX Improvements

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

EIP 2537, Precompile for BLS12-381 curve operations – Adds new functions to efficiently perform operations over the BLS12-381 curve, which is an algebraic structure widely used for zero-knowledge cryptography. Zero-knowledge cryptography can offer several benefits for blockchain-based applications, including stronger privacy guarantees, security, and scalability. The ability to perform operations over the BLS curve would be beneficial for applications and rollups built atop Ethereum that already utilize zero-knowledge proof systems or are looking to integrate such systems into their operations.

EIP 7002, Execution layer triggerable withdrawals – EIP 7002 creates a stateful precompile, which is a mechanism to modify EVM state, for validator withdrawals. Currently, validators on the Beacon Chain can only be exited through intervention by the validator withdrawal key owner, who is usually the operator of the validator. EIP 7002 introduces a mechanism for smart contracts to own validator withdrawal credentials and use them to trigger validator exits without manual intervention by 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, which will also have trickle-down effects on the users of staking applications that take advantage of EIP 7002 by enhancing the security of these applications.

EIP 7702, Set EOA account code – Creates a new transaction type for end-users to add short-term functionalities to their user-controlled Ethereum accounts such as:

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

• sponsorship, paying for a transaction on behalf of another account

• privilege de-escalation, authorizing specific spending conditions on the account balance

Given that most users execute transactions on Ethereum through a wallet provider, it will be up to wallet developers to utilize the new transaction type and add these functionalities to their designs in a way that users can easily access.

Expected Impacts

Unlike the critical and non-critical fixups, these code changes will directly enable more feature-complete app development on Ethereum. EIPs like 7002, 2537, and 7702 will enable more trustless staking pool designs, privacy-enhanced decentralized finance protocols, and secure user-controlled accounts, respectively.

Impacted stakeholders: End-users, smart contract developers

Expected impact on ETH: Positive

DA Improvements

As mentioned earlier in this report, there is one more code change that will likely be included in Pectra. Developers are weighing a minor increase to the blob gas target to improve Ethereum’s scalability as a data availability (DA) layer. There are a series of larger, more complex code changes related to improving DA capacity through the EIP 7594 (PeerDAS) upgrade. However, since EIP 7549 will no longer be activated in Pectra, there is a proposal to introduce a simpler change to reduce DA costs.

Currently, Ethereum can process a maximum of six blobs per block and dynamically adjusts the costs of these blobs so that on average blocks contain a target of 3 blobs per block. The proposal by Francis Li, a developer for the 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. For more background on blobs and how they work, refer to this Galaxy Research report on the Dencun upgrade.

In Li’s proposal, he notes that even a conservative increase of the target blob count alone to 4 instead of 3 would assist rollup teams building on Ethereum. Developers were largely in favor of the blob target increase in Pectra. However, confirmation of this sentiment and the formal inclusion of a DA improvement in Pectra is still to be decided on a future ACD call. For now, developers have agreed to include EIP 7742 in Pectra, which would pave the way for a change to Ethereum’s blob capacity through adjustments to the CL.

• EIP 7742, Uncouple blob count between CL and EL– The max and target blob limits are constantly hard coded on the EL and CL. EIP 7742 enables the CL to dynamically adjust the max and target blob limit such that future changes to DA capacity do not require a hard fork to both layers, but rather can be adjusted exclusively through the CL.

Alongside EIP 7742 and a blob capacity increase, 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 demand for blobs exceeds the target rate, which is currently three blobs per block, the protocol automatically adjusts the mandatory base cost for blobs upwards. This pricing mechanism is like the pricing mechanism for regular Ethereum transactions under EIP 1559. For more information about how EIP 1559 works, refer to this Galaxy Research report. EIP 7762 adjusts the minimum base cost for blobs higher such that the blob fee market can be more sensitive to swings in demand for blobs and reach price discovery for blobs faster.

• EIP 7623, Increase call data cost– Alongside blobs, rollups can use the call data field of transactions to post arbitrary data to Ethereum. However, usually, utilizing the call data field of transactions is more expensive for rollups. EIP 7623 aims to increase the cost of call data further to reduce the maximum size of Ethereum blocks. As Ethereum developers increase the size of blocks through increases to blob capacity, they are looking to prevent edge cases where abnormally large blocks are propagated by validators containing both a large amount of call data and the maximum number of blobs.

Increasing blob throughput in Pectra is a controversial topic among developers as this may negatively impact the decentralization of Ethereum by reducing the number of solo stakers operating on the network. Solo stakers are users that stake their own ETH and run their own staking operations either from home or through cloud providers, instead of relying on a staking pool or other intermediary services to stake. Compared to other types of stakers, solo stakers are the users who are operating validators on the most resource-constrained devices.

An increase in the blob throughput may increase the computational requirements of operating a validator and thus cause certain solo stakers to turn off their machines. On ACDE #197, developers shared anecdotal evidence to suggest that some solo stakers are already struggling to operate validators post-Dencun. Developers have agreed to conduct data-driven research on the health of solo staking operations before deciding on a blob capacity increase in Pectra.

Expected Impacts

In the short term, DA improvements to Ethereum are expected to reduce protocol revenue from Layer-2 rollups (L2s), increase profit margins of L2 sequencers, and lower transaction fees for L2 end-users. These impacts are expected to be similar to the impacts seen after the activation of EIP 4844 in the Dencun upgrade. To learn more about the impacts of Dencun on Ethereum and rollup economics, read this Galaxy Research report.

Impacted stakeholders: Layer-2 rollups, L2 end-users, ETH holders

Expected impact on ETH: Negative

Pectra Timeline Analysis

There are two alternative code changes that developers have discussed for inclusion in Pectra in case a change to the blob fee market is not ultimately included in the upgrade. Because a blob capacity increase in Pectra is likely, these two code changes are unlikely to be included in Pectra. They are EIP 7782 and 7783.

EIP 7782, proposed by Nethermind developer Ben Adams, reduces Ethereum slot times from 12 to 8 seconds. This change to the slot time would effectively increase Ethereum’s transaction throughput by 50% and reduce transaction confirmation speeds by 33%. A concern raised by developers on ACDE #198 and ACDC #144 about this proposal was that it could make the Verkle transition more difficult by speeding up the growth rate of state. Also, Ethereum Foundation Researcher Francesco D’Amato said that changes to slot time could have negative impacts on active research initiatives such as enshrined propose builder separation (ePBS) and inclusion lists (ILs).

EIP 7783, proposed by Erigon developer Giulio Rebuffo, is a comparatively easier code change for developers to implement because it does not require a hard fork. EIP 7783 creates a mechanism for client teams to gradually increase the gas target over time. Increases to the gas target would 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 safely increase it to this threshold gradually. On a recent call in October 2024, developers discussed the potential of implementing EIP 7783 shortly after the Pectra upgrade.

The addition of any new EIPs in Pectra are likely to delay the activation of the upgrade on mainnet. Further, the longer developers delay a decision about the final scope of Pectra, the longer it will be before developers can move forward with upgrading public Ethereum testnets, which is a key milestone for developers to reach before any Ethereum upgrade can be scheduled for mainnet activation. As of October 2024, developers do not appear close to finalizing the scope of Pectra. Thus, it is unlikely that public testnet upgrades for Pectra will go live before the end of this year.

Assuming the scope of Pectra is finalized by early next year in January or February, developers will need to test any additions to Pectra on a private test network, also called a devnet, before moving on to upgrading public Ethereum testnets. Budgeting at least one month for testing additional code changes to Pectra suggests that developers may begin public testnet upgrades in March for a tentative mainnet activation of the upgrade sometime in April or May.

These timeline estimations are subject to change based on when developers finalize the scope of Pectra over the course of the next few months and the complexity of the code changes they do decide to ultimately add to the upgrade.

Other Catalysts for ETH Value

So far, Pectra is a mixed bag of code changes, some of which are anticipated to enhance the user and smart contract developer experience. Due to the simplified scope of Pectra, the upgrade is not expected to have outsized impacts on ETH value. Beyond Pectra, there are more consequential updates to Ethereum that are likely to impact ETH value more directly such as the initiatives to reduce issuance and implement PeerDAS. However, as indicated earlier in this report, it is difficult to anticipate when these changes will be ready for activation on mainnet.

It is important to note that as Ethereum pursues further scaling improvements in DA according to a “rollup-centric roadmap”, protocol upgrades on Ethereum should matter less to ETH value over time. In the long term, as applications and users migrate to L2s, revenue for Ethereum is likely to be primarily driven by user activity on L2s. The upgrades that happen on L2s that advance UX, interoperability, decentralization, and security on these networks matter more to Ethereum’s value than the optimizations and improvements on the base layer. Though upgrades like Pectra will further enhance the protocol’s decentralization and usability, they are not likely to attract a new wave of users and propel adoption for decentralized applications as rollups can scale to meet this demand, while Ethereum cannot. Thus, when it comes to assessing what drives ETH value, the applications built on rollups and the protocol upgrades on rollups that further enhance the features of apps built on rollups are key to this analysis.

A common pushback to the rollup-centric roadmap is the concern that Ethereum may become too cheap as a DA layer or revenues from rollups will be too little to support ETH value. These arguments underestimate the total addressable market for decentralized applications. At present, the use cases for crypto stand to disrupt every single industry in the world because public blockchains have the potential to fundamentally change the activity of human coordination, similar in a way to how artificial intelligence (AI) has the potential to disrupt all industries for the way the technology fundamentally changes how digital content in all industries is generated.

Though scalability improvements such as EIP 4844 or PeerDAS reduce protocol revenues in the short-term. They are setting the stage for Ethereum to support magnitudes more on-chain activity than possible on Ethereum L1. Gaming, fundraising, decentralized finance, and social media are a few examples of the types of applications that have historically led to spikes in transaction volumes and fees on Ethereum. These applications took advantage of Ethereum’s network effects, decentralization, censorship resistance, and composability. In theory, applications on rollups will be able to take advantage of all 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 properties of decentralization, censorship resistance, or composability from Ethereum. Though they are effective at reducing transaction fees, they do so at the expense of decentralization and security. In other words, rollups do not scale Ethereum in a meaningful way other than lowering transaction costs. There are too many tradeoffs that exist for users to migrate their activity and apps to rollups from the L1 to the L2. Rollups like other scaling solutions developed on alternative Layer-1 blockchains and infrastructure projects like restaking solutions and ZKVMs are a work in progress. Until rollups mature as a technology and meaningfully benefit from Ethereum for the network’s decentralized properties, pure DA improvements likely won’t propel a new wave of adoption for either Ethereum or the rollups built atop it.

Conclusion

Despite uncertainty surrounding the scope and timeline for Pectra, Ethereum remains the front-runner when it comes to ushering in the Web 3 era where human coordination happens primarily through decentralized blockchain technology instead of centralized Internet protocols. For this to happen, Ethereum must continue to scale as a decentralized technology, whilst combating centralizing forces such as maximal extractable value (MEV) and transaction censorship. Though Ethereum certainly has competitors when it comes to achieving this vision, dominating the Web 3 blockchain space remains Ethereum’s game to lose, as discussed in this Galaxy Research report about the competitive landscape of Layer 1 blockchains.

Ethereum continues to hold the highest network effects of any general-purpose blockchain. It remains the most battle-tested blockchain for smart contract developers and the most studied among researchers and developers for addressing challenges related to scaling, MEV, censorship, UX, and more. However, as Ethereum developers pursue a rollup-centric roadmap, the role of Ethereum, as a technology, and Ethereum upgrades should wane in importance as solutions to the biggest problems facing Web 3 are inherited by rollups.

Pectra will introduce UX-focused code changes expected to attract new users and smart contract developers to the Web 3 space. However, it will likely 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’s stakeholders will be the ones pursued on rollups. To this end, it will be important to analyze the maturity of rollups as a technology and their ability to meaningfully inherit Ethereum’s security and scale it for millions of new users.

For more information on the maturity of rollups and their technical progress, read this Galaxy Research report tracking the decentralization progress of Ethereum’s top two rollups by total value locked, Arbitrum, and Optimism.