This document outlines various tasks to work through to make the Merge ready for Mainnet release.
Note: The set of items is not final and will be aligned with ongoing R&D and implementation work.
- Specs feature complete
- Transition process specified #2462
- Ensure structural conformance with existing specs #2472
- Rebase with Altair #2530
- Rebase with London (update
ExecutionPayload
) #2533 - P2P spec (primarily just version bumping topics for new types) #2531
- Optimistic sync spec
- Upgrade
beacon-APIs
to handle new types - [BONUS] Annotated specs link
- High level design doc
- EIPs
- Network -- devp2p
- Block gossip deprecation EIP-3675
- State sync post-merge
- Block sync post-merge
- Discovery
- Upgrade JSON-RPC (
execution-apis
) with new methods and deprecations #200 - [BONUS] Executable
execution-specs
and testing through the Merge
- Basic JSON-RPC extension, link (used in rayonism)
- Production refinements Engine API. Previous docs: WIP doc, Interop Edition
- Support execution-layer state sync
- Support async block insert
- Consider support for
Consensus <-> Execution
consistency (e.g. recover from crash or bad insert on execution layer) - Consider bi-directional communication
- ...
- Discuss JSON-RPC vs websockets vs restful http
- Migrate to execution-APIs or other permanent home, link
- Remove unauthenticated port from specification #219
- Merge architecture design document
- Application Layer Impacts
- Rename eth1/eth2 to execution/consensus across repos and documentation -- The Great Renaming
- Mega Merge Resource List
- Infrastructure provider guides
- https://launchpad.ethereum.org/en/merge-readiness/
- Additional community guides & documentation TBA
- Consensus
- Inherit all prior unit tests and generators
- Merge specific tests with mocked execution-layer
- Fork and fork-choice tests across merge boundary
- Execution
- Reuse existing framework for most prior EVM unit tests
- New
DIFFICULTY
/PREVRANDAO
opcode tests - EIP-3675
- Testnet chaos messages
- Hive
- Mocked CL for EL engine API unit testing
- CL+EL integration ests with all client combos
- Engine API tests
- Merge transition tests
- Shadow forks on a weekly basis to continuously test live transition and TX replays
- [BONUS] Additional simulation testing -- e.g. kurtosis, antithesis, etc
- Fuzz engine API
- Existing EVM fuzzing infra applied to merge ready execution engines
- Beacon-fuzz applied to merge ready consensus clients
- Short-lived devnets without transition process
- Short-lived devnets with transition process
- Long-lived devnets
- Fork public testnets
- Ropsten (deprecated after merge)
- Sepolia
- Goerli
Most research related to the merge has been completed. This section lists topics which are either tangentially related, or nice-to-haves, and still require R&D work.
- Transition process analysis
- Evaluate precision of TD computation on historic data
- Execution-layer sync
- Historic block sync (reverse header then forward body)
- Historic state sync (optimistic beacon block transition provides head data for EL sync)
- Sync during transition period (forward sync to PoW TTD, reverse sync past TTD)
- Discovery [is there actually anything to do here?]
- [In research, not to be included merge] Execution-layer proof of custody
- Consider weak subjectivity period implications
- Generate accurate weak subjectivity period calculations
- [IN PROGRESS] Specify standard data format & methods for weak subjectivity checkpoint distribution
- Disaster recovery if invalid chain finalized
- EL will perform re-orgs beyond finality but at a potential high sync cost
- [WIP] Client multiplexers (link, note: doesn't help with DR, but can potentially prevent invalid chains being finalized)
- Stress tests
- Single client load/metrics
- Network load testing
- Larger blocks
- Shorter slot times
- Large execution state (shadow-forking mainnet)
- Further threat analysis
- Miner attacks
- Resource exhaustion post-merge
- Fee Market behavior changes (missed slots impact)
- EIP-4396 proposed