Glamsterdam EIP Preferences

tl;dr our opinion

We believe the Glamsterdam fork will be a significant effort from developers while focusing on ePBS alone. However, given the support from the community for FOCIL, and the timeliness around its likely inclusion, we believe we should also attempt its implementation in Gloas.

We note that this will likely put teams at capacity for delivery depending on the anticipated fork date. With this in mind, any additional CL EIPs should be evaluated carefully to determine if their benefits are required for Gloas, or can be reasonably delayed to Heka, or later.

A brief summary is shown below, with reasoning given in the following sections.

Glamsterdam EIPs

Scheduled for Inclusion

• EIP-7732: Enshrined Proposer-Builder Separation (ePBS) - Headliner and focus of the fork.

Considered for Inclusion

• EIP-7805: Fork-Choice Inclusion Lists (FOCIL) (CL) - Support inclusion.

Proposed for Inclusion

• EIP-7688: Forward compatible consensus data structures - Do not support inclusion.
• EIP-8045: Exclude slashed validators from proposing - Do not support inclusion.
• EIP-8061: Increase churn limits - Support either this EIP or 8071 for inclusion, with the preference for 8071.
• EIP-8062: Add sweep withdrawal fee for 0x01 validators (CL) - Do not support inclusion.
• EIP-8068: Neutral effective balance design (CL) - Do not support inclusion.

Discussion

EIP-7732: Enshrined Proposer-Builder Separation (ePBS)

ePBS is the headliner and primary focus of the Glamsterdam fork. We anticipate that the implementation of ePBS will require significant developer effort and attention, so much so that any other EIP being considered must be evaluated against its impact on the ability to deliver EPBS in a timely fashion.

EIP-7805: Fork-Choice Inclusion Lists (FOCIL)

Recommendation: We support inclusion of FOCIL (SFI), noting that this will have some impact on the rate at which we can deliver ePBS. FOCIL appears to have significant community and developer support and addresses a key emergent censorship and centralisation risk. However we also acknowledge the degree to which the inclusion list will be utilised by the ecosystem remains unclear, and there is likely to be some opposition based on nation state pressure to censor or sanction transactions.

Pros

• The decline of local block building impacts overall censorship resistance. FOCIL provides in-protocol protection for local mempool participation in the event relays/builders decide to censor transactions.
• Implementation is reasonably well thought through with several client implementations - noting these are not yet rebased on ePBS.
• Delaying implementation of FOCIL until after ePBS may result in a period of potential censorship on the network.

Cons

• ePBS will be a complex and difficult change to make on its own. Adding FOCIL may impact delivery timelines.
• Requires a new committee for inclusion list building.
• The demand for the inclusion list relative to its complexity is uncertain. This may mean we spend considerable effort on a feature that goes unused.
• FOCIL may attract opposition from nation states or other entities interested in enforcing censorship of transactions.

EIP-8045: Exclude Slashed Validators from Proposing

Recommendation: We do not support the inclusion of this EIP (DFI). We agree generally with the idea, and believe it would provide some benefit to the network in a large scale slashing scenario (e.g. if 50% of validators were slashed). However, we are confident in the existing recovery mechanisms for this scenario and don't believe the complexity of the change, on top of ePBS and FOCIL, is justified by the benefits.

Pros

• Helps network resilience during mass slashing events.
• Blocks from slashed validators are considered invalid; selecting slashed validators serves no purpose.

Cons

• Additional work on top of ePBS.
• Benefits not well defined given potential complexities.

EIP-7688: Forward Compatible Consensus Data Structures

Recommendation: We do not support the inclusion of this EIP (DFI). While we agree that there is value in this change, we recommend considering this for the next fork (or lean chain) or waiting for snarkification work to be more significantly advanced. We believe, at the moment, the cost of transition is likely to be worse than maintaining indexes.

Pros

• Proposes new consensus data structures that would be forward compatible across forks, allowing developers to not break merkleization across fork boundaries when changing fields.

Cons

• Touches a lot of code for a benefit that is largely developer focused.
• May break existing smart contracts and/or have unforeseen impacts in the wider ecosystem.

EIP-8061: Increase Churn Limits

Recommendation: We would conditionally support either 8061 or EIP 8071 for inclusion with the aim of addressing the consolidation queue withdrawal bug. We do not believe this was the intended behaviour when the queue was introduced and it should not be used as a priority exit queue. 8071 more directly addresses this issue and would be significantly less complex to implement, which we are preferencing with the perspective of ePBS and FOCIL implementation.

We note that with ePBS, builders may slow down the exit queue more than it currently is and the increased churn limits may be justified. If this is the case, we would like to see better articulation of the risks around modifying weak subjectivity.

Pros

• Smaller delays in proposer activation/exit/consolidation queues through tripled limits.
• Improves opportunity costs for validators.
• Addresses consolidation queue skip issue.

Cons

• Affects weak subjectivity period.
• We would need to see the benefits for this change be articulated more explicitly.

EIP-8062: Add Sweep Withdrawal Fee for 0x01 Validators

Recommendation: While we do not support this change for inclusion in Glamsterdam, we acknowledge the aims and benefits of validator consolidation. At this stage we would suggest this EIP remain Proposed for Inclusion (PFI) as we would like to hear the benefits articulated more clearly before fully supporting.

In particular, the fee of ~$2/year per 32 ETH validator does not seem impetus enough to encourage transition while also introducing significant complexity. Additional fees will always attract negative opinion from the community and we believe that if we are to encourage consolidation, it should be done more decisively.

Pros

• Incentivizes 0x01 validators to move to compounding validators.
• Consolidations are beneficial for the network and required for the roadmap to fast finality.

Cons

• Introduces new fees for validators.
• The benefits of this change relative to its complexity are not well articulated. A minimal fee is unlikely to achieve the aims of the change, encouraging consolidation, while introducing significant complexity.

EIP-8068: Neutral Effective Balance

Recommendation: Similar to 8062, while we do not support this change for inclusion in Glamsterdam, we acknowledge the economic disparity from effective balance treatment differences between 0x01 and compounding validators.

We would be more likely to support this EIP if the implementation did not involve additional fields added to the validator and/or as part of a larger, more targeted EIP to encourage consolidation.

Pros

• Improves fairness between compounding and skimming validators.
• Provides reward-based incentive to consolidate - though noting one aimed at parity not positive incentivization.

Cons

• Requires two new fields on validators: temporary_upward_threshold and reset_eb.

Summary

Our primary focus should remain on successfully delivering EIP-7732 (ePBS) as the core feature of Glamsterdam. While we see value in FOCIL and certain other EIPs, we must carefully balance additional scope against the complexity and delivery timeline of ePBS.