At Nethermind, we pride ourselves on having experts across all levels of the blockchain stack and beyond, with freedom to express their own views. In this article, we present the views of Nethermind Research on Glamsterdam. These views are not necessarily representative of other teams within Nethermind, e.g. Nethermind Client, Nethermind Infrastructure, Nethermind Security, etc.
What stakeholder category do you represent?
Ethereum Protocol Research and Design.
What do you view as the top priority theme in this fork & why?
Decentralization
Which EIP(s) do you favor as a headliner for Glamsterdam?
CL: FOCIL
EL: Block-level Access Lists (BALs)
If known, what specific impacts would this have on your community?
FOCIL: This is a clear signal that Ethereum is prioritizing censorship resistance. Although the censorship resistance of FOCIL is limited to eventual censorship resistance and vanilla transactions (non-blob transactions), FOCIL stands as an important first step towards censorship resistance. In addition, exciting research have been proposed to improve FOCILâs bandwidth consumptions and extending censorship resistance for blobs. Furthermore, once the validator set can reliably enforce eventual censorship resistance, the protocol can rely more on sophisticated block builders (or execution proposers under APS). A foundation of sophisticated block builders, in turn, clears a path to bolder scalability directions, such as ZKâifying L1 execution, where we must rely on sophisticated builders (or execution proposers) to keep full state, execute transactions, and potentially generate proofs.
BALs: BALs lay the groundwork for efficient parallel execution in the EVM. Although extra engineering is still needed to make full use of them, BALs are an essential first step. An exciting followâup is to charge less gas for âwarmâ slots that remain in cache and more for âcoldâ slots. This ties fees to actual disk work and largely mitigates the negative impact of state growth without complex schemes like state rent or expiry.
Does anything make this an urgent feature for you or your community?
Both are necessary upgrades.
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
Although we acknowledge that ePBSâs decoupling of block validation and payload would be good for Ethereum throughput in isolation, ePBS introduces the well-documented free-option problem. We believe the free option problem needs to be addressed before ePBS is included. Removing the need to commit to a transaction payload in order to receive attestations may alleviate the problem, but the exact implementation of this needs further work. The referenced solution introduces slot auctions, which come with wellâdocumented drawbacks. Furthermore, slot auctions give rational proposers a strong incentive to bypass the inâprotocol auction altogether, calling into question why the in-protocol auction mechanism is needed. It may be worth exploring pipelining-only designs that exclude auctions from scopeâfor example, by embracing the fact that a PBS auction will occur out-of-protocol at the PTC deadline.
Delayed execution removes execution from the critical path, similar to ePBS, yet keeps the protocol simpler, as it avoids PTC, trustless payments, fork-choice modification, etc. However, the current design only pipelines execution, leaving payload broadcasting in the critical path. There are discussions about adding a delayed payload broadcast on top of delayed execution. However, this idea is still in its early stages and requires review for potential issues, such as the free-option problem. Adopting delayed execution first and extending it later may be a viable plan, but only if executionâonly pipelining alone proves valuable enough. We require more evidence that this is the case.
Shorter slot times improve UX and reduce the sizeable amounts of MEV that depend on slot time. All else equal, shorter block times also boost censorship resistance by accelerating proposer rotation and can shrink the window from mempool arrival to block inclusion in FOCIL. However, the risk of validator centralization, as highlighted by Flashbots, requires deeper study. Furthermore, we still need a thorough analysis of how shorter slot times interact with other proposals. Even if not scheduled for inclusion in Glamsterdam, we recommend initiating such analysis as soon as possible, given the likely benefits and potential impact of shorter slot times. We want to see shorter slot times incorporated as soon as this analysis is completed and no major issues arise.
Any additional comments?
Nethermind Research are strong believers in introducing some form of attestor proposer separation (APS). The primary reasons are to preserve the decentralization of the validator set, and addressing the shortcomings that a decentralized validator set introduces with respect to proposer duties. Within the APS design space, there are several designs that would handle the identified risks of both ePBS and faster slot times.
