Lodestar's Fusaka Inclusion Perspective
In response to the Fusaka deadline outlined in the All Core Developers March Checkpoint, this blog post summarizes the collective thoughts of Lodestar's perspective on the Fusaka hard fork.
Keep Fusaka Small and Focused
Taking into account some lessons learned from the Pectra retrospective published in February, we are still in favour of smaller scopes for hard forks. We believe that Fulu should only contain:
PeerDAS is a huge feature that touches many aspects of a consensus client implementation. By isolating this feature, we can ensure that the focus is dedicated solely to unlocking scalability for Layer 2s and delivering it as soon as it is stable, without dependencies or risks stemming from other inclusions.
We believe the community should consider including EIP-7892 because unpredictable hard fork commitments should not block rolling out blob increases. With this feature unlock, we will have a mechanism to raise blob counts without dependency on hard fork coordination. If we include this feature, we should have an initial optimistic blob only fork schedule with enough time between each increase to analyze data on mainnet. Should we observe any incorrect hypotheses that put mainnet at risk, we can push "ice-age" type schedule modifications to this blob increase fork schedule.
As of March 27, Alex Stokes proposed an initial blob schedule for feedback. Although, we will likely debate the final scheduling within the next few months, we generally agree with the direction of taking a conservative approach to observe mainnet data to justify the planned increases. The duration between blob increases should be enough time to implement a testing/observation plan which should be satisfied for continuing with the blob increase schedule. Currently, the initial proposal is set at two months. We would like to see that the testing/observation plan includes network metrics and statistics on liveness (e.g. reorgs, missed blocks, blob inclusions, participation rates, bandwidth consumption, etc.).
Although we would like to propose many other important inclusions, we think a Layer 1-focused hard fork to deliver a non-contentious feature unlocks exponential concurrent development for Ethereum and should remain the priority for 2025. To stick with our L2-centric roadmap, we must first and foremost support Layer 2s to create value on the Ethereum stack.
Push other proposals to Glamsterdam
With this in mind, we believe that we should freeze the Fulu specification with the two EIPs mentioned above. Depending on the conversation outcomes of EOF inclusion, a set of execution layer inclusions can be made should a decision be made to drop EOF support and await the delivery of PeerDAS. The considerations of these changes should be contained scopes that affect execution clients only, such as RIP-7212: Precompile for secp256r1 Curve Support. These EIPs should not risk delaying Fusaka if PeerDAS is ready to ship.
All of the remaining proposed for inclusion (PFI) EIPs should shift forward to Glamsterdam for consideration. As previously recommended, we should start planning for Glamsterdam as soon as we have a Pectra mainnet fork date so we can start to plan for n+2 forks ahead, a recommendation made by us from the Pectra retrospective.
Contribute to Lodestar!
At ChainSafe, we’re constantly seeking exceptional talent to join our teams and welcome contributors to the Lodestar consensus client. To any TypeScript developers looking to take on challenges and push the boundaries of the JavaScript ecosystem, get in touch!
To get involved, visit our GitHub repository
If you wish to contact the team, join Chainsafe's Discord in the #lodestar-general channel or explore our job openings page. Alternatively, you can email us at info@chainsafe.io.
Remember to visit our official website and follow us on Twitter for more updates.
Lodestar is built and maintained by ChainSafe.