# Testing the merge

Hey all,
I thought a bit about the structure of the program.
Given the number of people who showed interest in helping us test, I tried to define three different tracks. This does not mean that you have to decide for one of them. It's just meant to be an easier way for people to get started.
I will not really provide tasks, but I will provide suggestions on what things can be worked on.

## General Information
The program should be pretty self-guided. You decide how much time and effort you want to spend. Every little bit helps! I will try to answer questions as much as possible and try to guide the program a bit. I will also collect important edge cases that we should test. **If you think about edge cases to test, send them to me**. I will add them to this document.

A great writeup with additional ideas for tests is here: https://hackmd.io/@n0ble/merge-test-plan

**Please write as much documentation as possible, so others can build on your ideas**
It would be great if you could share the docs you write on twitter under #TestingTheMerge so that others can quickly find them.

The program is not compensated, but if you find a critical bug (consensus issue/panic), I'll buy you a beverage of your choice at the next DevCon!

### Code of Conduct
With so many new people coming in it is important to follow a few general rules:
- Please be polite to the maintainers! (It's not easy to maintain a client)
- Please double and triple check your issues before submitting
- Please check if someone submitted something similar beforehand
- Please submit issues with all important information (Versions, Steps-to-reproduce)

## Tracks

### Users
This track is primarily meant for non-technical people.
It's really important for teams to gather feedback on problems with setting up their clients and connecting to the testnets.
So ideas for tasks in this category are things like

- Set up a consensus layer client (preferably a minority client)
- Set up an execution layer client (preferably a minority client)
- Join the devnets
- Write documentation
- Report unclear points
- Report failures
- Try different failure scenarios (shutdown one or the other node, restart nodes)
- Write a guide to connect your local node to metamask on the testnet
- Send transactions (write tutorial)
- Measure performance (speed, db usage, etc.)
- Try creating huge blocks
- Run under different architectures (ARM, OSX, M1)
- Test clients with different sync methods (full, fast, snap, warp, weak subjectivity sync)

### Technical
This track is primarily meant for people with a technical background not primarily in ethereum/blockchain.
Some ideas might involve writing some code etc.

- Deposit into the deposit contract
- Run your own validator
- Run a slasher on the testnet
- Deploy and test contracts
- Try breaking the CL or EL clients
- Run a validator with the EL and CL being geographically far away to test latency induced issues
- Try to send invalid/wrong api calls to the EL layer
- Set up fuzzing infrastructure
- Run two different sets of CL/EL clients and note differences in behavior
- Create docker setups, Grafana/Metrics + document
- Write regression tests, (no merge rules should work before the merge happened)
- Test the TTD and TTDoverride
- Setup your own testnets
- Write libraries to interact with the EL and CL JSON-RPC/Rest API's
- Test existing libraries (web3.js, ethers.js,...) on the testnets
- Include invalid transactions in your block
- Join testnets with invalid TTD (too high, too low)

### Highly Technical
This track is primarily meant for people with a highly technical background in blockchain.
Most of these ideas involve writing some code.

- Review the code and see if it matches the spec
- Review the spec
- Add static test cases to the testing repos
- Write tools to visualize the merge, show forks
- Propose invalid blocks
- Propose reorgs
- Write malicious miners/block producers/validators
- Visualize the networking flow
- Work on the integration of merge tests into hive
- Double signing EL payloads
- Signing EL payload with invalid key
- Invalid payload signature
- Depositing pre/during/post merge
- Shutdown validators
- Split the network by voting on invalid blocks
- Split the network by voting on valid but sibling blocks
- Mining two/more competing final pow blocks
- Publishing a future pow final block
- Send post-merge blocks over the network (should be rejected)
- Create a block with invalid mixhash/randomness
- Use the RANDOM opcode
- Build a valid block on top of an invalid parent

### Shadow fork related
- Benchamark: regular goerli sync time, goerli shadow fork sync time(week #1), goerli shadow fork sync time(week #2)
- Attempt syncing in weird circumstances: Stop syncing EL/CL randomly, Switch ELs mid-sync, etc
- Log payload building processing times for various client combinations
- Restart the machine mid sync
- Run the EL and CL on different machines, assume EL goes offline and re-appears later
- Run EL and CL on different machines with different time configured(or clock skew)
- Switch EL mid-payload building request

## Resources

Connect to the devnet: https://hackmd.io/dFzKxB3ISWO8juUqPpJFfw
Collection of tools for devnet: https://kintsugi.themerge.dev
Send a tx over metamask: https://hackmd.io/XPRuPrCATTiGssTgdJSO3g
The original testing plan: https://hackmd.io/@n0ble/merge-test-plan