# Teku Glamsterdam's Headliner ## TL;DR The Teku team chose **[EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)** (Enshrined Proposer-Builder Separation or ePBS) as our headliner EIP for Glamsterdam. ![glamsterdam-headliner-rankings](https://hackmd.io/_uploads/rkUf_VUUgl.png) ## Why EIP-7732? (short version) - Slot restructuring allows for more time for blob propagation and more time for block propagation and execution; - Aligned with L1 and L2 scaling [strategic initiative](https://protocol.ethereum.foundation/strategic-initiatives) set by the EF for the next year; - Mature spec (two clients with PoC ready + successful devnets); - Sets the stage for future EIPs (e.g. FOCIL); ## Why EIP-7732? (slightly longer version) #### L1 and L2 Scaling Decoupling execution processing from network propagation allows more time for blob propagation and block propation and execution. This alleviates the bandwidth bottleneck that we have at the moment, supporting our L1 and L2 scaling goals. #### Spec Maturity The spec is already merged and mostly finalised. Consensus tests are being implemented and we already have two clients with PoC implementations ([one being Teku!](https://github.com/Consensys/teku/tree/epbs)) that have been tested in ePBS-specific devnets. This is a crucial point to consider given our expectations of a shorter release cycle between Fusaka and Glamsterdam. #### Setting the stage for future EIPs The separation between consensus block processing from execution payload processing decouples EL and CL (at least on timing requirements), allowing for slightly more independent evolution of both layers. Many proposed improvements like FOCIL, Rainbow Staking and others are dependent on this separation. ## Why not X? #### [EIP-7805](https://eips.ethereum.org/EIPS/eip-7805) Fork-choice enforced Inclusion Lists (FOCIL) We believe that EIP-7805 is a good inclusion for any fork, and we stand behind the design goals behind it (censorship resistance). The main reason for it not being our headliner is because it is not directly aligned to our scaling goals. Also, we believe this EIP can be delivered as part of any fork (including Glamsterdam) so it does not need to be a headliner. #### [EIP-7782](https://eips.ethereum.org/EIPS/eip-7782) (Reduce Block Latency) Despite this EIP also being closely aligned to the scaling roadmap, the main reason for not choosing EIP-7782 as our headliner is because the specification for it are not as mature as they should be, making it hard to estimate the complexity of implementing it. In our opinion, the risks outweigh the benefits of this EIP for Glamsterdam. However this is definetely an item that should be considered for the next fork. It is also crucial that teams get involved on this stream of work so we can evolve the spec and have it ready for a future fork. #### [EIP-7886](https://eips.ethereum.org/EIPS/eip-7886) Delayed execution At a high level, both EIP-7732 and EIP-7886 have a similar concept, where the execution payload can be verified separately from the beacon block validation, aliviating the critical path in beacon block processing. However, comparing both EIPs, we believe EIP-7732 specification is far more mature and, despite requiring more changes in client implementations, is closer to a state to be ready to be implemented (two CL clients have already working PoC of ePBS). Not only that, ePBS has other properties that have better synergy with other future EIPs that are being considered for the protocol. For those reasons, we believe ePBS is a better choice. If you want more details comparing ePBS and other alternatives, check out [this excellent post](https://notes.ethereum.org/@0YxgBRfbR0OTJbu2fDpY2Q/BkyjpOJEgg) by Mark M. from Lighthouse. #### [EIP-7942](https://ethereum-magicians.org/t/eip-7942-available-attestation-a-reorg-resilient-solution-for-ethereum/23927) Available Attestation: A Reorg-Resilient Solution for Ethereum This is a quite-recent proposal and the team hasn't had the time to analyse it completely. The goal behind this proposal solve all known reorg attacks to Ethereum, in a probable way. Potentially, it can simplify our multiple ad-hoc Fork Choice rules that were added over time to mitigate possible attack. It sounds like a great idea and we are keen to better understand this proposal. However due to how recently it was introduced, we don't have enough information to consider it at this point in time. #### [EIP-7919](https://eips.ethereum.org/EIPS/eip-7919) Pureth Pureth combines many improvements to Ethereum data availabilty, removing the need of trusted RPC providers. This is a good addition to the protocol. It does not fit as our CL headliner given the fact that most of the changes are EL-related. As a matter of fact, in Teku we have already worked on most of the changes associated to this EIP (e.g. Stable Containers), but they are not being used yet.