Prysm on Pectra split

# Prysm on Pectra split This is a short note to gather our team thoughts on the incoming Pectra fork splitting, future forks scoping and a retrospective on what went wrong in this fork planning. Pectra scoping was determined a few weeks after teams put out documents with their preferences on what to include on the fork. As it is clear from [that report](https://medium.com/offchainlabs/prysm-electra-upgrade-f827c20d0fd2), Prysm has always been very conservative in the set of features that it wants included per fork. This is rooted in our past experience with delays and rescheduling due to testing and last-minute bug findings. Had we stuck to this philosophy of having a *small fork* from the beginning, we would not be where we are today. Most importantly, Prysm refrained from proposing EIPs that we believed (and still do) to be urgent for inclusion, because of a sensed agreement in having such a small fork. We find ourselves under a different situation. The root of this situation is very simple to explain :::info Some of the features of Pectra are ready, fairly tested and productionized. Some others are still under development and require much more testing. ::: The first question we need to ask ourselves is **Do we want to split the fork?** We believe the best we can do at this stage is to answer **yes**, ship the fork as soon as possible and start working immediately on the next one. We believe that the overhead of having an extra fork will be minor (or rather has already been paid) given that all the testing infra is already in place for the next fork (AKA *PectrB*). As such we believe the best approach is to freeze immediately any spec changes to *PectrA* and work on having clients ready for testnets soon. We propose the set of EIPs collectively known as *devnet 3*, with the understood changes to the spec that are already merged (for example [consensus-specs/3875](https://github.com/ethereum/consensus-specs/pull/3875)). While we would be open for inclusion of EIPs that we have already implemented and represent no extra work on our part (for example a CL-watered down version of [EIP 7495](https://ethereum-magicians.org/t/eip-7495-ssz-stablecontainer/15476)), we would **only** consider these for inclusion if all clients already have them implemented and are ready to test them. ## Future forks Some core-devs expressed concerns about rescoping *PectrB*. While we understand and empathize with their frustration with the current situation, we believe that the lessons learned from this and past forks show that we should not try to scope this fork in advance. - Some of the features are close to final/production on many clients and are therefore naturally already considered for inclusion. Explicitly EOF on the EL and Peer-DAS on the CL. The code is still there, we would not divert dev work from Peer-DAS, on the contrary, Prysm has allocated two team members to work exclusively on it and will soon get reinforcement from other team members as they are freed from a frozen *PectrA* spec. - Some features that were not ready for inclusion at the time of Pectra scoping are getting ready fast. Specifically, we believe that [EIP 7732](https://eips.ethereum.org/EIPS/eip-7732) should be included in *PectrB* since it is - Fully specified - Implementations are deep underway - Is mainnet urgent on its own - It solves many of the problems that we currently have with Peer-DAS and increasing the blob count. - Trying to agree on a set of features in advance (including EIP 7732) is a futile waste of time as Verkle and EOF have shown multiple times. ## Increasing the Blob count In advance for the next ACD call and in connection with some of the above. There have been calls to increase the blob target and limit in *PectrA*. These have been last fueled by [a study](https://docs.google.com/document/d/1mkxfhDNvbT6jFEjH3e6LADsGGh3jEvL_WOt2glFbFfA/edit#heading=h.v2qm0jqcd4bj) from members of the Base rollup team. We believe that this study **does not** correctly support the thesis of a possible increase. In particular, uplink bandwidth has been a bottleneck and a constant source of complains from our users in our Discord server. The numbers on this study refer to average bandwidth while in real node operations, bandwidth is required to quickly broadcast all blobs to all of the network **before the attestation time**. This is a strong constraint for nodes on home connections, particularly so for those that are geographically located in areas away from the main centers of Europe and the US coastlines. There are mitigation that are already being worked out like an [endpoint](https://github.com/ethereum/execution-apis/pull/559) to obtain blobs from the EL's mempool, or the new [gossipsub message](https://github.com/libp2p/specs/pull/548)`IDONTWANT` that was recently implemented on clients. We are not opposed to changing our minds with regards to the current limits in case these mitigations show, in an indisputable and measurable manner, that raising the limits is proven to be safe. Having said so, we are less worried about a moderate target increase (without a max increase), since we have seen already home stakers can indeed take the current limits. However, we would want to see input from the community, in particular regarding tradeoffs with blob base-fee price-discovery and effects under adversarial scenarios like long reorgs and range syncing of nodes. We can't fail to notice that EIP 7732 completely solves this issue, removing entirely the peak bandwidth concerns from stakers, as the builder/proposer will have between 9 and 12 seconds to broadcast their blobs to the rest of the network. :::success This by itself should be a strong case for EIP 7732 together with Peer-DAS. :::