# Pectra fork thoughts The pectra interop event was an amazing way for the entire team to deep dive into the EIPs and their potential testing implications. As a result of which, we wanted to write down some points as to what fork options we think are viable. Before we start, here is a TLDR of fork options and their generic purposes (according to our view): | EIP # | EIP Name | Changes | | -------- | -------- | -------- | | EIP-2537 | Precompile for BLS12-381 curve operations | EL specific EVM changes | | EIP-2935 | Save historical block hashes in state | EL specific EVM change | | EIP-3074/7702 | AUTH and AUTHCALL opcodes | EL specific EVM change | | EIP-6110 | Supply validator deposits on chain | Affects validator onboarding & Needs EL/CL changes | | EIP-7002 | Execution layer triggerable exits | Affects validator offboarding & Needs EL/CL changes | | EIP-7251 | Increase the MAX_EFFECTIVE_BALANCE | Affects entire validator lifecycle | | EIP-7549 | Move committee index outside Attestation | CL specific change | | EIP-7685 | General purpose execution layer requests | Needs EL/CL changes | There are two more EIPs/features that have been extensively looked into: - EOF - EL specific change - PeerDAS - Mostly CL specific change, with minor EL involvement ## Thoughts and concerns: While most forks have EIPs that are relatively self-contained, Pectra currently has multiple EIPs that interact with each other quite intimately. An example of this interaction is EIP-6110,EIP-7002,EIP-7685 and EIP-7251. In these sets of EIPs, we are changing the deposit flow of a validator, the communication method of deposits from EL->CL, the validator effective balance(And consolidation related complications) as well as the exit trigger for the validator. This would mean we can no longer just test an EIP in isolation, but instead we would have to test the edge case of each EIP with all other EIPs in said list. This sort of edge case related EIP testing would increase the scope of testing by a large amount as well as make for a riskier fork in itself. A counterpoint to the above argument is that we would test edge cases irrespective of if we ship features across one or two forks. Another concern is that delaying PeerDAS by a significant margin would impact the scaling roadmap of Ethereum. We would ideally want to see PeerDAS delivered in a timely manner or a blob throughput increase (e.g: EIP-7691). We also haven't included EIP-4444 in our discussions so far. It currently seems like it would need some co-ordination and a fork for a rollout(not 100% sure on this yet). Based on the unsure rollout plan, we would prefer to not include EIP-4444 in the scope of pectra. Keeping the above thoughts in mind, we wanted to see what options we could have for the fork. ## Fork options: 1. Mega Fork (All EIPs/features included): - We have historically been bad at small forks, but good at big ones. So this option is to include all proposed EIPs as well as EOF and PeerDAS into one mega fork - The testing efforts for this fork would indeed be massive and take time, but achievable if the protocol demands it - The inclusion of all these changes would imply an extremely high chance that the fork doesn't happen in 2024 and would indeed occur sometime in mid/late 2025. However we don't ship forks for the sake of them, but rather ship features and mega fork would indeed ship a lot of features - The fork would be a highly risky one with a lot of room for error, but the payoff would indeed be huge - Mega fork could be tempting to then load on more EIPs into it, making it even bigger as EIPs see it as a last chance to get deployed - This mega fork would mean all EL/CL/Testing teams would have their hands full and leave little time for pre-preparation for the next fork (e.g: Verkle) 2. MaxEB/PeerDAS and EIP-6110/7002/7685 in separate forks, including a CL only fork: - By splitting the two EIP sets into separate forks, we could ensure that the deposit/exit changes work as expected before we touch validator balance with MaxEB - Since PeerDAS needs an activation fork, we could combine that with maxEB in a "CL ONLY" small fork after Pectra - This fork could potentially include EOF in Pectra, meaning post Pectra EL devs are free to start work on Verkle, while the CL devs work on the CL only fork - MaxEB could potentially use the extra time while peerDAS is being worked on to finalize how consolidations would work and allow us to design more edge cases around it - The removal of MaxEB would also simplify Pectra greatly, allowing it to potentially achieve the 2024/early 2025 timelines - Note: Pawan mentioned that we use [MaxEB features in EIP-6110](https://github.com/ethereum/consensus-specs/pull/3689), which would complicate such a split fork - We could still discuss the merits of a blob throughput increase (EIP-7691) depending on the timeline for the CL only fork. - We've however historically been bad at small forks and this approach only works if we are adamant in not including any other EIPs into the small CL only fork 3. PeerDAS with EOF/Verkle/MaxEB: - We could choose to ship PeerDAS in a separate fork, either with EOF/Verkle/MaxEB. This would depend on what we choose goes into Pectra and would indeed imply one of the features gets pushed back by another fork. - This feels like a safe fork option, but would largely depend on the timeline of Verkle/MaxEB/EOF. - We could potentially end up in a situation where PeerDAS is completed and we are waiting on Verkle/EOF/MaxEB. Changing the order of which EIPs we ship together after we agree to a combination now would lead to a lot of rebasing and we should be clear in whichever choice we make. - We should strongly consider a blob throughput increase (EIP-7691) depending to alleviate some blob demand until peerDAS is shipped. 4. Modify MaxEB without consolidations, no EOF: - MaxEB could be reduced scope with removal of consolidations (for e.g), reducing the testing scope for Pectra - This would potentially reduce the impact of MaxEB but the usefullness of the feature itselfitself might be brought into question - No EOF would also mean the fork would have a reduced test surface and enable a faster fork 5. Minimal fork - maxEB or 6110/7002/7685 as well as all eips that are currently done (2537, 2935) - This fork option has the highest likihood of being shipped fast but also has the least number of EIPs included in it 6. Mega Fork with PeerDAS in a CL only fork after: - Mega Fork including all EIPs we want to ship in a reasonable amount of time (pre-Q1/Q2 2025) and a fast fork after with just peerDAS - Allows more time for peerDAS to ship as well as shipping a lot of features for Pectra - Delays would be hard to calculate in, lot of EIPs would mean a lot of testing effort and forks after Pectra would suffer due to lesser devs getting time to focus on it ## ethPandaOps position We would ideally prefer option 2. The option would address our concerns about cross-EIP edge case testing. There are some members of the team that argue for 1. or 3. on the basis that we have never done small forks historically. The decision between 2. or 1./3. would depend on wether we believe we can ship a small/scoped fork shortly after Pectra. There has been an argument made that we would test the edge cases of all EIPs irrespective of if they are in a single fork or split over two forks. This was directed at our thoughts and concerns section and according to this view it would be simpler to go with option 1. as oposed to 2. As mentioned, the team itself is divided on this topic and we would love to hear other opinions on it.