Feature: Include unique id with withdrawal verification -- urgently needed for projects that process many withdrawals

[youfoundron]

User story
As an EigenPod contract owner I want the events PartialWithdrawalRedeemed & FullWithdrawalRedeemed to include a uint256 withdrawalIndex (this is a unique id that marks the position of a withdrawal within beacon chain history), so that I may parse through event logs and know which withdrawals have already been redeemed for a pod.

The WithdrawalIndex has been in-spec since Capella

I propose modifying the event interfaces on IEigenPod.sol like so:

    /// @notice Emitted when an ETH validator is prove to have withdrawn from the beacon chain
    event FullWithdrawalRedeemed(
        uint40 validatorIndex,
        uint64 withdrawalTimestamp,
        address indexed recipient,
        uint64 withdrawalAmountGwei,
        uint256 indexed withdrawalIndex // new log
    );

    /// @notice Emitted when a partial withdrawal claim is successfully redeemed
    event PartialWithdrawalRedeemed(
        uint40 validatorIndex,
        uint64 withdrawalTimestamp,
        address indexed recipient,
        uint64 partialWithdrawalAmountGwei,
        uint256 indexed withdrawalIndex // new log
    );

Actions

• Modify IEigenPod.sol event interfaces PartialWithdrawalRedeemed & FullWithdrawalRedeemed to include withdrawalIndex
• Update BeaconChainProofs.sol with the capability to parse the withdrawalIndex value from submitted withdrawal proofs
• Update EigenPod.sol to pass the withdrawalIndex when emitting the relevant events

[youfoundron]

Without this, withdrawal tracking / redemption is a brittle process for everyone.

FWIW, It seems this information should be accessible from within the submitted proof.

Please see:

eigenlayer-contracts/src/contracts/libraries/BeaconChainProofs.sol

Lines 92 to 94 in e12b03f

	uint64 withdrawalIndex;
	bytes32 blockRoot;
	bytes32 slotRoot;

Granted, there is a bit of a naming collision here as what EL calls the withdrawalIndex is actually referring to a withdrawal's index within a given slot (0 - 15).

However, if the event emitted this value along with the slotRoot it would be enough information to uniquely identify a withdrawal and solve the broader problem of not being able to uniquely identify withdrawal redemptions from on-chain data.

Here is what I mean:

    event XWithdrawalRedeemed(
        uint40 validatorIndex,
        uint64 withdrawalTimestamp,
        address indexed recipient,
        uint64 withdrawalAmountGwei,
        bytes32 indexed slotRoot,  // withdrawalProof.slotRoot
        uint64 indexed withdrawalSlotIndex  // withdrawalProof.withdrawalIndex
    );

While this approach is not as clean as the one offered in my original post, it would technically solve the problem without requiring any changes to proof generation logic.

[gpsanant]

Hey there. unfortunately since we're so close to our mainnet launch, we're not comfortable making this change.

Could you explain the impact of the change? From the timestamp (which gives you the slot) and the validator index, you should be able to get the withdrawal index?