Lodestar

Lodestar's Pectra Split Vision Update

The Lodestar team proposes splitting the Pectra roadmap into two forks—PectrA and PectraB—to ensure mainnet stability, a smoother rollout, and clearer standards for feature readiness.

Phil Ngo

Phil Ngo

— 4 min read
Lodestar's Pectra Split Vision Update
⚠️
Clarification: Edits to the original post have been made to clarify the acronymns and context behind already existing EIP procedures such as "CFI" which is actually "considered for inclusion" and "SFI" which is actually "scheduled for inclusion". This post has been edited to standardize the use of existing procedural terminology.

In our original roadmap vision for Pectra, we proposed shipping Pectra "as-is" to close the scope for the next hard fork with some suggested inclusions. At the time, we had anticipated a small fork with a reasonable shipping timeline of Q4 2024, which we believe is no longer possible for mainnet.

We still agree that we should ship PectrA (more to follow) as soon as possible so that mainnet users can benefit from features in Pectra Devnet-3. However, the included feature specifications should be slightly adjusted to account for minor implementation details.

This leads to the conclusion that Pectra must be separated into two forks, PectrA and PectraB, to minimize the risk of a large change that may adversely affect the stability and reliability of the mainnet. In addition, client teams committed to shipping something before the end of the year, which is no longer possible, even with a fork split.

Due to the current circumstances, there are some things to consider for collaboration at Devcon, as well as what we envision for PectrA and PectraB as an updated scope for implementation.

Close PectrA Now

There is no reason to delay releasing fully implemented features ready for robust testing. Devnet-3 is our first stable network with features that have been anticipated for nearly a year now. We should also proceed with a Sepolia fork as soon as possible so developers can benefit from a testing playground to help find any issues and structure their applications for PectrA deployment as early as possible.

Set Standardized Scope Procedures for Fork-Ready Inclusions

We believe this is one of the main discussion points when planning for the next hard fork scope, including PectraB. A lot of time was spent on ACD this year, discussing an endless scope, undermining the initial consensus of having a small fork in 2024.

We need to set a consistent standard across all proposed EIPs, specifying what a feature must meet to be scheduled for inclusion (SFI) rather than just considered for inclusion (CFI). Being considered for inclusion only outlines what we intend to work on as a spec feature in the short term but doesn't specify when to work on them, what the priority is, or what its current state of implementation is. Therefore, we can have multiple concurrent features being implemented but not guaranteed to make the next hard fork. Naturally, we see client teams working on their own priority features based on what they think is important to them, but not consistently across the ecosystem. There should be some predictable system that minimizes the ambiguity of not just what is CFI'ed but also when it's SFI'ed because it meets the necessary requirements. An example of requirements could be:

  • A complete EIP proposal.
  • Level of urgency for mainnet deployment.
  • A website or centralized repository of information that is consistently up-to-date on feature spec developments maintained by lead implementers (e.g. https://verkle.info).
  • Relevant research, data and reviews of the benefits/risks of such an inclusion.
  • Demonstrative and provable needs echoed by the community of builders and users (e.g., petitions, governance posts, and representative participation/presentations in ACD or async).
  • A testing suite built and ready for client teams to test implementations against.
  • At least one stable client combination for a devnet.
  • A stable and functioning Kurtosis multi-client configured devnet, ideally with the feature built on top of the latest closed fork (e.g. PectrA), awaiting implementation and incremental participation from all client teams.

This is just an example to initiate the conversation of setting what procedural requirements should be expected of CFI'ed EIPs to get to the SFI'ed stage to be included for the next fork, which should be closed off after a period of time (e.g. 6 months after the previous mainnet fork date) and/or by milestone (e.g. first stable multi-client devnet).

PectraB (Estimated Q2 2025)

Assuming we have closed the PectrA discussions, we can now focus on scoping PectraB, which should have little to no change from how we saw the original Pectra. We previously stated that we would like additional EIPs related to enabling forward-compatible containers included with Pectra due to its beneficial value in developer experience. Our proposal for PectraB inclusion for consensus is as follows:

Fulu/Osaka (Estimated ???)

It is likely not ideal to plan further than one fork ahead due to the continuously fast-changing state of the development ecosystem. When closing off a fork scope, we should look at the state of the current development ecosystem and then propose inclusions based on its development against the fork-ready procedures we seek to develop. However, anyone developing CFI'ed EIPs should ideally try to hit all these proposal requirements for SFI scoping when a scoping cycle restarts.

We would like to reiterate the danger of having large changes intertwined with many other large features in one fork. We would rather see a quicker turnaround on hard forks with fewer or completely isolated EIPs, especially if the EIP changes touch multiple, sensitive, established mechanisms that can lead to consensus failure.

TLDR:

  • Pectra should be split into two forks—PectrA and PectraB.
  • A standardized process is needed for each step of EIP progression to avoid delays and improve transparency.
  • PectrA should focus on ready features, while PectraB should add more complex EIPs for consensus.
  • PectrA should be closed with devnet-3 features, while PectraB should include the remaining features scheduled originally for Pectra plus forward-compatible containers.
  • There is no reason to fork scope past one fork when the development landscape continues to change.

Contribute to Lodestar! 🌟

At ChainSafe, we constantly seek 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.

Lodestar is built and maintained by ChainSafe.

Website | Youtube | Medium | Twitter | Linkedin | GitHub

Read more