tl;dr our opinion
We believe the Glamsterdam fork will be a significant effort from developers while focusing on ePBS alone. Still, 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 further CL EIPs should be evaluated carefully to establish if their benefits are needed 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: Raise 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 chief focus of the Glamsterdam fork. We anticipate that the build-out of ePBS will call for 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. Even so we also acknowledge the degree to which the inclusion list will be utilised by the ecosystem stays 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 gives in-protocol protection for local mempool participation in the event relays/builders decide to censor transactions.
- Implementation is reasonably well thought through with multiple client implementations - noting these are not yet rebased on ePBS.
- Delaying build-out of FOCIL until after ePBS may result in a period of plausible censorship on the network.
Cons
- Adding FOCIL may impact delivery timelines. ePBS will be a intricate and difficult change to make on its own.
- Calls for 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 as a rule with the idea, and believe it would give some benefit to the network in a large scale slashing scenario (e.g. if 50% of validators were slashed). Even so, we are confident in the current recovery apparatus 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
- Further work on top of ePBS.
- Benefits not well defined given plausible 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 materially 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 current smart contracts and/or have unforeseen impacts in the wider ecosystem.
EIP-8061: Grow 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 brought in and it should not be employed as a priority exit queue. 8071 more straight addresses this issue and would be materially less involved to build, which we are preferencing with the perspective of ePBS and FOCIL build-out.
If this is the case, we would like to see better articulation of the risks around modifying weak subjectivity. We note that with ePBS, builders may slow down the exit queue more than it right now is and the raised churn limits may be justified.
Pros
- Smaller delays in proposer activation/exit/consolidation queues through tripled limits.
- Raises 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 stay 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. Further 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 called for for the roadmap to fast finality.
Cons
- Rolls out new fees for validators.
- A minimal fee is unlikely to achieve the aims of the change, encouraging consolidation, while introducing significant complexity. The benefits of this change relative to its complexity are not well articulated.
EIP-8068: Neutral Effective Balance
Recommendation: Alike 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 build-out did not involve further fields added to the validator and/or as part of a larger, more targeted EIP to encourage consolidation.
Pros
- Raises fairness between compounding and skimming validators.
Summary
Our chief focus should stay 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 extra scope against the complexity and delivery timeline of ePBS.