# Pectra Interop Testing Requirement Tracker ✨ The meta-EIP can be found here: https://eips.ethereum.org/EIPS/eip-7600 This doc is heavily inspired from Mario's testing doc [here](https://notes.ethereum.org/@marioevz/pectra-testing-requirement-tracker). The testing team will mostly focus on single client testing, ethpandaops would focus on network level and interop testing, which this doc aims to make a plan for. We will aim to divide each EIP into a TLDR, overall estimated changeset, Assertoor tests and new tools needed. Quick links to EIP sections: - [EIP-2537](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-2537-Precompile-for-BLS12-381-curve-operations): Precompile for BLS12-381 curve operations - [EIP-2935](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-2935-Save-historical-block-hashes-in-state): Save historical block hashes in state - [EIP-6110](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-6110-Supply-validator-deposits-on-chain): Supply validator deposits on chain - [EIP-7002](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-7002-Execution-layer-triggerable-exits): Execution layer triggerable exits - [EIP-7251](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-7251-Increase-the-MAX_EFFECTIVE_BALANCE) Increase the MAX_EFFECTIVE_BALANCE - [EIP-7549](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-7549-Move-committee-index-outside-Attestation): Move committee index outside Attestation - [EIP-7685](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-7685-General-purpose-execution-layer-requests): General purpose execution layer requests - [EIP-7702](https://notes.ethereum.org/@ethpandaops/pectra-testing-overview-doc#EIP-7702-Set-EOA-account-code-for-one-transaction): Set EOA account code for one transaction ### [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537): Precompile for BLS12-381 curve operations #### TLDR: - Adds functionality to perform BLS ops, including verification - Adds 9 opcodes #### Estimated changeset: - Purely EVM related changes - No change in Beacon or EL APIs - No change to EngineAPI or CLs required #### Comments: - We could use tools such as FuzzyVM(and goevmlab) or similar differential EVM fuzzers to ensure that the evm performs similarly across implimentations - There are error cases listed in the [EIP](https://eips.ethereum.org/EIPS/eip-2537#abi-for-g1-addition), we should definitely craft transactions that trigger these cases - Chances are that the testing team will have static test cases for all the edge cases and uses, we can potentially import them into assertoor and simply assert cross client behaviour #### Devnets/Assertoor: - [ ] Test case to perform a signing, assert output and gas used - [ ] Test case to aggregate bls pubkeys, assert output and gas used - [ ] Test case to verify a bls signature, assert output and gas used - [ ] Test error edge cases mentioned in comments, assert output and gas used #### New tools: - [ ] None #### Other Integrations required: - Assertoor integration with execution-spec-tests ### [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935): Save historical block hashes in state #### TLDR: - Adds a `BLOCKHASH` opcode to read and serve the last 8192 blocks(or `HISTORY_SERVE_WINDOW`) hash from a contract storage #### Estimated changeset: - Purely EVM related changes - No change in Beacon or EL APIs - No change to EngineAPI or CLs required #### Comments: - `HISTORY_SERVE_WINDOW` is 8192 blocks or ~1.2d. We should see what this value is for the `minimal` spec and if we can modify it for faster assertoor tests. This particular test might be easier in assertoor over hive. - We have to make a deployment of the contract, similar to EIP-4788. More info [here](https://eips.ethereum.org/EIPS/eip-2935#deployment), the script needs to fund `0xa4690f0ed0d089faa1e0ad94c8f1b4a2fd4b0734` and then perform the contract deployment. - Where is `HISTORY_SERVE_WINDOW` specified? In the genesis.json files? If so, what is the field called in the various EL spec files? #### Devnets/Assertoor: - [ ] Test case to request a block hash within `HISTORY_SERVE_WINDOW`, assert hash and gas used. Assertoor could use the JSON api to know the right answer ahead of time - [ ] Test case to request a block hash outside of `HISTORY_SERVE_WINDOW`, assert response as 0 and gas used. Assertoor could use the JSON api to know current head and decide which block to request the data for - [ ] Test case to request block hash of fork transition slot, assert response and gas used - [ ] Test case to request block hash of block 1, assert response is the same as genesis block hash and gas - [ ] Test in a shadowfork that has 8192 blocks before fork, assert the expected response and gas used - [ ] Simple wrapper script (or the one from kurtosis) to perform the deployment in devnets #### New tools: - None #### Other Integrations required: - If `HISTORY_SERVE_WINDOW` is configurible in `config.yaml`, we need to support it in the `ethereum-genesis-generator` - We have to reuse the 4788 deployment codebase in kurtosis to deploy the bytecode required for this EIP. The trigger for this module would have to be on the setting of `pectra_fork_epoch`. ### [EIP-6110](https://eips.ethereum.org/EIPS/eip-6110): Supply validator deposits on chain #### TLDR: - NOTE: WILL CHANGE WITH REBASE ON EIP-7685 - Appends validator deposits to the Execution payload struct - Removes the need for deposit voting from the CL #### Estimated changeset: - NOTE: WILL CHANGE WITH REBASE ON EIP-7685 - Execution payload format - Engine API response - BeaconAPI response for the payload related requests - JSON RPC unchanged - No EVM changes - ELs can for e.g change defaults on till which block they store receipts that they required for deposit processing - Deeper list of changeset can be found [here](https://ethereum2077.substack.com/i/142552521/define-a-new-deposit-structure-and-modify-the-engine-api-to-include-deposits-in-execution-payloads) #### Comments: - Since this touches the execution payload, we're gonna have to make changes in quite a few tools to be able to parse it - We'd need to evaluate the dos vector of spamming with a lot of deposits and increasing the verification time, this is of course an expensive dos vector but likely to occur during normal chain operations - `Eth1Data` poll mechanism is removed in an un-coordinated fashion, this means we should test the edge cases. Transition ends when `state.eth1_deposit_index == state.deposit_receipts_start_index`. More info [here](https://ethereum2077.substack.com/i/142552521/deprecating-ethdata-poll-by-adding-depositreceiptsstartindex-and-ethdepositindex-limit) - Validator/bn won't re-validate merkle proof for deposit inclusion. So a malicious EL can potentially cause some damage when combined with a malicious proposer. - EngineAPI includes the deposit contract address as a config now, check where this can be configured - The `MAX_DEPOSIT_RECEIPTS_PER_PAYLOAD` is a CL side limitation, there's no limit on the EL side. So using a contract like the [kiln deposit batcher](https://docs.kiln.fi/v1/tools/eth-batch-deposit-contract) would allow us to perform more than 8192 deposits in a block while being under the gas limit. This should trigger an edge case. #### Devnets/Assertoor: - [ ] Test with deposit, assert deposit showing up on the execution payload - [ ] Test with more deposits than the `MAX_DEPOSIT_RECEIPTS_PER_PAYLOAD`, assert max showing up on execution payload - [ ] Test deposits with network wide reorgs, assert interop across all nodes - [ ] Use the [kiln deposit batcher](https://docs.kiln.fi/v1/tools/eth-batch-deposit-contract) to perform more than `MAX_DEPOSIT_RECEIPTS_PER_PAYLOAD` deposits, assert `MAX_DEPOSIT_RECEIPTS_PER_PAYLOAD` make it on chain - [ ] Test deposit with reorg on subset of nodes, assert same state across nodes - [ ] Test invalid deposits, assert rejection across nodes - [ ] Test invalid deposit being accepted by one malicious node, allow node to propose block, assert rejection by honest nodes - [ ] Test with `Eth1Data` poll mechanism being active on most clients and with deposits occuring via the EIP-6110 method, assert that the EIP-6110 deposits are included - [ ] Test `Eth1Data` poll deprecation, assert voting ending - [ ] Test with `Eth1Data` poll being deprecated with the last voting condition never finishing, i.e transition never ending, assert network behaviour - [ ] Test a network fork with same pubkey but having differing indexes, assert ordering post reorg (We would need to induce an artifical fork with attacknet mostly and perform deposits on one half of the network to trigger differing validator indexes) - [ ] Engine API now includes the deposit contract, ensure the right contract is requested and check behaviour if the wrong one is requested #### New tools: - Some lightweight way to parse the voting period data, probably a zsh script wrapper around the beacon API #### Other Integrations required: - Malicious proposer that proposes invalid deposit, this should likely be a malicious geth node - Update zrnt to accept new exec payload format - Update geth http client lib (included in geth package) to handle new exec payload format - Update Dora to include parsing of new exec payload - Notify beaconchain team of changes for their explorer - Update Xatu with new column handling deposit data from exec payload (if needed) ### [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002): Execution layer triggerable exits #### TLDR: - NOTE: WILL CHANGE WITH REBASE ON EIP-7685 - Allows validators to trigger withdrawals and exits from their `0x01` withdrawal credentials - The new exit messages are added to the exec payload and processed by the cl #### Estimated changeset: - NOTE: WILL CHANGE WITH REBASE ON EIP-7685 - Execution payload format - Engine API response - BeaconAPI response for the payload related requests - JSON RPC unchanged - No EVM changes #### Comments: - We have to make a deployment of the contract, similar to EIP-4788. More info [here](https://eips.ethereum.org/EIPS/eip-7002#deployment), the script needs to fund `0x4951E1ff64Fe2C88effd8a98be863d6Db24aDDdf` and then perform the contract deployment. - There's a `TARGET_EXITS_PER_BLOCK` and `MAX_TARGET_EXITS`, so there's a EIP-1559 style mechanism at play that needs testing - 1. CL exits, 2. EL exits, 3. EL parital withdrawals is the order of preference, this should give us some edge cases to test - Look into edge cases along with EIP-7251 (MaxEB) once finalized #### Devnets/Assertoor: - [x] Submit a exit request from an address with 0x00 credentials, assert no exit - [x] Submit a exit request from an address with 0x01 credentials, assert exit - [x] Submit a exit request from an address with 0x02 credentials, assert exit - [x] Submit a partial 1 ETH withdrawal request from an address with 0x01 credentials, assert no withdrawal - [x] Submit a partial 1 ETH withdrawal request from an address with 0x02 credentials and balance >= 33 ETH, assert withdrawal - [x] Submit a partial 2 ETH withdrawal request from an address with 0x02 credentials and balance < 34 ETH, > 33 ETH, assert < 2 ETH, > 1 ETH withdrawal - [ ] Submit more exits than `MAX_WITHDRAWAL_REQUESTS_PER_BLOCK` and assert that `MAX_WITHDRAWAL_REQUESTS_PER_BLOCK` gets processed per block - [ ] Submit exit request with invalid `source_address` and/or invalid `validator_pubkey`, assert failure - [ ] Submit subsequent exits to fill up blocks with exits, assert the exit fee increasing - [ ] Submit exit in CL, submit another exit on the EL side, assert behaviour - [ ] Submit exit in EL side, submit partial withdrawal immediate after, assert partial withdrawal yielding nothing - [ ] Simple wrapper script (or the one from kurtosis) to perform the deployment in devnets - [x] Submit an exit request from an address with `_0x02_` credentials, assert exit - [ ] Submit partial withdrawal and while it is pending, submit EL exit, assert no exit initiated - [ ] Submit partial withdrawal and while it is pending, submit CL exit, assert invalid block - [ ] Submit partial withdrawal for `_0x01_` validator, assert no withdrawal happened - [ ] Submit partial withdrawal for a balance that is bigger than the churn limit of one epoch, assert withdrawal - [ ] Submit partial withdrawal for a validator with the balance < MIN_ACTIVATION_BALANCE, assert no withdrawal happens - [ ] Submit partial withdrawal, submit exit (EL or CL) immediate after, assert partial withdrawal yielding nothing #### New tools: #### Other Integrations required: - We have to reuse the 4788 deployment codebase in kurtosis to deploy the bytecode required for this EIP. The trigger for this module would have to be on the setting of `pectra_fork_epoch`. - Update zrnt to accept new exec payload format - Update geth http client lib (included in geth package) to handle new exec payload format - Update Dora to include parsing of new exec payload - Notify beaconchain team of changes for their explorer ### [EIP-7251](https://eips.ethereum.org/EIPS/eip-7251): Increase the MAX_EFFECTIVE_BALANCE #### TLDR: - Allows for a higher max effective balance than 32 eth - Max balance a validator can have is 2048 ETH - Validator needs to already be active on chain, then a consolidation transaction can be sent to the system contract - ~~New validator can set a custom ceiling, so the partial withdrawals will be processed until that value~~ no custom ceiling anymore, 0x02 validators always consolidate up to 2048 ETH #### Estimated changeset: - No EVM changes - No change in Beacon or EL APIs - Engine API communicates the requests to the CL via EIP-7685 #### Comments: - We have to make a deployment of the contract, similar to EIP-4788. More info [here](https://eips.ethereum.org/EIPS/eip-7251#deployment), the script needs to fund `0xd6e25886D7B986C394156C31a48e84Ee0BA71f72` and then perform the contract deployment. #### Devnets/Assertoor: - [x] Assertoor test to consolidate 2 validators into 1, have max effective balance as 64, assert success - [x] Assertoor test to consolidate 64 validators into 1, have max effective balance as 2048, assert success - [ ] Assertoor test to consolidate 2 validators into 1, 1 validator has 32 eth and 1 validator already has 2048 eth, assert failure - [ ] Assertoor test to consolidate 2 validators into 1, validator 1 has 32 eth and validator 2 has 2017 eth, assert failure - [ ] Assertoor test to consolidate 2 validators into 1, validator 1 has 32 eth and validator 2 has 2015 eth - [ ] Assertoor test to consolidate 2 validators into 1, but validators are not active yet and are currently in the deposit queue(`pending_initialized`), assert failure - [ ] Assertoor test to consolidate 2 validators into 1: - validator 1 state: `pending_initialized`, `pending_queued`,`active_ongoing`, `active_exiting`, `active_slashed`,`exited_unslashed`,`exited_slashed`, `withdrawal_possible`, `withdrawal_done` - validator 2 state: `pending_initialized`, `pending_queued`,`active_ongoing`, `active_exiting`, `active_slashed`,`exited_unslashed`,`exited_slashed`, `withdrawal_possible`, `withdrawal_done` - We need a matrix of 9x9 validator states, so 81 tests in all with different assertoor outcomes for all (TODO: check what the behaviours would be) - [ ] Assert changes to initial slashing penalty (details under discussion) - [x] validator 1/2 states active_ongoing, trigger consolidation, then slash validator 1 - [ ] validator 1/2 states active_ongoing, trigger consolidation, then slash validator 2 - [ ] validator 1/2 states active_ongoing, trigger consolidation, then slash validator 1 and 2 - [ ] Assertoor test to send a consolidation request for 2 validators, while at the same time submitting a exit request for 1 validator, assert failure of one of the two processes - [ ] Send 1 ETH to the deposit contract with the same withdrawals credentials as an existing validator: * ensure invalid signature = no 0x02 change * ensure valid signature = 0x02 change - [ ] Assertoor test to check that the withdawal queue is rate limited by weight instead of number of validators, assert success - [ ] Assertoor/Devnet to perform a withdrawal of 1 validator that exceeds the churn limit at the time (TODO: Does this then take up churn limit of multiple epochs) - [ ] Assertoor/Devnet to perform a deposit of 1(or more) validator that exceeds the churn limit at the time (TODO: Does this then take up churn limit of multiple epochs) - [ ] Assertoor test to withdraw ~1000 validators and ensure that the churn rate is applied as expected - [ ] Assertoor test to perform a consolidation when a validator is in a sync committee #### Other Integrations required: - Dora needs to be able to display custom balances - Assertoor task that takes in an input of validator pubkey/index and spits out a consolidation transaction would be very useful ### [EIP-7549](https://eips.ethereum.org/EIPS/eip-7549): Move committee index outside Attestation #### TLDR: - Move the committee `index` field outside of the signed Attestation message to allow aggregation of equal consensus votes #### Estimated changeset: - Execution payload unchanged - Engine API unchanged - BeaconAPI unchanged - JSON RPC unchanged - No EVM changes - Change in CL `index` from `AttestationData` to `Attestation` #### Comments: #### Devnets/Assertoor: - [ ] Assertoor querties the `attestation` and validates that the index has been moved out - [ ] Run Xatu on devnet and observe drop in p2p traffic #### New tools: #### Other Integrations required: - Xatu needs to modify its parsing to understand the `index` field being moved - Dora needs to modify attestation aggration and participation calculation ### [EIP-7685](https://eips.ethereum.org/EIPS/eip-7685): General purpose execution layer requests #### TLDR: - Adds a field in block body and header to include requests as well as request hash - Sort of a general EL->CL request passer #### Estimated changeset: - Execution payload changes to include new body and header? - Engine API changes to include new body and header? - BeaconAPI changes to include new body and header in execution payload? - JSON RPC changes to include new body and header - No EVM changes #### Comments: - Generic request passer, yet to understand what sort of requests we can craft #### Devnets/Assertoor: - [ ] Cases mostly handled by 6110 and 7002 tests #### New tools: #### Other Integrations required: - Dora to understand the requests and API changes / display EL triggered requests ### [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702): Set EOA account code for one transaction #### TLDR: #### Estimated changeset: #### Comments: #### Devnets/Assertoor: #### New tools: #### Other Integrations required: # NOTE changed, replace with 7702 ### [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074): AUTH and AUTHCALL opcodes #### TLDR: - Delegates control of a EOA to a smart contract - Two new opcodes called `AUTH` and `AUTHCALL` #### Estimated changeset: #### Estimated changeset: - Purely EVM related changes - No change in Beacon or EL APIs - No change to EngineAPI or CLs required #### Comments: - We need a smart contract wallet that someone deploys to start any sort of testing. Talk to community or reth's alphanet people to see how they solve the issue or if there's a reference implimentation #### Devnets/Assertoor: - [ ] Test with EOA delegating to a basic smart contract and perform a test transaction, assert tx and gas used - [ ] Test with EOA delegating to a basic smart contract and perform a test contract deployment, assert tx and gas used - [ ] Test with EOA delegating to a basic smart contract and perform a call to all of the new EIPs opcodes, assert tx response and gas used - [ ] Test with an EOA that has no funds and uses an external sponsor to pay for tx, assert network interaction and gas used - [ ] Test with EOA delegating control to a non-existent smart contract, assert failure and gas - [ ] Test replay protection with nonce, assert a failed tx and gas - [ ] Test sending multiple `AUTH` and sandwiching some `AUTHCALLS`, assert that the correct contract has the correct rights - [ ] Test `AUTH` with reorgs, assert the correct behaviour - [ ] Test tx invalidation in the mempool due to 3074 interactions, assert tx was indeed invalidated #### New tools: - Probably will need some wallet integrations to properly test this - Easy way to check or vet that an EOA has set an AUTH. Probably needs integration with a indexer though? #### Other Integrations required: - 4788-Deployer code would need to deploy some smart contract we can use to test delegation ### [EIP-7594](https://eips.ethereum.org/EIPS/eip-7594): PeerDAS - Peer Data Availability Sampling #### TLDR: * Supernodes store all blobs * Standard nodes store CUSTODY_REQUIREMENT(4) amount of subnets/columns. #### Estimated changeset: * Change in CL #### Comments: - As long as the nodeID (in the ENR) is the same, the ordering of columns will be the same - As long as the csc (in the ENR) is the same, the number of columns custodied will be the same - So as long as {nodeID, csc} is the same, the node will custody exactly the same columns. - And so as long as the ENR is the same, the node will custody exactly the same columns. #### Devnets/Assertoor: - [ ] Test for 1 supernode for each CL. - Test for 1 supernode and 1 standard node for each CL. - [ ] Test for 1 supernode for each CL with 1 standard node for each non same CL. - Test for DATA_COLUMN_SIDECAR_SUBNET_COUNT(128)//CUSTODY_REQUIREMENT(4) number of standard nodes (32), each with engineered ENR so that they conver one unique subnet. Then make an assertoor test that will query every data column in every slot to ensure availability is 100% throughout finality. - this can't be done with assertoor 1. Determine (it's a one shot computation, has only to be done once) 32 private keys leading after derivation to a 128 sets of subnets, effectively covering all the subnets. - Ideally we should try edge case, so either do 128 nodes with 1 custody or 32 nodes with 4 custody each node - edge case might be disliked by some clients but as long as [custody requirements](https://github.com/ethereum/consensus-specs/blob/dev/configs/mainnet.yaml#L167) is a config we should be able to customize this to 1. - We should brute force 128 subnets enr private keys still, just so we can test lower custody values too. 2. Run clients with those private keys (In Prysm it is possible to impose a givent Private key. Don't know for other clients) 4. Run DataColumnSidecarsByRoot requests for nodes. (You know which node custodies which columns) 5. Check that the nodes respond correctly with non altered columns (KZG proofs will ensure that) If 4. fails because no response or bad response, ping the client team 4. can be done with a dedicated too. #### New tools: #### Other Integrations required: