# Dencun testing overview The Dencun upgrade is the next Ethereum protocol upgrade, with a large focus being placed on EIP-4844. This overview document has been made to help comprehend the various parts that will be changed and the corresponding tests required across the EL/CL. Please reach out with feedback about areas of testing that are missing or tools that we should focus on developing. Aims: - Overview of testing and contact people ## Needs: - Testnet verifier: Can verify success/failure of testnet (needs update) - Sync co-ordinator (needs update) - re-org handling tests (likely with kurtosis) - long term archival of blobs (s3 script?) - check blob fee market implimentations across clients - gossip related tooling? ## Categories of testing: ### CL Spec tests: The consensus layer has a canonical specs repository found [here](https://github.com/ethereum/consensus-specs). The specs repository contains a large number of tests that are run with the `minimal` or `mainnet` spec parameters depending on certain conditions. These tests attempt to assert compliance to the defined specs. Contact: [Hsiao-Wei](https://twitter.com/icebearhww) #### EVM related: The upgrade has quite a few EIPs related to changes of the EVM ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153),[EIP-4788](https://eips.ethereum.org/EIPS/eip-4788),[EIP-5656](https://eips.ethereum.org/EIPS/eip-5656),[EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) and [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844)). We'd need to assert that the edge cases are handled across client implimentations and that the results are matching across implimentations. Tools we can use: - Hive - EVM fuzzing - Execution specs - FuzzyVM Contact: [Mario Vega](https://twitter.com/elbuenmayini) #### Sync testing: The presence of blobs will introduce new states for blobs to be in, this effects the states the node is in- which we would need to test: **CL**: [fully synced, syncing, synced to an old state, checkpoint synced, checkpoint synced invalid state] **EL**: [fully synced, syncing] **Blobs**: [available, syncing, expired/pruned] Tools we can use: - [Sync test co-ordinator](https://github.com/samcm/sync-test-coordinator): We need to update this tool, but it should be possible to assert the following conditions: - Sync regular - Sync > blob expiry - Checkpoint sync @ finalized state before and after blob expiry period - Sync with blob missing - Optimistic sync tests The tool also needs a sync target. We'd potentially rely on the public devnet/testnet of the week for this. - Hive - Nethermind Sync testing tools Contact: [Sam](https://twitter.com/samcmAU) or [Pari](https://twitter.com/parithosh_j) or [Mario Vega](https://twitter.com/elbuenmayini) or Nethermind DevOps team #### Chaos tests: [Chaos testing](https://chaos-mesh.org/) allows us to test a number of varying chaotic situations, for e.g: - EL/CL crashes - Network level chaos (increased latency, packet drops, partitions) - Resource stress (CPU/RAM) - Time faults (NTP related) This would allow us to test the below scenarios for the Dencun upgrade: - p2p delays for gossip of blobs - block propagation delays - missing packets on the gossip layer - network partitions Tools we can use: - [Kurtosis](https://github.com/kurtosis-tech/eth2-package) with [Chaos mesh](https://chaos-mesh.org/) - [Antithesis](https://antithesis.com/) Contact: [Barnabas](https://twitter.com/BarnabasBusa) or [Pari](https://twitter.com/parithosh_j) or [Tyler](https://github.com/0xTylerHolmes) #### Public tests: This is the level of tests that includes the community and largely requires the most co-ordination. This includes: - Devnets - Shadowforks (sepolia, mainnet) - Bigboi tests (high validator counts) - [Beacon-metrics-gazer](https://github.com/dapplion/beacon-metrics-gazer) for easy access to performance metrics Contact: [Barnabas](https://twitter.com/BarnabasBusa) or [Pari](https://twitter.com/parithosh_j) #### MEV related tests: Roughly ~80-90% of blocks on Mainnet are produced via the mev workflow. This means we have to test these codepaths. There are largely four parts to the mev-workflow: - clients - mev-boost - relays - builders Each of these parts needs to upgrade for the Dencun fork and would need to be tested. The relays and builders are a bit harder to test since they are the domain of the companies running them. The type of tests we need to conduct: - Integration test: Do all components communicate as expected - Edge cases: Invalid payloads from builder/relay, Valid payload but invalid fields Tools we can use: - [Kurtosis](https://github.com/kurtosis-tech/eth2-package) with `mev_type` set to `mock`(Edge cases and Integration without relay/builder) or `full`(Integration test with all components) Note: We still need to configure the behaviour of `mock` mev mode on kurtosis. Contact: [Kurtosis team](https://twitter.com/KurtosisTech) or [Alex](https://twitter.com/ralexstokes) or [Pari](https://twitter.com/parithosh_j) #### Regression tests: We need to ensure that certain basic cases are tested and that we do not regress on the basic cases. These are reproducible tests we can run nightly or weekly. E.g of basic cases we should test: assert evm calls, check beacon block root, proper expiry of blobs Tools we can use: - [Kurtosis](https://github.com/kurtosis-tech/eth2-package) with the golang SDK to write `go` tests - Hive Contact: [Kurtosis team](https://twitter.com/KurtosisTech) or [Pari](https://twitter.com/parithosh_j) or [Mario Vega](https://twitter.com/elbuenmayini) #### Bad block/blob tests: These are edge cases that could potentially take down the network. Tools we can use: - [Tx-fuzz](https://github.com/MariusVanDerWijden/tx-fuzz) - Internal fuzzing tools Contact: [Marius](https://twitter.com/vdWijden) or EF Security team #### Blob specific tests: Some scenarios that we need to test to assert blobs work as expected. This includes: - `Replacement` and `Cancellations` as DoS vectors in the blob txpool (Perhaps tx-fuzz can do replacements and cancellations and we can test it in kurtosis) - [Eviction strategy](https://github.com/ethereum/go-ethereum/pull/26940) related tests - `reorgs` with blobs being absent or present on the nodes (Hive) - Network partitions to test reinserting (Hive WIP) - Blobs with incorrect proofs (but not blatantly wrt format/etc) - Blob containing all 0 data (causes edge case for the proof) (Potential idea from Mario could take care of the blow points) - Invalid blobs being gossiped by a malicious client - Send blob txs containing 0 blobs - Send blob with no block - Send block with no blob - Staggered sending, i.e: Send blob/block and then wait 1-20s to send the other Testing scenarios from Mario: https://notes.ethereum.org/@marioevz/testing-the-blobs Tools we can use: - [Kurtosis](https://github.com/kurtosis-tech/eth2-package) for some of it - ??? Need a way to send invalid blobs with a malicious client ??? - Hive ??? - ??? Contact: [Pari](https://twitter.com/parithosh_j) or EF Security team