## Thoughts about Splitting the Pectra Fork in Two ##

Initially, the Pectra fork was meant to be relatively small. However, it is widely agreed upon that there is no such thing as a small fork. This is because inclusion of various EIPs warrants a lot of efforts in terms of development, testing and security discussions. Yet, we often fill the time till the fork with more discussions and possible inclusion of dangling EIPs.

For Pectra, a few notable EIPs were included, like the EL-CL requests interface, new transactions supporting code, BLS precompiles, and the pre-verkle storage history modifications. We have already spent 3 devnets in ironing out issues with the included EIPs, and naturally coordinating testing of these simple implementations is still a significant task.

Down the line, however, we also decided to include PeerDAS and EOF into the Pectra fork. From my perspective it does make sense for a large change like EOF to be included before Verkle, lest it loses momentum. When almost all client teams agreed to go forth with EOF, however, we certainly lost the smallness of the Pectra fork.

The discussion is now pivoting towards breaking down Pectra into two forks, let's say Pectra-1 and Pectra-2. On the surface it makes sense to ship unrelated EIPs in different fork parts. This could potentially let us focus on some of the EIPs first and then move on to the others.

A great example of how we may achieve this is by postponing EOF and PeerDAS to the second split and shipping the rest in the first split. This does inherently add a few extra months before the next fork (Verkle) could happen.

My argument against splitting one fork into two is summarized in the following bullet points

- A split is likely a strategy to distribute implementation efforts for the included EIPs. What's hiding behind this idea is also to put off the decision making around them. Whatever doesn't go to the first split goes to the second. It might be tempting to think that we could put a few things off to the next split, but that's not how it will go. The second split might make for enough opportunities to further discussions and findings for or against the EIPs to be included, making it a full-blown fork on its own right.

- The EIPs on either forks would not be completely exclusive to how they influence each other and it would certainly lead to a lot of last minute changes. This may lead to things like dropping some EIPs, reversing changes made in the first split, more time testing and developing. For instance, say there is a feature/EIP called "A" in parts - A1, A2 and A3. We have decided to include A1 in this split, and A2, A3 in the next one. By the next split A2 might seem like a bad idea, and we could decide to reverse A1 too. The correct thing would be to make the decision to include all of A into one fork or drop it altogether.

- A 2-split fork is essentialy two forks. And if inclusion of x number of EIPs in one fork is hard enough, it's harder to do on two forks.

- We need to get our priorities straight, as difficult as it may seem. For instance, if Verkle is a priority right now, we should make the fork-schedule tuned to shipping Verkle at the earliest. All other EIPs will have to wait. Since we moved forward with EOF already, it would be a good idea, for instance, to only decide whether or not EOF is ready in a few devnets and not talk about any other EIPs CFI'd or included.

- The client teams are already innovating solutions to problems like state growth, efficient code, low-powered clients, resource-optimization etc. So, it may feel tempting to think that we could ship more EIPs since the ones decided are already in the devnets. In reality, every new protocol change pushes client teams back on these optimizations and innovations. So, a new feature in a new EIP is not without costs to overall modernization and/or improvement to how the Ethereum network is run.

In conclusion, more EIPs and split forks are a bad idea as they change the flow of things and negatively affect actual innovation for client teams, while creating more potential for bugs, issues and confusions.

P.S. The above arguments are from a client team perspective