Prysm: Electra Upgrade

Offchain Labs has been deeply committed to contributing to the development of Ethereum itself. The continuous efforts of the Prysm team at Offchain Labs help ensure our technological alignment between the L2 roll-ups and Ethereum, driving faster innovation and working towards our core mission to scale Ethereum.

With the Deneb/Cancun/Dencun upgrade set to land on the Ethereum mainnet in the very near future, the Prysm team at Offchain Labs has begun to consider which Ethereum Improvement Proposals (EIPs) are in scope and feasible for the consensus layer upgrades following Deneb. The Electra upgrade will be the first upgrade after Deneb in the consensus layer and the Prysm team strongly feels that Electra should be scoped to ship quickly enough in 2024 such that it is still viable to support Verkle Trees in 2025.

While the Prysm team recommends a modest upgrade for Electra in 2024, we would be open to supporting complex changes such as Inclusion Lists and ePBS if the community decides to ship Electra as a more extensive upgrade in 2025. When it comes to any EIPs that primarily affect the Execution Layer, we defer to and trust the judgement of the Execution Layer teams. Lastly, we have very strong opinions that are weakly held. All support / no support signals in this post are open to reconsideration to align with the Ethereum Core Developer community.

Strong Support

EIP-7002: EL Triggerable Exits

The proposal for triggering validator exits from the execution layer takes trustless staking pools and re-staking to the next level by enabling Ethereum mainnet accounts to initiate a validator exit rather than the operator of the validator “hot validating key”. The work required to support this in the consensus layer is considered a relatively moderate change with a high impact potential. The Prysm team supports this EIP for inclusion in Electra.

EIP-6110: Supply Validator Deposits On-Chain

Switching from the “ETH1 voting in the beacon node” scheme of deposit inclusion to an on-chain mechanism contained within the Execution Layer significantly reduces the complexity of consensus layer deposit inclusion and allows for Prysm to clean up certain parts of the codebase. In fact, this very logic was once responsible for the first ever mainnet incident in the Ethereum Consensus Layer. The ETH1 voting functionality was necessary prior to The Merge and is now considered tech debt. From a CL implementer’s perspective, supporting this EIP is an easy win, and the Prysm team endorses its inclusion in Electra.

EIP-7549: Move Committee Index Outside of Attestation

This proposal changes the structure of attestation messages for more efficient vote counting. Implementation of the proposal in Prysm is relatively easy, although a pull request may appear large as Attestation and AttestationData objects are used throughout the application and would require a new abstraction type. As such, the Prysm team supports this proposal in Electra.

EIP-6914: Reusing Validator Indices

At the time of writing this post, more than 20% of Ethereum mainnet validators are inactive. Yet, these validators’ spot in the beacon state continues to occupy memory in every beacon node implementation. Rather than maintaining a state with fully exited validators, the beacon chain could reuse the validator index, after a safe period of time, to allow a new validator to take that spot in the beacon state. The specification for this proposal is relatively straightforward and we expect that implementation would not be a significant burden or high complexity. The Prysm team supports this EIP for inclusion in Electra.

No Objection

Using Simple Serialize (SSZ) for ExecutionPayload Structs

There are several EIPs proposed for leveraging SSZ instead of Recursive-Length Prefix format or Merkle-Patricia Trie committments for certain data fields in messages passed between the EL and CL clients. These proposals primarily require support from execution layer clients with minimal changes to consensus layer clients. For that reason, the Prysm team defers to the Execution Layer teams on whether or not these EIPs should be included in Electra. Furthermore, we do not support modifications of the SSZ spec to include Optional types until there is a consensus or execution spec that uses that feature.

No Support

EIP-7251: Increase Validator Max Effective Balance

The idea to allow increased validator balances paves the way towards validator consolidation, allows compounding rewards, and staking arbitrary amounts above 32 ETH (i.e. a validator could stake 40 ETH and earn rewards proportional to their stake.) This benefits large and small stakers. However, the changes required to the beacon chain node are relatively high complexity and touch many areas of the protocol. We believe this EIP should be bundled with EIP-6914 to reuse validator indices to have the most impact. Lastly, we believe the timeline for Electra, aiming to land by the end of the year, would not allow for sufficient design, implementation, and testing of any proposal that affects such a large portion of the application. Therefore, we do not support this proposal in Electra if our intentions are to land the upgrade on mainnet in 2024.

EIP-7547: Forced Inclusion Lists

Transaction censorship on Ethereum has become an increasing concern with the mass participation of validators in the mev-boost ecosystem. These externalized builders have a centralizing factor and many of them openly admit to censoring transactions. The main idea behind a forced inclusion list proposal is to require a block proposal to include a previously defined set of transactions in the next block. This is considered a list of transactions that must be included for the block to be valid in protocol such that a victim of censorship could place their transaction into the inclusion list and it cannot be censored. The Prysm team favors the ideas behind this proposal, however we do not support shipping this within Electra to land in 2024.

EIP-7594: Peer Data Availability Sampling (PeerDAS)

The main idea behind PeerDAS is to strengthen data availability by an error-correcting technique: we double the amount of data to make available, but validators only need to download half of it to recover the full set. This technique ensures that data will be available even in the presence of malicious validators that drop it. In addition, this EIP includes a new scoring system to penalize validators that do not have the data they advertise as available, and allows honest validators to help others requesting blob data.

The Prysm team is leaning towards not supporting this EIP for Electra, unless it is completely specified soon and it is a reasonable implementation complexity. In its current status we feel that supporting this PR will delay the scope of Electra as this proposal is quite new and may not be fully specified with enough time to start design, implementation, and testing of the feature with sufficient time to land in Electra in 2024.

Thanks to everyone on the Prysm team for providing feedback.