# EIP-4895 Hive Testing ## Engine API Execution Client Test Suite PR: https://github.com/marioevz/hive/tree/engine-withdrawals-2 ### Fork Activation Tests Test the withdrawals fork on timestamp such that it happens on a specific block height. - Withdrawals Fork On Genesis: Tests the withdrawals fork happening since genesis (e.g. on a testnet). - Withdrawals Fork on Block 1: Tests the withdrawals fork happening directly after genesis. - Withdrawals Fork on Block 2: Tests the withdrawals fork happening directly after genesis. Tests correct `latestValidHash==genesis.Hash` on `engine_newPayloadV2(withdrawals=[])` on block 1. - Withdrawals Fork on Block 3: Tests the withdrawals fork happening directly after genesis. Tests correct `latestValidHash==block1.Hash` on `engine_newPayloadV2(withdrawals=[])` on block 2. ### Withdrawals Payload Tests Test combinations of accounts and amounts contained in the withdrawals payload. - Withdraw to a single account: Make multiple withdrawals to a single account. - Withdraw to two accounts: Make multiple withdrawals to two different accounts, repeated in round-robin. There might be a difference in implementation when an account appears multiple times in the withdrawals list but the list is not in ordered sequence. - Withdraw many accounts: Make multiple withdrawals to 1024 different accounts. Execute many blocks this way. This scenario is an extreme situation that will not be seen on mainnet. - Withdraw zero amount: Make multiple withdrawals where the amount withdrawn is 0. - Empty Withdrawals: Produce withdrawals block with zero withdrawals. ### Sync Tests Test a client syncing a chain that contains withdrawals. A primary client is started first and builds a canonical chain. A secondary client is started afterwards with the primary client as bootnode and then the head of the chain is delivered using `engine_newPayloadV2` and `engine_forkchoiceUpdatedV2`. - Sync after 2 withdrawals blocks, withdrawals fork on block 1, single withdraw account, 16 withdrawals per block, no transactions - Sync after 2 withdrawals blocks, withdrawals fork on block 1, single withdraw account, 16 withdrawals per block, 16 transactions per block - Sync after 2 withdrawals blocks, withdrawals fork on genesis, single withdraw account, 16 withdrawals per block, 16 transactions per block - Sync after 2 withdrawals blocks, withdrawals fork on block 2, single withdraw account, 16 withdrawals per block, no transactions - Sync after 2 withdrawals blocks, withdrawals fork on block 2, single withdraw account, 16 withdrawals per block, 16 transactions per block - Sync after 128 withdrawals blocks, withdrawals fork on block 2, multiple (1024) withdraw accounts, 16 withdrawals per block, 16 transactions per block ### Re-Org Tests Test a client performing a re-org to a sidechain that contains withdrawals, but withdrawals block can occur at a different height (due to timestamp differences). Two clients are started simultaneously and begin on the same genesis. The clients diverge at some point before or after the withdrawals fork is reached. The re-org can be either by delivering all blocks using `engine_newPayloadV2` or triggered via sync by delivering only the head of the sidechain. - Withdrawals fork on block 1, 16 withdrawals blocks, 8 block re-org, re-org using `engine_newPayloadV2` - Withdrawals fork on block 1, 16 withdrawals blocks, 8 block re-org, re-org using sync - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 8, re-org using `engine_newPayloadV2` - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 8, re-org using sync - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 7, re-org using `engine_newPayloadV2` - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 7, re-org using sync - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 9, re-org using `engine_newPayloadV2` - Withdrawals fork on block 8, 8 withdrawals blocks, 10 block re-org, sidechain withdrawals fork on block 9, re-org using sync ### Invalid Re-Org Tests (ToDo) Tests that a client rejects a re-org via sync to a sidechain with an improper withdrawal or withdrawals occurring on the wrong timestamp. ### Verifications All tests include the following extra verifications: - Sending `engine_newPayloadV2` with non-null withdrawals before the fork timestamp. Must result in `INVALID` response with appropriate `latestValidHash` set. - Sending `engine_forkchoiceUpdatedV2` with non-null withdrawals in the payload attributes before the fork timestamp. Must result in error. - Sending `engine_newPayloadV2` with null withdrawals after the fork timestamp. Must result in `INVALID` response with appropriate `latestValidHash` set. - Sending `engine_forkchoiceUpdatedV2` with null withdrawals in the payload attributes after the fork timestamp. Must result in error. - Verify balance of the withdraw accounts using `eth_balanceOf`. - All withdrawn accounts contain EVM code that unconditionally set `storage[0]=1`, which is then verified to be unset after withdrawals occur (since withdrawals must not trigger EVM execution). ## Interop EL+CL Test Suite WIP