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

[eladiosch]

I checked this and it's only used as a calldata param, never stored, so I'm going to remove deprecated stuff

[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

❌ Patch coverage is 70.82067% with 96 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
mainnet-contracts/src/PufferProtocolLogic.sol	75.13%	38 Missing and 8 partials ⚠️
mainnet-contracts/src/PufferProtocol.sol	72.15%	19 Missing and 3 partials ⚠️
mainnet-contracts/src/GuardianModule.sol	0.00%	14 Missing ⚠️
mainnet-contracts/src/PufferModule.sol	53.84%	6 Missing ⚠️
mainnet-contracts/src/PufferModuleManager.sol	66.66%	4 Missing ⚠️
mainnet-contracts/src/LibGuardianMessages.sol	50.00%	2 Missing ⚠️
mainnet-contracts/src/PufferProtocolBase.sol	84.61%	0 Missing and 2 partials ⚠️

Files with missing lines	Coverage Δ
mainnet-contracts/src/ProtocolSignatureNonces.sol	100.00% <100.00%> (ø)
mainnet-contracts/src/PufferOracleV2.sol	67.64% <100.00%> (-14.71%)	⬇️
mainnet-contracts/src/LibGuardianMessages.sol	33.33% <50.00%> (-46.67%)	⬇️
mainnet-contracts/src/PufferProtocolBase.sol	84.61% <84.61%> (ø)
mainnet-contracts/src/PufferModuleManager.sol	87.34% <66.66%> (-3.71%)	⬇️
mainnet-contracts/src/PufferModule.sol	83.82% <53.84%> (-16.18%)	⬇️
mainnet-contracts/src/GuardianModule.sol	62.67% <0.00%> (-22.71%)	⬇️
mainnet-contracts/src/PufferProtocol.sol	88.02% <72.15%> (-6.65%)	⬇️
mainnet-contracts/src/PufferProtocolLogic.sol	75.13% <75.13%> (ø)

... and 6 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.