Author: Christine Kim, Galaxy; Translated by: Baishui, Jinse Finance
Preface
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 started
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, in discussing what to include in Pectra, it became clear that developers are unanimous about what the top priorities for the ethereum protocol should be outside of the Verkle transition. Developers agree that the Verkle transition should be the focus of upgrades after Pectra, but it’s 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 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 the Ethereum 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 in order to minimize the technical risk of the upgrade implementation. Developers expected Pectra to be a small upgrade that they could complete easily before focusing their full attention on the more difficult task of implementing the Verkle transition.
How is it going?
By the end of August 2024, Pectra will be the largest upgrade in Ethereum history in terms of the number of Ethereum Improvement Proposals (EIPs). Developers agreed to include 20 EIPs in Pectra, and in early September they considered adding more EIPs to the list. 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, a group of Ethereum Foundation engineers, the EthPandaOps team responsible for organizing Ethereum upgrade testing, 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 planned 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 and insisted that doing so would allow them to deliver the first part of the upgrade within six months.
Therefore, all EIPs included in Pectra are planned to be implemented in two hard forks instead of one. The scope of the first hard fork will include 8 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 8 EIPs.
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 possible for developers to also increase blob capacity in Pectra. There are now nine EIPs. The Pectra upgrade is tentatively scheduled for mainnet activation in early 2025 and may include the following 10 code changes:
In general, Pectra includes a series of updates to Ethereum that are expected to achieve three results:
Fixing the protocol’s key flaw as a proof-of-stake blockchain
Improving the user experience (UX) of interacting with smart contract applications on Ethereum
Improving Ethereum’s data availability capabilities
On the surface, UX improvements and improvements to Ethereum as a DA layer are intended to encourage end users to no longer interact with smart contracts on Ethereum, but to interact with smart contracts on rollups in a cheaper way. However, UX improvements on Ethereum are likely to have a “trickle-down effect,” meaning that due to their implementation on mainnet, they are likely to be adopted by Rollups, benefiting both Rollup and Ethereum end users.
Notably, Pectra did not make any code changes designed to reinforce ETH’s narrative as “sound money” or a store of value. Additionally, none of the EIPs directly improve Ethereum’s quality as a censorship-resistant blockchain, an issue that has become a priority for developers since the merged upgrade as the number of known regulated entities involved in the block building process has increased.
More than 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 US 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, the 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 completed, the developers will re-evaluate the EIP based on the priority and readiness of Fusaka.
For reference, here is a list of 12 code changes that were originally included in Pectra but have since been removed from upgrades.
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 Object Format," or EOF for short. EOF makes important changes to the way the EVM constructs and processes code, and is expected to improve 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:
With the exception of 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 research and development.
Of the above initiatives, inclusion in listings 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 their impact on the value of ETH at this time. However, it is 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 an EIP in Pectra that is essential for Ethereum to function 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 encountered severe network problems at 1.4 million validators. EIP 7251 is expected to ease network pressure by encouraging 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 protocol developers want to encourage a large number of participants to participate in the proof-of-stake consensus protocol. Developers conservatively estimate that at 32 ETH, the beacon chain will attract approximately 312,500 validators, and the aggregate cryptographic signatures generated by these validators will be sufficient to protect the security of the nascent chain.
When the beacon chain went live in December 2020, the price of ETH was around $600, which meant 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 transaction fees or MEV rewards, and staking was quite risky because users could not withdraw 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" requires each validator to maintain the same effective balance. If all users were required to maintain a staked balance above 32 ETH, developers would worry that there would not be enough validators to protect the security of the chain. If all users maintained a staked balance below 32 ETH, people would worry that there would be too many validators and put unnecessary burden on the Ethereum network layer.
In addition to the maximum effective balance of 32 ETH, developers set a large number of other constants and parameters in the protocol that are based on rough estimates of Ethereum's future staking demand. 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 specification of the beacon chain can feasibly 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, Ethereum’s network layer is unlikely to support 1.4 million validators, let alone more than 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, which can range from at least 32 ETH to 2048 ETH per validator.
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 resolved 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 also introduces new operations for validators to consolidate existing validators and adjusts the initial slashing penalties 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 spike in validator set size between now and when validator consolidation takes effect could negatively impact network health and network participants running validators on lower-end hardware or in locations with limited internet bandwidth.
The chart below shows the growth in the number of active validators since the Dencun upgrade. The Dencun upgrade was 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 forecasts are conservative and do not take into account potential future catalysts for staking demand, such as the maturation of re-staking 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 - This code change introduces a refactoring of validator attestation messages in order to make the CL client software more efficient. It is expected to reduce network load on validator nodes, albeit to a lesser extent than EIP 7251.
EIP 6110, Providing Validator Deposits On-Chain – This code change moves the responsibility for 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 changes to EL so that proofs of historical blocks can be generated from state. It may provide some additional functionality for smart contract developers, as they will be able to access information about 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 CLs 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 CLs. This code change introduces a protocol framework to store these types of requests so that CLs 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 gains 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 network status quo.
End users and ETH holders are not expected to benefit directly from these five code changes. These code changes primarily benefit the health and resiliency of Ethereum as a proof-of-stake blockchain. They are positive for the value of the protocol in the long run because they ensure that it can continue 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, the likelihood of the Pectra upgrade not being successful is low, 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: Validator node operators
Expected impact on ETH: Neutral
User experience improvements
There are three EIPs in Pectra that will introduce user experience improvements for Ethereum 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 the 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 BLS curves 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 a new transaction type for end users to add short-term functionality to their user-controlled Ethereum accounts, such as:
Transaction batching, authorizing multiple on-chain operations by signing a single transaction
Sponsorship, paying transaction fees on behalf of another account
Downgrade permissions, specific spending conditions for authorized account balances
Given that most users perform transactions on Ethereum through wallet providers, wallet developers will need to take advantage of 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 fully functional application development directly on Ethereum. EIPs 7002, 2537, and 7702 will enable more trustless staking pool designs, privacy-enhanced decentralized financial 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, there is another code change that may be included in Pectra. Developers are considering a small increase in the blob gas target to improve the scalability of Ethereum as a data availability (DA) layer. There are many larger and more complex code changes related to improving DA functionality through the EIP 7594 (PeerDAS) upgrade. However, since EIP 7549 will no longer be activated in Pectra, it has been proposed to introduce simpler changes to reduce DA costs.
Currently, Ethereum can handle up to 6 blobs per block, and dynamically adjusts the cost of these blobs to achieve a target of 3 blobs per block on average. Francis Li, developer of Layer-2 rollup Base, has proposed increasing 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 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 - max and target blob limits are constantly hardcoded on both EL and CL. EIP 7742 enables the CL to dynamically adjust max and target blob limits so that future changes to DA capacity do not require hard forking both layers, but can be adjusted exclusively through the CL.
In addition to EIP 7742 and the blob capacity increase, developers are weighing two additional code changes related to optimizing Ethereum 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 enable faster price discovery for blobs.
EIP 7623, Increased Call Data Cost - In addition to blobs, rollups can also use the call data field of a transaction to publish arbitrary data to Ethereum. However, leveraging the call data field of a transaction is generally more expensive for rollups. EIP 7623 aims to further increase the cost of call data in order to reduce the maximum size of Ethereum blocks. As Ethereum developers increase the block size by increasing blob capacity, they want to prevent edge cases where a validator with a large amount of call data and the 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 solo staker is a user who stakes their own ETH and runs their own staking operations from home or through a cloud provider, rather than relying on a staking pool or other intermediary service for staking. Compared to other types of stakers, independent stakers are users who operate validators on the most resource-constrained devices.
Increased blob throughput could increase the computational requirements of operating a validator, causing some individual stakers to shut down their machines. At ACDE #197, developers shared anecdotal evidence that some individual stakers are already struggling to operate post-Dencun validators. Developers have agreed to conduct a data-driven study of the health of individual stake operations before deciding to increase Pectra’s blob capacity.
Expected impact
In the short term, Ethereum’s DA improvements are expected to reduce protocol revenue from Layer-2 rollups (L2), increase margins for L2 collators, and reduce transaction fees for L2 end users. These effects 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
The developers have discussed two alternative code changes to include in Pectra in case the blob fee market changes are not included in the upgrade. Since the blob capacity in Pectra is likely to increase, these two code changes are unlikely to be included in Pectra. They are EIP 7782 and
EIP 7782, proposed by Nethermind developer Ben Adams, would reduce Ethereum slot times 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. Additionally, 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 Inclusion Lists (IL).
Proposed by Erigon developer Giulio Rebuffo, EIP 7783 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. In a recent call in October 2024, developers discussed the potential for implementing EIP 7783 shortly after the Pectra upgrade.
Adding any new EIPs to Pectra could delay activation of the upgrade on mainnet. Furthermore, 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 the scope of Pectra is finalized in January or early February of next year, developers will need to test any additions to Pectra on a private testnet (also known as a development network) before moving on to upgrading the public Ethereum testnet. With at least a month’s budget set aside to test other code changes to Pectra, it is suggested that developers could start public testnet upgrades in March in order to tentatively 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
So far, 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 the value of ETH. In addition to Pectra, there are more follow-up updates to Ethereum that may more directly affect the value of ETH, such as initiatives to reduce issuance and implement PeerDAS. However, as mentioned earlier in this report, it is difficult to predict when these changes will be activated on the mainnet.
It is worth noting that as Ethereum further pursues DA scalability improvements under the “Rollups-centric roadmap”, protocol upgrades on Ethereum should have less and less impact on ETH’s value over time. In the long run, Ethereum’s revenue may be driven primarily by user activity on L2 as applications and users migrate to 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 to the base layer. Although 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 because Rollups can scale to meet this demand, while Ethereum cannot. Therefore, when evaluating the factors that drive ETH’s value, applications built on Rollups and protocol upgrades based on Rollups (which further enhance the functionality of applications built on Rollups) are key to the analysis.
A common resistance to Rollup-centric roadmaps is the fear that Ethereum might become too cheap due to the DA layer, or that the revenue from Rollups would be too small to support the value of ETH. These arguments underestimate the total potential market for decentralized applications. Currently, the use cases of cryptocurrencies are disrupting every industry in the world, as public blockchains have the potential to fundamentally change human coordination activities, just as artificial intelligence (AI) has the potential to disrupt all industries. The technology fundamentally changes the way digital content is generated in all industries.
While scalability improvements like 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 available 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 surges 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 reduced 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 of 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 trade-offs for users to make when migrating their activities and applications from L1 to L2. Other scaling solutions like Rollups are being developed on alternative layer 1 blockchains, as well as infrastructure projects like re-collateralization solutions and ZKVM. Until Rollups mature as a technology and benefit from Ethereum’s decentralized nature, pure DA improvements may not drive a new wave of adoption for Ethereum or Rollups built on top of it.
in conclusion
Despite the uncertainty surrounding Pectra’s scope and timeline, Ethereum remains the frontrunner in ushering in the Web 3 era, where human coordination is primarily conducted through decentralized blockchain technology rather than centralized internet protocols. To achieve this goal, Ethereum must continue to scale as a decentralized technology while fighting centralized forces such as Maximum Extractable Value (MEV) and transaction censorship. While Ethereum certainly has competitors in achieving this vision, dominating the Web 3 blockchain space is still a losing game for Ethereum.
Ethereum continues to have the highest network effect of all general-purpose blockchains. 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, etc. However, as Ethereum developers pursue a Rollup-centric roadmap, the importance of Ethereum as a technology and Ethereum upgrade should diminish, as the solutions to the biggest problems facing Web 3 will be inherited by Rollups.
Pectra will introduce UX-focused code changes that are expected to attract new users and smart contract developers to the Web 3 space. However, this is likely to 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 security and scale it to millions of new users.
