# EthereumJS Thoughts on Pectra and Beyond June 6, 2024 This document is about giving a somewhat structured take by the EF JavaScript team on a potential imminent Ethereum mainnet (L1) fork setup and structure, following takes from [Reth](https://docs.google.com/document/d/1IfOnozIhp93qkqZ7Jt-jVUvcdRDAv7HOdP4lnsOpu74/edit#heading=h.6ekswrac8es6), [EF DevOps](https://notes.ethereum.org/@ethpandaops/pectra-fork-thoughts), [Lodestar](https://blog.chainsafe.io/lodestar-pectra-roadmap-vision/) and [Besu](https://consensys.io/blog/besu-maintainers-on-the-pectra-fork) (not fully sure if this list is complete). We have extensively discussed this during our team call on Wednesday, June 5 and aligned (or not) positions from the different team members. ## Our Situation Just to give an overview on where we are regarding our insights into the different included discussed EIPs: we had a small presence at the Kenya core devs interop and successfully participated in the [pectra-devnet-0](https://notes.ethereum.org/@ethpandaops/pectra-devnet-0#Client-implementation-tracker) testnet. We have a working EIP-3074 implementation but haven't started on EIP-7702 (somewhat evolved version of 3074). Gajinder ([g11tech](https://github.com/g11tech)), being both on our and the Lodestar team, has done a PeerDAS implementation on the Lodestar side. We are actively engaged in Verkle testing and have participated in the latest testnets, Gabriel ([gabrocheleau](https://github.com/gabrocheleau)), also Gajinder, are the main experts (and contact persons) on this. Jochem ([jochem-brouwer](https://github.com/jochem-brouwer)) is following EOF development for quite some time, has done an early (and now outdated) full implementation and has now started on a [new one](https://github.com/ethereumjs/ethereumjs-monorepo/pull/3440) aligning with the latests Mega specs. This has substantially advanced but is not finished yet (~ at 50-60%). Holger ([holgerd77](https://github.com/holgerd77)) leads the EthereumJS team and can serve as a general contact person. ## Fork "Design" Considerations We do not want to give a full picture and stances here on "everything", since a lot has already been written and discussed and we can generally align with a lot of reasoning being done. So this document just emphasizes some things we think are important to consider. ### To Mega-Fork Or Not Currently discussed is the option to expand the current Pectra fork scope by including EOF and therefore do some kind of "Mega Fork". There is the notion of "Ethereum is historically better at big than at small forks" floating along. We regard this notion as describing the situation as "too binary" and while it has turned out that (too) small forks have high economic fixed costs there is nevertheless rather some "complexity equilibrium" where a fork size "finds its balance". While it is very true that client teams have improved a lot on their ability to manage forks and the overall process (management) has "professionalized", there is still some natural tenedency that the single parts in a fork get less and less attention the bigger a fork grows. While EOF might appear reasonable in size when having a first look at the (very condensed) [Mega EOF spec](https://github.com/ipsilon/eof/blob/main/spec/eof.md) a second deeper dive into the various (12) [separate EIPs](https://github.com/ipsilon/eof/blob/main/spec/eof.md#appendix-original-eips) though reveals that most of these EIPs have at least a mid level of complexity on its own and EOF on its own bears a complexity we formerly had for single hardforks alone. We therefore have a somewhat strong tendency to consider it - with all improvements on the tooling/process front - as too (and eventually: unnecessarily) risky to bundle EOF with the current already substantially sized fork scope. There are literally hundreds of edge (and general functionality) cases on EOF (behaviour of new opcodes, container/stack validation, substantial contract creation & control flow changes). All this deserves the full attention both by getting a very sufficient test coverage by the cross client tests as well as being tested thoroughly on the official testnets once deployed. It is also to be considered that EOF will cause a high level of disruption and the need to adopt "upstream", both on the higher levels of the wider protocol stack (Solidity, Vyper, Other) and the subsequent infrastructure and tooling (wallets with an eventual interplay on AA integration), integration tools like Ethers/Viem & literally everyone using the EVM. We do think it has benefits (and might be enough) if these parties have "only" this one big thing to concentrate upon and adopt along one fork go. Lastly to say: the current Pectra fork scope already has some solid amount of complexity to handle, and there is also the risk the other way around of *these* changes "falling under the bus". The BLS precompiles provide a very large surface for consensus failures and need to be thoroughly tested. And native AA introduction with EIP-7702 is a big step for the Ethereum network and should be thoroughly accompanied. For the above reasons we would somewhat strongly prefer to not bundle all this into one fork. If decided we could also live with the "one fork to rule them all" option though. ### EOF Importance and EOF/Verkle "Research Curves" While we do see heavy inherent complexity coming with the EOF changes we do regard EOF as a very important core upgrade to the network bringing a variety of extremely substantial "ground improvements" to the network engine. We won't recite here but can fully align with the summaries being written down on this by Dragan from the Reth team [here](https://hackmd.io/aZurva_kR2GQdOgJfS7B6A?view) or included in the Besu team blog post from above. Comparing the two "research and spec evolution curves" we perceive EOF as more settled, with the refinement parts of the research now literally happening over years while there are still heavier and more substantially spec changes in the Verkle spec, latest the folding of account data fields like nonce or balance into one [basic data field](https://github.com/ethereum/EIPs/pull/8576), as just one example. At the same time we do recognize the high importance for Verkle for the network together with the need to not delay this upgrade in a significant way, reasons sufficiently outlined in other posts and comments. We do think though that doing EOF still before Verkle might not have a delay effect, since both the work itself as well as the testing efforts are extremely distinct and it has already proven that test network deployment can very much happen in parallel. Since touching so different parts of the tech stack it also often turns out that implementation within the teams is mostly done by different persons with the respective expertise, so this might (?) also be not a substantial delay factor. Lastly to consider here: there is some interplay between Verkle and EOF, mostly going in the Verkle direction, meaning EOF and its structure update influencing how code chunking is done in Verkle. This might add to the argument to do EOF before Verkle to not have the need to do "Verkle twice" respectively need to adopt this part of the Verkle structure directly again. Generally we have to say that we do not have the full picture here yet regarding the interplay, also on potential eases or downsides (we have some tendency to think that EOF might rather ease things) and we only somewhat briefly discussed during the latest call. ## Preferred Fork Suggestion The considerations from above lead us to have the following somewhat preferred fork structure: ### 1. October 2024 Pectra Fork We do think it has benefits to keep the current Pectra fork in its current form including EIP-7702. Side note: we do not have any insights into the changes and scope to have any opinion as the side inclusion of EIPs 7495+7688 as proposed [by the Lodestar team](https://blog.chainsafe.io/lodestar-pectra-roadmap-vision/). While we do agree that there is some slight risk to intervene with Devcon - which would be a bit unlucky - we perceive the progress on the testnets as very solid and so the chance to have an in-time and uneventful fork as high. So we think this is a risk worth to live with - especially give the otherwise happening delay-cascade by Devcon and then holidays - and would propose a targeted fork date for early or mid October 2024. ### 2. Q1 2025 EOF (PeerDAS) Fork We would then intentionally propose a somewhat aggressive EOF fork timeline, with the fork being proposed directly for Q1 2025 (likely end of Q1 though) and not e.g. Q2 to not substantially shift the Verkle fork timeline, even if placed before the Verkle fork. This would mean that first EOF testnet forks should basically "directly" happen after Pectra with first forks still being scheduled for this year. Thesis here: if we have made so much progress on tooling/process we can also very much channel these capabilities in orchestrating two forks in a more parallel fashion. 🙂 This would give us a couple of extra months where the full attention/communication/testing can lay on EOF. While we are only "side-educated" on PeerDAS by Gajinder and do not have the full picture here this fork might also be suited to go along with PeerDAS being a distinct complementary feature introduction on the CL side. Also to note: yes, there is this risk of additional EIP demands and "natural fork growth". The agressive timeline together with the already big (and also very much clear and consistent) EOF scope might help to prevent the tempation to "go in" here on ACD-E calls on additional EIP requests. Or more actively framed: this will only work if we **lockdown the scope and entertain no further EIPs in a EOF/peerDAS fork**. Such a fork schedule would also imply for all client teams to **urgently work on EOF** if not already happening in a sufficient manner. ### 3. Q4 2025 Verkle Fork Whew, whew: two forks in one year? Short answer: yes. We do think that we are in a different situation here with these two "mega changes" being EOF and Verkle where research and implementation efforts happened over the years and timing interplay might play out different here than what we had with (most) previous forks. So we think that even with an additional EOF fork in Q1 we have some good chance to keep the schedule "as is". ## Conclusion The above presents another thought line how one can reason about scheduling of the on-the-horizon next 2-3 forks for Ethereum mainnet and we think it is worth to consider. However other teams have laid out their reasoning as well and we can very well also imagine to align with other proposals and go with the respective reasonings presented. This document is not claiming to take all important aspects into consideration and there might be strong arguments not presented here to take an alternative path.