What we think should be included:
Fulu is fundamentally about PeerDAS (EIP-7594). Given its complexity, it should remain the centerpiece of this fork and we should keep scoping outside of PeerDAS very tight.
We strongly support EIP-7892 (Blob Parameter Only Forks) as it directly supports PeerDAS. The primary motivation here is flexibility: allowing blob count increases without requiring full-scale hard forks. This flexibility will enable us to respond quickly to capacity demands as they emerge. Additionally, it simplifies testing by allowing us to easily modify blob limits on testnets. We've prototyped this in Lighthouse and Reth, showing it's achievable in roughly 100 lines of code each.
We acknowledge that there’s ongoing discussion about the best method for implementing Blob Parameter Only forks, such as introducing staker-voted blob limits similar to the current gas limit voting mechanism. However, since our main goal is shipping PeerDAS quickly, we would advocate for a minimal configuration-based approach first. In future forks we can migrate to on-chain staker-voted blob limits if desired.
What we are on the fence about:
EIP-7917 (Deterministic Proposer Lookahead): We strongly support modifying the protocol to best support based and native rollups. Offering fast and reliable pre-confirmations is a key part of that. However, it appears that the chance the function compute_proposer_index (Electra spec) returns distinct proposers is extremely low (less than once per year). We would like to see supporting evidence to disprove this claim. See: https://hackmd.io/@dapplion/eip7917_statistics
What we don’t think should be included:
We do not support the inclusion of EIP-7732 (Enshrined PBS) due to its complexity and the risk of enshrining heavy technical debt for dubious benefits. The footprint of this change would be broad in the Lighthouse codebase and would very likely delay the fork.
Likewise, we believe EIP-7805 (FOCIL) should not be included in Fulu. However, it could be a very high value, relatively low complexity change in a fork following Fulu.
EIP-7898 (Uncouple execution payload from beacon block) is primarily a networking optimization and does not materially advance the Ethereum roadmap, so should be excluded from the fork. Additionally it is a large change including the bulk of the work from EIP-7732.
EIP-7688 Stable Containers is a very useful quality of life feature and would be beneficial to the ecosystem at large. However, at this stage, it does not appear that Fulu will alter any generalized indices and so the urgency of this EIP is significantly reduced. Assuming that remains true, we are of the opinion that Stable Containers should be implemented soon, but after Fulu.
Some execution opinions:
We are not going to comment on the technicals of EOF, only some of the philisophical points surrounding it. We are against ossification of the EVM at this stage, as it risks putting Ethereum at a technical disadvantage as well as driving ambitious engineers and researchers out of the ecosystem. The L1 EVM is the main driver of change ecosystem wide. The idea that L2 innovations will come to L1 has not come to fruition. The interest in Native rollups and EVM equivalence at L2 seem to suggest the reverse. If the fundamental tradeoff is complexity vs stagnation and we would favor complexity.
RIP-7212 (secp256r1 Curve Support) could greatly enhance UX around transaction signing from mobile devices, so it's inclusion should be strongly considered.
We also recommend including EIP-7642 (eth/69 - Drop pre-merge fields) since it directly supports PeerDAS by reducing bandwidth overhead.
Other execution EIPs do not significantly impact our roadmap, and should be considered post-Fulu.