Lodestar Glamsterdam Upgrade Proposal
As the Fusaka hard fork nears deployment on mainnet, the Lodestar team continues to push towards their Zig transition alongside participating in scoping the Glamsterdam hard fork. We made it clear that Glamsterdam was an important upgrade in optimizing Ethereum's slot restructuring via EIP-7732 and the focus now shifts towards additional EIPs for inclusion.
TL;DR
- EIP-7805: We strongly believe that censorship resistance needs to be included with Glamsterdam. We believe delaying Glamsterdam and/or simplifying ePBS so we can include a censorship resistant mechanism with ePBS is important for the protocol. We currently estimate an additional engineering effort of ~2 weeks for implementation of rebasing FOCIL on top of ePBS for our client only
- EIP-7688: We support inclusion of compatible consensus data structures for reducing maintenance churn for important staking ecosystems relying on beacon data in smart contracts
- EIP-8045: We support inclusion of excluding slashed validators from proposing for chain health in non-finality situations, as demonstrated by the Holesky rescue
- EIP-8071: is overall a low priority as it doesn't create a security issue for the chain, even though it is a design flaw in how consolidations are used. It is however, a simple fix to an unintended consequence if we choose to include it
- We overall do not support the following maintenance EIPs and would prefer to see a more thorough Meta-EIP to fix flaws in Heka:
- EIP-8061: We do not support increasing churn limits until more research has been completed on tradeoffs and more consensus is formed by other parts of the community affected by changing staker dynamics. We believe in a security-first approach over staking UX and the better question to primarily ask is "what is a safe weak subjectivity period?" However, we would be open to having a separate churn limit for consolidation because its purpose is different from entry/exit queues
- EIP-8062: This is overall a low priority and has bad optics on burning/charging fees on the consensus layer, which has no precedence. In addition, there is no clear data to show that this will be impactful for 0x02 migration and consolidations are potentially lagging in adoption due to downstream governance delays from staking entities
- EIP-8068: We do not support neutral effective balance design because the proposed thresolds feel overly complex, the severity of the issue is unclear without data on its gamification and we would much prefer a broader plan for how to deal with consolidations rather than band-aid solutions such as this
The importance of censorship resistance: Why FOCIL matters now.
Phil Ngo
Ethereum has a unique property unlike any other Layer 1 blockchain. The community and the technological structure of Ethereum's protocol is meant to ensure we preserve its permissionlessness and decentralization ethos.
Block production is an important function of the blockchain but is naturally, a centralizing mechanism that is ripe for capture. Whether it's the lack of diverse builders, relays or stakers, it is clear that a "winner take most/all" is inherently incentivized within the protocol for maximum rewards. Off-protocol block production such as MEV-Boost generally capture a consistent ~90% of blocks on mainnet because of its larger rewards for stakers, which also birthed the concept of smoothing pools for sharing these rewards. This also means that builders who can build the most valuable blocks, generally squeeze out the competition and capture the ability to dictate what makes it into a block and what doesn't, hence, censorship.
As we work towards enshrined proposer-builder separation (ePBS) via EIP-7732, we confirm what we've tried so hard to avoid: Admitting that local block building is not viable long-term on Ethereum. In the early designs of Ethereum's proof of stake system, we hoped that block production and block validation would be run by a diverse group of individuals alongside professional node operators. That diversification is what gives Ethereum its edge in remaining the world's "hardest" (irrevocable and irreversable) global settlement layer for digital assets. Over time, fewer solo node operators have emerged than originally hoped for. Secondly, we need to counteract builder centralization urgently.
This is why we feel it is important for us to include EIP-7805: Fork-Choice enforced Inclusion Lists (FOCIL) as part of Glamsterdam. Delaying this EIP induces uncertainty with its inclusion at all as we keep having to rebase it on other changes such as six second slots (anticipated headliner of the Heka hard fork). This is a huge risk and the engineering effort is worth the additional time required to ship Glamsterdam. We currently estimate the additional time at ~two weeks based on the specification details for implementation on top of ePBS.
In addition, the benefits of FOCIL accrue to other layers of the protocol such as Layer 2s which would allow for optimistic rollups to reduce their challenge window. This creates another desirable effect, making finality faster on Layer 2s where a lot user-based activities live.
We generally believe that FOCIL implementation is worth an additional delay in shipping Glamsterdam.
Other EIPs for Inclusion Consideration
EIP-7688: Forward compatible consensus data structures
We are in favor of including EIP-7688, which has now been rebased on top of Gloas. This EIP introduces generalized indices across forks, reducing the maintenance churn (involving security councils) for builders that consume beacon data in their smart contracts, and is mostly benefiting staking pools (e.g., Rocket Pool, Diva, Lido) and our ethos of trustlessness.
EIP 8045: Exclude slashed validators from proposing
We are in favor of including EIP-8045. This is a straight forward change that will improve chain liveness should there be unforeseen events such as a mass slashing. We want to maximize including any EIPs which will positively impact chain performance, especially during periods of instability. Every block proposed on an unstable chain is valuable and we want to minimize opportunities for missed slots because a validator scheduled to propose has already been slashed.
EIP 8071: Prevent using consolidations as withdrawals
We are weakly in favor of including EIP-8071. This simple fix in the protocol is an oversight and the unintended consequence is that the consolidation queue is being used for a purpose it was not designed for to circumvent the withdrawal queue. Although, we believe that it makes sense for us to correct this, this is not a priority as it does not pose a threat to security.
Other EIPs for Exclusion or Deferral
EIP 8061: Increase churn limits
We believe that this EIP requires more research to identify additional unintentional or predictable consequences downstream to the protocol before inclusion. This change introduces tradeoffs in chain security for staking experience with no additional benefit to Ethereum ethos, such as decentralization. Entering or exiting the protocol should be constrained by the volume of those looking to enter or exit the validator set for the preservation of chain security. Native staking should always been seen as a long-term commitment and not a predictable mechanism to make capital as efficient as possible. There are offchain markets (e.g. liquid staking tokens, CEXs) which serve and also take the risk of offering faster churn whilst the protocol itself remains as secure as possible.
This EIP also prematurely sets parameters that require additional time to investigate. We need to thoroughly understand all/most of the risks of reducing the weak subjectivity period and finding a minimum period required which balances staking experience and security of the chain. Then, we can derive optimal limit sizes for queues. We need to answer, "what is the right duration for the weak subjectivity period" first.
In addition, this EIP will also affect the incentives related to staking issuance and rewards which require additional scrutiny from its changing staking dynamics. We currently do not have any data, feedback and opinions from other parts of the community to justify the large scope of this change. It is not a purely technical decision to change these queues.
A research discussion was also raised about potentially investigating a priority-fee mechanism for faster withdrawals. There is currently no proposed design or research to cite. However, there may be future options in the near future to debate how to solve for faster queues without sacrificing chain security.
EIP 8062: Add sweep withdrawal fee for 0x01 validators
We are not in favor of including EIP-8062. Although we believe that migrating to a smaller active validator set is important for Ethereum's roadmap, we do not think there is definitive proof that this EIP would force migration to 0x02 and this would create precedence for adding fees on the consensus layer for regular operations, which is optically negative.
EIP 8068: Neutral effective balance design
We are not in favor of including EIP-8068. The gamification identified by this EIP needs to be supported with more data that this is occurring. The proposed thresolds feel overly complex and without the data, the severity of this issue is unknown. We would much prefer to see a plan to overhaul the consolidation process with a simpler design, which includes addressing issues such as this for Heka.