Pectra Retrospective

Magicians Process Improvement
,
26

Reth team has gathered opinions on Pectra scoping and development internally, here is the aggregated summary our thoughts:

EIP Consideration

Currently, the EIP is considered ready when it has been summarised, the spec has been defined and sufficient number of community members have discussed it. Then the champion of the EIP brings it on a wider ACD discussion forum and it can be considered for inclusion. The crucial step that we think is missing from this process are test vectors. This would make implementation easier for every client as well as put the authors into the mindset of encoding and possibly discovering the edge cases that their change presents.

Scoping

Pectra scoping has effectively started after Dencun has landed on mainnet and lasted essentially for almost 9-10 months (until the last EIP inclusion). We are strongly opinionated that ACD collectively should:

  • normalize considering EIPs for inclusion for the fork after next (later referred to as fork n + 1)
  • freeze “major” EIPs for the fork n + 1 , by the time fork n lands on mainnet
  • consider committing to a fixed fork schedule (e.g. 2 forks a year)

Testing

We should define a clear set of requirements for clients to be included in devnet on launch. These must include passing all necessary engine Hive test and could include having run an interop devnet locally with 2 or more other clients.

Devnet Parallelization

At this moment, we think that devnet parallelization (simultaneously running devnets for fork n, n + 1, n + ...) is a complex change to the current ACD process and requires more discussions. While we are not against the change, we do think that it introduces a set of challenges/questions including but not limited to:

  • fork activation: should we run fork n + 1 devnet with changes from fork n or should it be an isolated devnet?
    • the former approach puts additional strain on developers to troubleshoot potential bugs from fork n on fork n + 1 devnet
    • the latter approach requires downstream rebase of the changes which is time consuming and might introduce additional bugs
  • what to do with interdependent EIPs across forks?

Summary

We think that first and foremost we should define and change the fork scoping process and are open-minded to future changes with regard to devnet testing.

7 Likes