feat: pectra compatibility

[ypatil12]

Updates checkpoint proof system to be Pectra compatible. The breaking change to EigenPods is the BeaconState container increasing to have 37 fields, which results in the tree height to be > 5.

Overview

We need to solve for the following cases:

• Prevent deneb proofs from being submitted to pectra blocks
• Ensure that the PECTRA_FORK_TIMESTAMP is the first timestamp at or after the pectra hard fork for which there is a non missed slot. Checkpoint proofs store the proof timestamp. If there are missed slots at the hard fork timestamp, it's that the beaconTimestamp is post pectra but the block header is deneb.

To do this, here is the upgrade process:

1. Pause checkpoint starting & credential proofs
2. Upgrade after fork is hit
3. Run script to detect the first timestamp at or after the pectra hard fork for which there is a non missed slot
4. Set pectra fork timestamp to the first timestamp at which there is a pectra block header
5. Unpause

EigenPod

• Updated balance container and validator container proofs to pass in a proof timestamp & pectra fork timestamp to check against which tree height to use for the beacon state
• Modify storing variables in memory to handle stack too deep errors
• Note that since the 4788 oracle returns the PARENT beacon block root, our check against the pectra fork timestamp returns the previous tree length for proofs that are <= pectraForkTimestamp

Deprecation Plan

• Post pectra, we can upgrade the EigenPod to deprecate the fork timestamp case handling once all in progress pre-Pectra checkpoints have been completed

TODOs

• Unit Tests
• Integration Tests simulating upgrade
• Mekong Deployment
• Update Integration Test User to use validators >32 ETH

[eigenmikem]

AFAIK the fork timestamp has never been altered once broadcast, at least not in the last few years, so I think hardcoding it is fine

[wadealexc]

Hmm, I wonder about the usage of getParentBlockRoot above.

Can beaconTimestamp belong to the block after the fork, but the proof itself is over the parent block (aka pre-fork)?

[wadealexc]

For the record I think I'm correct here. 2 scenarios:

1. I try to verify withdrawal credentials the block after the hard fork. getParentBlockRoot grabs a block from before the hard fork; that's what my proof needs to be against.
2. I start a checkpoint just after the hard fork. The checkpoint block root used for proofs is from a block just before the hard fork.

Naive solution: have the fork selector logic in the proofs library check proofTimestamp - 12. However, this runs into potential issues with skipped slots -- I might have a proof timestamp 2 blocks after the hard fork, but there was a skipped slot right at the fork, so the proof block is from before the fork.

I think, unfortunately, we need to pause proofs just before the fork, and unpause just after the fork (once we see the first valid block). Although I'm not sure this entirely fixes the issue... will think more.

[wadealexc]

Maybe we need to pause + upgrade just after the fork + unpause? ugh.

[ypatil12]

Synced offline, here is what we need to do:

• Prevent deneb proofs from being submitted to pectra blocks
• Ensure that the PECTRA_FORK_TIMESTAMP is the first timestamp at or after the pectra hard fork for which there is a non-missed slot. Checkpoint proofs store the proof timestamp. If there are missed slots at the hard fork timestamp, it's possible, like Alex mentions above, that the beaconTimestamp is post pectra but the block header is deneb.

To do this, here is the process:

1. Pause checkpoint starting & credential proofs
2. Upgrade after fork is hit
3. Set pectra fork timestamp to the first timestamp at which there is a pectra block header
4. Unpause

[wadealexc]

[wadealexc]

Using the image above, we want to determine what proof type to use, given the proof timestamp tp. Because tp is used to look up a parent block in the EIP-4788 oracle, its proof type corresponds to the last non-skipped block. So, if:

• tp > t1, use pectra logic
• tp <= t1, use dencun logic

Given our beacon state tree height getter: https://github.com/layr-labs/eigenlayer-contracts/blob/b4852c74cdbe43fea2f7330ea0dc752fcf10b6e9/src/contracts/libraries/BeaconChainProofs.sol#L327-L334

... pectraForkTimestamp should be set to the first valid, non-skipped block after the Pectra hard fork.

[wadealexc]

Is this PR targeting testnet?

We're going to need a different PR for mainnet, since that's landing before slashing, right? (This EigenPod file is compatible with testnet slashing, but not mainnet)

[ypatil12]

Is this PR targeting testnet?

Yup, targeting testnet. There will be a separate mainnet PR. cc @wadealexc

Updated Impl

[wadealexc]

Do we need this added to the EigenPod interface?

It already exists on the EPM - why duplicate?

[wadealexc]

Just making some notes:

Before we set pectraForkTimestamp in the EPM, it returns 0. This will cause all proofs to be interpreted as pectra proofs. However, we expect contracts to be paused if this value is unset, so that's fine 👍

Additionally, if the contracts are unpaused but the value is still unset, this logic means all proofs are interpreted as pectra proofs, even if we're working with a dencun block. This is good fallback behavior, as the worst case means some proofs will revert until we set the timestamp. 👍

It's the reverse behavior we wanted to avoid - where dencun proof sizes are allowed for pectra blocks. That shouldn't be possible here 👍