feat: pectra compatibility #1053

ypatil12 · 2025-01-28T17:14:45Z

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

To do this, here is the upgrade process:

Pause checkpoint starting & credential proofs
Upgrade after fork is hit
Run script to detect the first timestamp at or after the pectra hard fork for which there is a non missed slot
Set pectra fork timestamp to the first timestamp at which there is a pectra block header
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 · 2025-02-05T15:57:42Z

src/contracts/pods/EigenPod.sol

@@ -254,6 +255,7 @@ contract EigenPod is Initializable, ReentrancyGuardUpgradeable, EigenPodPausingC
        for (uint256 i = 0; i < validatorIndices.length; i++) {
            // forgefmt: disable-next-item
            totalAmountToBeRestakedWei += _verifyWithdrawalCredentials(
+                beaconTimestamp,


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)?

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

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.

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.

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

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:

Pause checkpoint starting & credential proofs

Upgrade after fork is hit

Set pectra fork timestamp to the first timestamp at which there is a pectra block header

Unpause

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 · 2025-02-05T17:35:13Z

Is this PR targeting testnet?

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

src/contracts/libraries/BeaconChainProofs.sol

Updated Impl

src/contracts/interfaces/IEigenPod.sol

src/contracts/interfaces/IEigenPodManager.sol

8sunyuan · 2025-02-21T19:29:58Z

src/contracts/pods/EigenPod.sol

        bytes32 beaconStateRoot,
        uint40 validatorIndex,
        bytes calldata validatorFieldsProof,
        bytes32[] calldata validatorFields
    ) internal returns (uint256) {
-        bytes32 pubkeyHash = validatorFields.getPubkeyHash();
-        ValidatorInfo memory validatorInfo = _validatorPubkeyHashToInfo[pubkeyHash];
+        ValidatorInfo memory validatorInfo = _validatorPubkeyHashToInfo[validatorFields.getPubkeyHash()];


Assuming stack too deep here

8sunyuan · 2025-02-21T19:31:27Z

src/contracts/pods/EigenPod.sol

@@ -378,6 +383,7 @@ contract EigenPod is Initializable, ReentrancyGuardUpgradeable, EigenPodPausingC
    }

    /// @notice Called by EigenPodManager when the owner wants to create another ETH validator.
+    /// @dev This function only supports staking to a 0x01 validator. For compounding validators, please interact directly with the deposit contract.


Can be backlog to add stake function with compounding validators when we implement eip7002

wadealexc · 2025-02-21T20:07:49Z

src/test/integration/UpgradeTest.t.sol

@@ -35,4 +37,22 @@ abstract contract UpgradeTest is IntegrationCheckUtils {
        isUpgraded = true;
        emit log("_upgradeEigenLayerContracts: slashing upgrade complete");
    }
+
+    uint64 constant PECTRA_FORK_TIMESTAMP = 1739352768;


Where are you getting this value? Is this the expected timestamp of the holesky fork?

Wouldn't we need to wait to determine this until after the fork? We need the first non-skipped slot, which may not be this specific value.

Resolved in slack -- this is basically a filler value because we can't know this beforehand.

Actually - since this is a timestamp from a week ago, this is probably messing with tests?

We should maybe just have fork timestamp be current timestamp + 12 or something - that way we know we're moving forward in time if we warp to it.

wadealexc · 2025-02-21T20:12:15Z

src/contracts/libraries/BeaconChainProofs.sol

+
+    /// @dev We check if the proofTimestamp is <= pectraForkTimestamp because a `proofTimestamp` at the `pectraForkTimestamp`
+    ///      is considered to be Pre-Pectra given the EIP-4788 oracle returns the parent block.
+    function getBeaconStateTreeHeight(


Let's consider moving this logic into EigenPod, since it's specific to the EIP-4788 oracle (and the EPM getter), which this library doesn't handle.

We can pass the proofs library an enum (DENEB|ELECTRA), instead.

wadealexc · 2025-02-21T20:12:46Z

src/contracts/pods/EigenPod.sol

+
+    /// @notice Returns the timestamp of the Pectra fork, read from the `EigenPodManager` contract
+    /// @dev Specifically, this returns the timestamp of the first non-missed slot at or after the Pectra hard fork
+    function _getPectraForkTimestamp() internal view returns (uint64) {


Maybe add a require(result != 0) here?

We should never be in a state where we can call this and have it return zero, so this is a sanity check that when we unpause, we have set a value :)

src/contracts/pods/EigenPodManagerStorage.sol

src/test/integration/IntegrationBase.t.sol

src/test/unit/EigenPodUnit.t.sol

src/test/integration/mocks/BeaconChainMock_Pectra.t.sol

src/test/integration/tests/upgrade/Prooftra.t.sol

wadealexc · 2025-02-21T21:15:56Z

src/test/integration/tests/upgrade/Prooftra.t.sol

+        // 3. Upgrade EigenPodManager & EigenPod
+        _upgradeEigenLayerContracts();


This already calls _handlePectraFork, so you're duplicating actions here to some extent. Can we pick whether we're adding special fork logic in UpgradeTest, or in this file?

wadealexc · 2025-02-21T21:30:39Z

src/test/integration/tests/upgrade/Prooftra.t.sol

+        // 2. Randomly warp to just after the fork timestamp
+        // If we do not warp, proofs will be against deneb state
+        if (_randBool()) {
+            // If we warp, proofs will be against electra state
+            cheats.warp(block.timestamp + 1); 
+        }


i'm pretty sure this is testing against electra regardless of whether you warp or not

wadealexc · 2025-02-21T21:31:15Z

src/test/integration/IntegrationDeployer.t.sol

@@ -562,7 +562,7 @@ abstract contract IntegrationDeployer is ExistingDeploymentParser {

    function _genRandUser(string memory name, uint userType) internal returns (User user) {
        // Create User contract based on userType:
-        if (forkType == LOCAL) {
+        if (forkType == LOCAL || (forkType == MAINNET && isUpgraded)) {


Seems this has some cherry picked stuff from another branch?

Yup, will be resolved once I merge this into feat/prooftra and rebase that off of dev

ypatil12 mentioned this pull request Jan 28, 2025

feat: pectra compatability #893

Closed

3 tasks

ypatil12 force-pushed the slashing-magnitudes branch from 7a6f8a6 to fbe5ee2 Compare January 28, 2025 18:23

ypatil12 changed the base branch from slashing-magnitudes to dev January 28, 2025 21:48

ypatil12 force-pushed the yash/pectra-compatibility branch 4 times, most recently from 8b3076f to 8679ebb Compare January 28, 2025 21:55

ypatil12 changed the base branch from dev to feat/prooftra January 29, 2025 22:11

ypatil12 changed the base branch from feat/prooftra to dev January 29, 2025 22:31

ypatil12 force-pushed the yash/pectra-compatibility branch from 8679ebb to 392022e Compare January 30, 2025 01:14

ypatil12 changed the base branch from dev to feat/prooftra January 30, 2025 01:15

ypatil12 force-pushed the yash/pectra-compatibility branch 4 times, most recently from d71e908 to 2e9ab01 Compare January 30, 2025 02:12

ypatil12 marked this pull request as ready for review January 30, 2025 20:34

ypatil12 requested review from 8sunyuan, wadealexc and eigenmikem January 30, 2025 20:36

eigenmikem previously approved these changes Feb 4, 2025

View reviewed changes

ypatil12 force-pushed the feat/prooftra branch from 8beb418 to d63fded Compare February 4, 2025 22:42

ypatil12 force-pushed the yash/pectra-compatibility branch from d849720 to f5dbfb8 Compare February 4, 2025 23:16

wadealexc reviewed Feb 5, 2025

View reviewed changes

wadealexc reviewed Feb 6, 2025

View reviewed changes

src/contracts/libraries/BeaconChainProofs.sol Outdated Show resolved Hide resolved

ypatil12 mentioned this pull request Feb 7, 2025

feat: prooftra upgrade script #1067

Open

wadealexc reviewed Feb 7, 2025

View reviewed changes

src/contracts/interfaces/IEigenPod.sol Outdated Show resolved Hide resolved

wadealexc reviewed Feb 7, 2025

View reviewed changes

src/contracts/interfaces/IEigenPodManager.sol Show resolved Hide resolved

ypatil12 added 9 commits February 16, 2025 13:23

chore: cleanup interface

8d09664

test: push update, still debugging

473d599

test: passing tests

3b38f9e

test: fix upgrade tests

2038051

chore: update BC mock to use max EB

fb20a10

fix: tests

2b8e024

fix: pectra beacon max eb

d21de56

chore: update all tests to create validators up to maxEB

a5db453

fix: out of gas error

7c9e05a

8sunyuan reviewed Feb 21, 2025

View reviewed changes