Schlesi ETH 2.0 Testnet

Documentation of the Ethereum 2.0 phase-0 beacon-chain multi-client testnet efforts.

This is work in progress.

• Deposit contract: 0xA15554BF93a052669B511ae29EA21f3581677ac5 (Goerli Testnet)
• Current ETH 2.0 specification version support:
  • v0.10.1 (moved to .trash/)
  • v0.11.1
  • v0.12.x

v0.11.1

This repository contains the client configuration files and genesis state for the v0.11.1 Ethereum 2.0 specification multi-client testnet "Schlesi v0.11" for the following clients:

• Cortex
• Lighthouse config: light/, docs: light/README.md
• Lodestar
• Nimbus
• Prysm config: prysm/, docs: prysm/README.md
• Teku config: teku/ (WIP)
• Trinity

Known issues:

• Prysm: ERROR sync: Failed to handle p2p pubsub error=attestation is not aggregated #5649
• Lighthouse: thread 'tokio-runtime-worker-7' panicked at 'elapsed=7481664; when=7481664' #1067
• Lighthouse: No valid eth1_data votes, votes_to_consider empty, outcome: casting state.eth1_data as eth1 vote #1066
• Spec: clarify that eth1 timestamp can be less than min genesis time #1756
• Ligthhouse: Eth1 genesis time is incorrect #1051
• Prysm: Prysm launches beacon chain 1 hour before Lighthouse #5616
• Teku: Unable to peer with Lighthouse or Prysm #1666
• Prysm: Do not reject peers if --p2p-max-peers is reached #5588
• Prysm: Failed to handle p2p RPC error=rate limited #5587
• Lighthouse: Beacon Node: Unable to recover from network fragmentation #949

Clients will be added one by one if they manage to connect, synchronize, and stay in consensus. Work in progress.

F.A.Q.

I'm wondering why ...

Why do we need multi-client test-networks?

The first phase of Ethereum 2.0, the phase 0, is the beacon chain. For the first time, a variety of new clients will be working together on a brand new blockchain with a new, unique approach to networking and consensus.

Before such a mainnet can be launched, we need testnets that mimic mainnet conditions as good as possible. This requires us to have stable, long-term, and persistent testnets up and running that are supported by not only one client but multiple clients, ideally, all clients.

The Schlesi testnet is one of many steps in that direction.

Is Schlesi an incentivized adversarial network?

No. The Schlesi testnet is not incentivized. The current goal is to ensure protocol compatibility across major ETH 2.0 client implementations. Participation is free and permissionless, everyone can create validator deposits at 0xA15554BF93a052669B511ae29EA21f3581677ac5 on the Goerli Ethereum testnet and start validating on Schlesi.

What's the difference between Schlesi and Interop?

The ETH 2.0 Interop Lock-In was a physical meetup of seven client teams working towards interoperability in 2019. This was the first major step towards multi-client testnets, even though the focus of the lock-in was mainly on networking. Other aspects of interoperability were playing minor roles.

For Schlesi, all aspects are important, as they would be important for a potential mainnet candidate.

What's the difference between Schlesi and Multinet?

The ETH 2.0 Multinet is a collection of startup scripts to simulate multi-client testnets with various parameters such as number of validators to run the network with. The multinet is based on a minimal ETH 2.0 specification.

Schlesi, however, is not a simulation. It's a real persistent end-user testnet based on a slightly modified mainnet configuration. Everyone should be able to add validators and beacon chain nodes.

Why does Schlesi use the Mainnet configuration?

The ultimate goal of Schlesi should be proving that the clients are ready to support a potential beacon-chain mainnet. Therefore, it is time to template the testnet as close as possible to mainnet.

Why is there no docker file or startup script?

The focus of the testnet is no longer developer but end-user centric. Each user of the beacon chain should be able to manually complete any task, i.e., setting up a validator or synchronizing a beacon chain node. Scripts will be convenient in future to ease this process but for now we need to ensure that nodes, clients, and other tooling is ready to be used sufficiently to complete all tasks required by a beacon chain mainnet.

Additionally, not having a script that does the job for you, ensures that all node implementations and their according tooling are well documented across the different clients.

Why do you call it Schlesi?

Schlesi (Schlesisches Tor) is a subway station in Berlin with proximity to Goerli and Full Node.

What is the Goerli testnet?

Goerli is a cross-client proof-of-authority Ethereum 1.x testnet. It's well supported across all ETH 1.0 clients, tooling, and infrastructure, and will be used to test the ETH 2.0 transition through a deposit contract deployed to Goerli.

See also

Resources:

• Notes: Longstanding MC-testnet(s)
• Article: How to run your own Beacon Chain
• Stack Exchange: What does the beacon chain deposit contract ceremony entail?
• Stack Exchange: How would a chain specification for a beacon chain look like?

In the news:

• Ethereum 2.0's Phase 0 multiclient testnets will likely go live in April

Historical documentation:

• Gist: Schlesi ETH 2.0 Multi-Client Testnet configuration
• Field notes: Towards a multi-client Ethereum 2.0 testnet
• Call: EF Research & Görli Testnet “Multi-Client Testnet for ETH 2.0”

Previous multi-client testnets:

• Github: eth2-clients/multinet
• Github: eth2-clients/eth2-testnets

License

This is free and unencumbered software released into the public domain. For more information, please refer to unlicense.org