Skip to content

Latest commit

 

History

History
93 lines (81 loc) · 8.68 KB

LAUNCH.md

File metadata and controls

93 lines (81 loc) · 8.68 KB
Raw

Launch an ETH2 multi-client testnet/mainnet

All of the moving parts that need to come together to successfully launch an ETH2 network.

Examples are italic, here: Medalla.

1. Preparation

The following steps are crucial to design and plan the testnet.

  1. Design the scope, i.e., dev-net, public testnet, attack-net, incentivized network, etc. pp.
    • official public testnet
  2. Optionally, give it a name. This is only necessary for long-term, public or mid-term, semi-public networks. Long names should come with a short handle for the client's config.
    • Medalla, or medalla
  3. Define the version of the specification, e.g., v0.12.2 or v0.11.3, so that all clients can agree on running the same specification. Make sure the specification has tests and a release in the official spec repository.
  4. Pick a chain specification. In most cases, you want to use a mainnet/phase0 config. But there are also potentially needs for minimal or phase1 configs.
  5. Deploy the deposit contract. Either use the official Solidity contract, the Vyper contract, or any customly augmented contract that contains features for testing purposes, i.e., withdrawal functions or validator whitelisting. Make sure to verify it on block explorers for public testnets.
  6. Define a minimum genesis time. You don't want to launch the network prior to that timestamp. Only required for coordinated launches, otherwise just use the default and launch right away.
    • Gregorian: August 4th, 2020, 1pm UTC
    • Unix: 1596546000
  7. Optionally, choose a custom genesis fork version, or modify any other parameters as per your needs, e.g., number of genesis validators or deposit amounts.
    • Genesis fork version: 0x00000001
  8. Add the chosen parameters to the chain specification. The selected chain configuration requires to be updated with everything defined above.
  9. That's it, that's the testnet.

2. Implementation

The following steps are necessary to implement, deploy, and prepare the launch of the testnet. It assumes launching a public or semi-public testnet that requires some coordination. Private or short-term dev-nets could proceed directly to the launch section.

  1. Publish the configuration in an accessable location, e.g., Github, Gist, Pad, Hackmd, etc.
  2. Communicate the scope and chain configuration early with the client teams. They can then decide to bake in the configuration and even, depending on scope and spec version, make it the default testnet.
  3. Bootnodes: This is always our chicken-and-egg item on that bullet list. Do we provide bootnodes first that we can add to the clients or do we implement the config in the clients before setting up bootnodes? Whatever you do first, please publish the bootnode's ENR and/or Multi-Address to Github/Gist/Pads, so other clients can access this resource. It's recommended that each client provides at least one bootnode.
  4. Clients: Implement the specification and bootnodes. Consider giving it internally a meaningful name (medalla), maybe log the spec version (v0-12-2), and provide command-line flags for users to be able to connect to the network (--medalla or --medalla-testnet). Depending on the scope, also consider making it default or just an additional network.
  5. Communicate the planned launch and the scope of the network with other service providers that are potentially interested in the network. Tell them about the name, scope, config, and planned launch date.
    1. Block explorers:
    2. Network monitors:
    3. Staking pools:
    4. Miscellaneous:

3. Launch

The following steps are necessary to launch a network. For the sake of completeness, it assumes a launch of a public, coordinated testnet.

  1. Configure and provide a launchpad. Users that want to validate on the network should be provided with a user interface helping to make validator deposits and get set up completely.
  2. For testnets, provide faucets that allow users to redeem enough testnet tokens to be able to make around one to five validator deposits, e.g., for Goerli.
  3. Make sure everything above is properly documented, especially custom command-line flags, instructions how to run a beacon node or a validator, how to use the launchpad with a certain client, etc. pp.
  4. Client teams should prepare properly tagged releases and binaries if desired to ease running the nodes on the new network.
  5. Provide genesis validators. Key stakeholders and client teams might want to run validators at genesis for various reasons. Make sure to get in deposits before the minimum genesis validator count is met.
  6. Announce the launch if you want a broad audience, either "officially" through the Ethereum Foundation blog or through the client teams communication channels (discord, blogs, etc.).
  7. Monitor the launch. Lean back and check validator deposits, some might be invalid due to outdated tooling or bugs that should be squashed immediately once isolated.
  8. Launch. This is most likely happening automatically once minimum validator deposits are met and the minimum genesis time passed. It's worth comparing the computed genesis time, the fork digest, initial state and block root across the clients. Make sure they match.

That's it. Now proceed to Phase 1. 😄