Pectra upgrade

[eladiosch]

This Pull Request was made for mainly 2 different things:

• Create a new flow to trigger validators exit from the Execution Layer: This is a new feature from EIP-7002 available due to the Pectra upgrade. Currently it's not possible to do this on production since we're waiting for Eigenlayer to deploy it
• Remove enclave related flows as we want to remove REEF. This means all validators will have a 2 ETH bond. This implies some modifications in the PufferProtocol contract. The GuardianModule code won't be modified (to avoid re-deploying it). However some comments have been added to indicate the deprecated functions and variables

Currently this is a WIP. There are a couple of things left to do, basically:

• Fix some remaining failing tests of PufferProtocol
• Add some tests for the new flow

[bxmmm1]

We should rethink this one. If we remove it right now, and in the future we decide to add a new field to this struct, it might contain some bad data. This shouldn't be an issue, but it is still possible. I'd rather have it deprecated_raveEvidence or something like that just to eliminate that chance, even though it is minimal.

[eladiosch]

Done

[bxmmm1]

We can remove these two, they are related to enclave

[eladiosch]

Used deprecated_* as in prev comment

[bxmmm1]

99% sure that this was only used by the enclave, We can remove this function

[eladiosch]

Removed

[bxmmm1]

We can remove

        // Every guardian needs to receive a share
        if (data.blsEncryptedPrivKeyShares.length != GUARDIAN_MODULE.getGuardians().length) {
            revert InvalidBLSPrivateKeyShares();
        }

        // blsPubKeySet is for a subset of guardians and because of that we use .getThreshold()
        if (data.blsPubKeySet.length != (GUARDIAN_MODULE.getThreshold() * _BLS_PUB_KEY_LENGTH)) {
            revert InvalidBLSPublicKeySet();
        }

[bxmmm1]

It would be nice if we introduced 2 ways of doing execution layer withdrawals/exits

Way 1:
PufferProtocol (validate that the node operator that registered a validator is doing the request) -> PMM -> Module -> Eigenpod

In this flow, if the validator is 0x02, the same function could be used to withdraw the rewards from beacon chain
protocol.

something like:

    PufferProtocool.requestWithdrawal(bytes[] pubkeys, uint256[] amounts) external {
        ProtocolStorage storage $ = _getPufferProtocolStorage();

        address node = $.nodeOperatorInfo[msg.sender].node;
 
        // validate pubkeys belong to that node
       // allow withdrawals from the same module? or figure out something

        PUFFER_MODULE_MANAGER.requestWithdrawal(pufferModule, pubkeys, amounts);
    }
    ```
    
in PMM `requestWithdrawal` can be called by puffer paymaster | pufferProtocol
    
If we need to exit validators, we call it from the paymaster, otherwise the users request rewards withdrawals/exit their validator from on-chain

Potential attack vector:
We provision 64 ETH Validator (2 VT per day), user requests a withdrawal of 32 ETH. This is not their reward, and the ETH should be returned to the Vault, a potential DOS attack is possible, if we give the ability to users to request withdrawals with any amount

wyt? should we sync on this more?
    

[eladiosch]

We can remove

        // Every guardian needs to receive a share
        if (data.blsEncryptedPrivKeyShares.length != GUARDIAN_MODULE.getGuardians().length) {
            revert InvalidBLSPrivateKeyShares();
        }

        // blsPubKeySet is for a subset of guardians and because of that we use .getThreshold()
        if (data.blsPubKeySet.length != (GUARDIAN_MODULE.getThreshold() * _BLS_PUB_KEY_LENGTH)) {
            revert InvalidBLSPublicKeySet();
        }

Removed

[eladiosch]

It would be nice if we introduced 2 ways of doing execution layer withdrawals/exits

Way 1: PufferProtocol (validate that the node operator that registered a validator is doing the request) -> PMM -> Module -> Eigenpod

In this flow, if the validator is 0x02, the same function could be used to withdraw the rewards from beacon chain protocol.

something like:

    PufferProtocool.requestWithdrawal(bytes[] pubkeys, uint256[] amounts) external {
        ProtocolStorage storage $ = _getPufferProtocolStorage();

        address node = $.nodeOperatorInfo[msg.sender].node;
 
        // validate pubkeys belong to that node
       // allow withdrawals from the same module? or figure out something

        PUFFER_MODULE_MANAGER.requestWithdrawal(pufferModule, pubkeys, amounts);
    }
    ```
    
in PMM `requestWithdrawal` can be called by puffer paymaster | pufferProtocol
    
If we need to exit validators, we call it from the paymaster, otherwise the users request rewards withdrawals/exit their validator from on-chain

Potential attack vector:
We provision 64 ETH Validator (2 VT per day), user requests a withdrawal of 32 ETH. This is not their reward, and the ETH should be returned to the Vault, a potential DOS attack is possible, if we give the ability to users to request withdrawals with any amount

wyt? should we sync on this more?
    

Since we're not adding support to 0x02 validators in this PR, and when we do we have to change more stuff I'd say to implement those changes in a future PR when we're sure on how will 0x02 validators will affect our architecture.

Also in my implementation, the PMM function can only be called from a new role ROLE_ID_VALIDATOR_EXITOR

We can sync on this if you want

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines	Coverage Δ
mainnet-contracts/src/GuardianModule.sol	74.61% <ø> (-10.77%)	⬇️
mainnet-contracts/src/PufferModule.sol	100.00% <100.00%> (ø)
mainnet-contracts/src/PufferModuleManager.sol	92.00% <100.00%> (+0.95%)	⬆️
mainnet-contracts/src/PufferProtocol.sol	94.73% <100.00%> (+0.07%)	⬆️

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bxmmm1]

This changes the event signature, if we want to have it easy on the off-chain side(subgraph), we can keep the old event signature and always emit false for usingEnclave. IMO, it is not a big deal to change it as well, but it is something we must be aware of.

[bxmmm1]

It would be nice if we introduced 2 ways of doing execution layer withdrawals/exits
Way 1: PufferProtocol (validate that the node operator that registered a validator is doing the request) -> PMM -> Module -> Eigenpod
In this flow, if the validator is 0x02, the same function could be used to withdraw the rewards from beacon chain protocol.
something like:

    PufferProtocool.requestWithdrawal(bytes[] pubkeys, uint256[] amounts) external {
        ProtocolStorage storage $ = _getPufferProtocolStorage();

        address node = $.nodeOperatorInfo[msg.sender].node;
 
        // validate pubkeys belong to that node
       // allow withdrawals from the same module? or figure out something

        PUFFER_MODULE_MANAGER.requestWithdrawal(pufferModule, pubkeys, amounts);
    }
    ```
    
in PMM `requestWithdrawal` can be called by puffer paymaster | pufferProtocol
    
If we need to exit validators, we call it from the paymaster, otherwise the users request rewards withdrawals/exit their validator from on-chain

Potential attack vector:
We provision 64 ETH Validator (2 VT per day), user requests a withdrawal of 32 ETH. This is not their reward, and the ETH should be returned to the Vault, a potential DOS attack is possible, if we give the ability to users to request withdrawals with any amount

wyt? should we sync on this more?
    

Since we're not adding support to 0x02 validators in this PR, and when we do we have to change more stuff I'd say to implement those changes in a future PR when we're sure on how will 0x02 validators will affect our architecture.

Also in my implementation, the PMM function can only be called from a new role ROLE_ID_VALIDATOR_EXITOR

We can sync on this if you want

overall, the PR looks good. Lets sync on this topic tomorrow. Would be nice to bundle a few things in one audit, and have 1 upgrade instead of more.