Skip to content

Latest commit

 

History

History
142 lines (113 loc) · 6.43 KB

mainnet-readiness.md

File metadata and controls

142 lines (113 loc) · 6.43 KB

The Merge Mainnet Readiness Checklist

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.

Table of contents

Specification

Consensus layer

  • Specs feature complete
  • Transition process specified #2462
  • Ensure structural conformance with existing specs #2472
  • Rebase with Altair #2530
  • Rebase with London (update ExecutionPayload) #2533
  • Consider weak subjectivity period implications
  • P2P spec (primarily just version bumping topics for new types) #2531
  • Upgrade beacon-APIs to handle new types
  • [BONUS] Annotated specs

Execution layer

  • High level design doc
  • Rayonism spec
  • EIPs
    • EVM DIFFICULTY -> RANDOM
    • EVM BLOCKHASH [unchanged but weaker randomness documented in PoW -> PoS transition EIP]
    • Transition process EIP-3675
  • Network -- devp2p
    • Block gossip deprecation
    • State sync post-merge
    • Block sync post-merge
    • Discovery
  • Upgrade JSON-RPC (execution-apis) with new methods and deprecations
  • [BONUS] Executable execution-specs and testing through the Merge

Engine API

  • Basic JSON-RPC extension, link (used in rayonism)
  • [IN PROGRESS] Production refinements, 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
  • [BONUS] Test vectors

Public facing documents

  • Merge architecture design document
  • Infrastructure provider guide
  • Rename eth1/eth2 to execution/consensus across repos and documentation -- The Great Renaming
  • [BONUS] Consider relationship between execution and consensus spec/API repos and build processes

Testing

Unit tests

  • Consensus
    • Inherit all prior unit tests and generators
    • [IN PROGRESS] Merge specific tests with mocked execution-layer
    • [IN PROGRESS] Fork and fork-choice tests across merge boundary
  • Execution
    • Reuse existing framework for most prior EVM unit tests
    • New DIFFICULTY opcode tests

Integration tests

  • Transition process tests with fully enabled consensus and execution layer
    • Hive: scenario with PoW network partitioning
    • Hive: happy case and various edge case scenarios, e.g:
      • Re-org beyond transition block
      • EL/CL client offline or not upgraded before/during/after transition
      • PoW block propagation before/during/after transition
      • Burst of EL blocks on different forks & optimistic sync interactions
  • Hive with all client combos
  • Hive: consensus+execution integration tests
  • Hive: Engine API tests

Stress tests

  • Single client load/metrics
  • Network load testing
    • Larger blocks
    • Shorter slot times
    • Large execution state.

Fuzzing

  • Beacon-fuzz applied to merge ready consensus clients
  • Existing EVM fuzzing infra applied to merge ready execution engines

Testnets

  • Short-lived devnets without transition process
  • Short-lived devnets with transition process
  • Long-lived devnets
  • Fork public testnets

R&D

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
  • 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?]
  • Execution-layer proof of custody
  • Disaster recovery if invalid chain finalized
    • [WIP] Client multiplexers (link, note: doesn't help with DR, but can potentially prevent invalid chains being finalized)
  • Further threat analysis
    • Miner attacks
    • Resource exhaustion post-merge
  • Fee Market behavior changes (missed slots impact)