• Follow
    Subscribe to EtherWorld.co
    Get the latest posts delivered right to your inbox
    Great! Check your inbox and click the link to confirm your subscription
    Please enter a valid email address!

The Evolution of Ethereum Testnets

An extensive research report on the evolution of the Ethereum testnets from genesis till the Merge upgrade.

Go to the profile of Yash Kamal Chaturvedi
34 min read
By Yash Kamal Chaturvedi
The Evolution of Ethereum Testnets

Table of Content

Sincere thanks to Tim Beiko, Péter Szilágyi, MariusVanDerWijden & Pooja Ranjan for reviewing and sharing details to be added to this report.

What is an Ethereum Testnet?

Ethereum test network (a.k.a testnet) is an infrastructural setup with an almost identical environment created to test a contract or protocol to be deployed on the main network (a.k.a. mainnet).

It is the main network's replica, except that the gas (Ether) used for the execution has no real economical value. Testnet enables decentralized applications (dApps) to interact with simulated blockchain environment without having the risk of using real ETH. It is a handy tool for developers to try the software to check for bugs before deploying them to the mainnet.

Mainnet Vs Testnet Vs Devnet

Criteria Mainnet Testnet Devnet
Goal Actual Functional Blockchain where all transactions happen Testing Environment Development Environment
Who can use? Anyone Anyone Developers & Testers
Tokens Has Economic Value No Economic Value No Economic Value
Number Only 1 mainnet Multiple testnets are possible Multiple devnets are possible

Popular Test Networks

TestnetsTimeline

Proof of Work (PoW) Testnet

pow_changes--1-

Olympic Testnet

This is the first-ever public Ethereum blockchain based testnet and was launched even before the official launch of the Ethereum Mainnet. It was launched early 2015. It had a network ID of 0.

Olympic was famously known as "Ethereum 0.9".

It was a Proof of Work testnet and was intended to be the final test before the public release of the Ethereum main network.

Why Ethereum developers created Olympic Testnet?

The main purpose of the Olympic Testnet was to reward people who try to test the limits of the Ethereum blockchain during the pre-release period, spamming the network with transactions and doing crazy things with the state, so that the developers could see how the network holds up under high levels of load. At the same time, application developers, data providers, exchanges, and users were encouraged to develop and deploy on the testnet and run nodes.

The Ethereum Developement team also announced a prize fund of 25,000 ether. This prize was for the person who would first create a substantial fork on the testnet.

Failures of the testnet: The size of Olympic blockchain was very large, and it also had some issue with keys (private keys created on Olympics could potentially be vulnerable).

The Olympic Testnet was deprecated on July 2015 after the successful launch of the Ethereum Mainnet.

Morden Testnet

As the public Ethereum main network was launched back in July 2015, there was a need for a new Testnet which could go hand-in-hand with the mainnet. This was the basis for the developement of the Morden Testnet which eventually replaced the Olympic Testnet.

This testnet was also based on PoW consensus mechanism.

The Morden Testnet had a network ID of 2 and was the only Testnet for over a year.

This Testnet was deprecated in November 2016 due to some accumulated junk and some testnet related consensus issues between Geth and Parity, the two major clients at the time.

Morden Classic Testnet: This testnet remained active in the Ethereum classic community and was renamed as "Morden Clasic Test Network".

Ropsten Testnet

Ropsten is the third testnet and follows the Proof of Work consensus mechanism. This testnet was named after a subway station in Stockholm, Sweden. It has a chain and network ID of 3. This testnet was launched in late 2016 due to multiple issues in the old testnet and finally replaced The Morden Testnet.

Clients Support: The Ropsten test network supports all major Ethereum clients such as Geth, Parity (deprecated), Nethermind, Hyperledger Besu and even the Akula, the latest Ethereum client. It is the only available test network that uses the Proof-of-Work consensus mechanism till the launch of Sepolia testnet. As of May 2022, there are approximately 12.3 million blocks on the Ropsten testnet and developers have executed roughly 230 million transactions to date.

The Ropsten DoS attack: In February 2017, the Ropsten test network had a major Denial of Service (DoS) attack.

Basically a Denial-of-Service (DoS) attack is an attack meant to shut down a network, making it inaccessible to its users. DoS attacks accomplish this by flooding the target with traffic, or sending it information that triggers a crash.

This made it hard for Ethereum clients to sync with the Ropsten network, by slowing down the network and consuming excessive disk space. This attack would gradually inflate the block gas limit from 4.7 million to about 9 billion, crippling the network whenever large transactions were sent and creating a lot of spam blocks.

The Ropsten team succeeded in reviving the network in March 2017 by throwing in GPU hash power donated by the community, thereby clearing all the spam blocks that had been accumulated due to the attack.

The Ropsten Proof of Work testnet was merged and proof of stake has been activated on 8th June, 2022.

Sepolia Testnet

Image Source

Sepolia testnet was launched on October 2021 to eventually replace the Ropsten Testnet. It is a cross-client PoW testnet which is a like-for-like representation of Ethereum mainnet. It has a chain ID of 11155111. Sepolia is made mostly for client developers’ and for dApp developers to have a public space to harden and make their software resistant to attacks. After the software is tested in the testnet, it can be deployed to the mainnet.

  • As Sepolia is based on a PoW consensus mechanism, SEPPETH, the Ether used in the testnet, can be mined. Instead of relying on faucets to get the test ether, it is better to stash SEPPETH.
  • Sepolia has mostly public validators, not pre-authorized validators, so it fails to reach finality sometimes. The difference between Sepolia and other Ethereum testnets is that Sepolia is a public testnet run primarily by public verifiers, unlike testnets like Kovan that only allow fixed sets of verifiers.
  • These public validators who have not undergone any background check or capability testing by network participants, could possibly fail to have the necessary hardware and software to stay connected to the testnet at all times, and hence cause the chain to fail to finalize.

The Sepolia Testnet has been transitioned from PoW to PoS on 6th July, 2022 at 17:00 UTC.

Client Integration Testnets

All these testnets were used for testing basic infrastructure. They were not used for deploying dapps and there was no guarantee that EIPs included will go into the mainnet.

YOLO

Image Source

You Only Live Once (YOLO), was an official ephemeral test network for Ethereum. An ephemeral environment is a short-lived, encapsulated deployment of an application. It provides robust, on-demand platforms for running tests, previewing features, and collaborating asynchronously across teams.

It was the pre-Berlin ephemeral testnet, created specifically to test available frameworks of the Ethereum blockchain. Therefore, it was a short-lived. It was not a replacement for existing testnets on the execution layer (PoW) chain.

The requirement of an ephemeral testnet surfaced during the discussion for testing BLS curve signature EIP. As a result, Ephemeral Testnet YOLO was created.

YOLO v1 was launched on June 03, 2020.

Image Source

After a few days of the launch of the YOLO testnet, It was blown up as it went out of the disk. Later, the Issue was resolved by the Geth team. Nethermind was not able to sync with YOLO Testnet. Three major clients, i.e., Geth, Open Ethereum, and Besu, were successfully synced before the network stopped.

YOLO v2 was launched on October 10, 2020. It was the pre-Berlin ephemeral testnet.

YOLO v3 was later launched on February 03, 2021.

Aleut

Aleut was the first client integration testnet for the London Upgarde with all 6 PoW clients participation. Discussed during Ethereum Core Devs Meeting #109 on April 2, 2021, it was used to test EIP-1559: Fee market change for ETH 1.0 chain and EIP-3198: BASEFEE opcode.

Deployed on ChainId: 7822, the testnet was named after Aleutian Trench, i.e., an oceanic trench which runs along the southern coastline of Alaska and the Aleutian islands. It was the 1st devnet for London Upgrade.

Baikal

Baikal was the next client integration testnet/devnet. It was discussed during Ethereum Core Devs Meeting #113 on May 14, 2021.

In addition to EIP-1559: Fee market change for ETH 1.0 chain and EIP-3198: BASEFEE opcode, this testnet included 2 additional EIPs for testing - EIP-3529: Reduction in refunds and EIP-3541: Reject new contract code starting with the 0xEF byte. All 6 clients signalled but only Besu, Geth & Nethermind were able to sync.

ID: Baikal

EthStats: https://baikal.ethdevops.io/

Faucet: https://faucet.baikal.ethdevops.io/

Explorer: http://18.224.51.102:3000/

ChainId: 1642

NetworkId: 1642

It was named after Lake Baikal, i.e., a massive lake in the mountainous Russian region of Siberia. It was the 2nd devnet for London Upgrade.

Calaveras

Calaveras was discussed during Ethereum Core Devs Meeting #114 on May 28, 2021. It was used to test the same set of EIPs as of Baikal.

Calaveras had ChainId & NetworkId: 123

EthStats: https://calaveras.ethdevops.io/

Faucet: https://faucet.calaveras.ethdevops.io/

Explorer: http://18.224.51.102:3000/

JSON RPC endpoint: http://18.224.51.102:8545/

It was named after Calavera, i.e., a representation of a human skull. It was the 3rd devnet for London Upgrade.

Proof of Authority (PoA) Testnets

poa_changes

The Proof of Authority (PoA) consensus mechanism leverages the value of identities, which means that block validators are not staking tokens but their own reputation instead. Therefore, PoA blockchains are secured by the validating nodes that are often selected as trustworthy entities.

Kovan Testnet

The DoS attack on Ropsten led to the birth of two new testnets, Kovan is one of them. This testnet was created by the Parity team in March 2017.

  • The Kovan testnet uses the Proof-of-Authority consensus mechanism which abandons decentralization for security, by maintaining a small group of trusted signers and validators, who ensure the creation of new blocks in the network by staking their reputation.
  • Just like some of the previous testnets, the Kovan test network is named after a subway station in Singapore.

It has a network ID of 42 and takes about 4 seconds to create a new block. This test network is only supported by Parity (OpenEthereum) and not by any other Ethereum clients and does not fully reproduce the current production environment. It is a very old proof-of-authority testnet for those still running OpenEthereum clients.

Rinkeby Testnet

Image Source

Both Kovan and Rinkeby were created in response to the Ropsten attacks. Kovan was unilaterally announced by the Parity team and was using Aura, a very very involved engine not supported by anyone else. Rinkeby was designed to be a true replacement for Ropsten where it's based on a consensus engine that can be realistically implemented by other clients too (Clique). Péter Szilágyi

The Rinkeby Testnet was created on April 2017. As the Kovan Testnet was quickly created in response to the Ropsten attack by Parity (OpenEthereum), Rinkeby was designed to be a true replacement for Ropsten. This network was also named after a subway station in Stockholm, has a network ID of 4, and a block time of 15 seconds.

Rinkeby is an Ethereum testnet that client developers use to test protocols and dapp developers to complete testing of their own decentralized applications. The network can be joined by anyone. However, the signers are pre-approved, just like in Goerli. This is to prevent spam attacks and improve performance of the testnet.

There are currently about 11,000,000 blocks on the network and as of 2021, Rinkeby had about 164,290,117 transactions.

Why use Rinkeby?
Using PoA, enhances security overall. Rinkeby has 15 sec blocktime close to Ropsten testnet, yet, it was preferred by developers because it is more protected compared to PoW testnets.

People chose Rinkeby because Ropsten was often attacked by malicious miners, causing long reorgs or empty blocks and it was just unreliable. Rinkeby - with it's controlled miner set - behaved correctly and reliably. Péter Szilágyi

  • The chain data size for Rinkeby is only about 6 GB. That means if you wanted to run an Ethereum node for Rinkeby, it wouldn’t require a large amount of data size compared to other testnets.
  • Rinkeby has a better track record than Goerli. The only difference was that Goerli tried to have many more validators whereas Rinkeby kept it to the original 7.

Overall, Rinkeby is often known to be more reliable and faster than other testnets.

Clients Support
Rinkeby uses the Clique consensus engine. Clique was specced by Péter Szilágyi even before Rinkeby launched. The spec stayed frozen ever since.

  • The Rinkeby testnet is supported by all Ethereum clients that support Goerli (PoA) testnet. The only reason it was more "geth" specific is because all signers were running Geth and team didn't want to risk breaking the network while other clients implement the Clique consensus engine.
  • With the efforts of Go-Ethereum team, a robust Clique consensus engine is created, which is what Goerli is also running. Goerli was a nice testbed for other clients to catch up and is currently supported by all major clients.

Limitations of Rinkeby
One drawback of using Rinkeby is that the blockchain consensus model for demonstrating authority does not completely simulate the production environment. This is different from the Ropsten testnet, where miners on the network have financial incentives to maintain the testnet itself. The Ropsten testnet uses the PoW consensus mechanism, which is the same as the current Ethereum consensus mechanism.

Rinkeby <> The Merge Upgrade
The Rinkeby testnet will not run through The Merge. Once the Ethereum mainnet transitions to proof-of-stake, Rinkeby will no longer be an accurate staging environment for Ethereum mainnet testing. A list of changes introduced by The Merge that application developers should be aware of is available here.

Deprecating Rinkeby
Maintainer of Rinkeby, the Go-Ethereum team merged a pull request by Péter Szilágyi adding a warning for Rinkeby users and making an official announcement to deprecate the testnet. Rinkeby testnet may still work, if maintained by the community but there will be no further hard-forks shipped for it by the Go-Ethereum team. If no community support is received, eventually the network will be permanently halted after other test networks transition through The Merge and proven to be stable enough.

Developers who currently use Rinkeby as a staging/testing environment should prioritize migrating to Goerli or Sepolia, and projects who are affected by Ethereum’s transition to proof-of-stake should aim to do so as soon as possible.

Goerli Testnet

Image Source

Görli or commonly pronounced as Goerli is one of the testnets for the Ethereum network. It is named after a train station in Berlin and was introduced in Görlicon in September 2018. This test network would start out as a hackathon project by the Chainsafe team in #ETHBerlin. It was an attempt to implement Parity’s Aura Proof-of-Authority consensus mechanism into Geth by rewriting it in GO.

  • It became an official project when Afri Scohedon worked with the Chainsafe team to create a "next generation" public PoA testnet.
  • It is the most stable testnet for application developers.

The Gorli network has a network id of 5, a chain id of 5, and an average block time of 15 seconds.

The early steps taken by Ethereum developers included:

  • Sufficiently specifying Clique proof-of-authority consensus protocol and Aura. However, reimplementing Aura in Go failed miserably, because it was a very invasive protocol.
  • Goerli was bootstrapping a new simplistic proof-of-authority test network based on the available implementation that mimics the main network’s conditions. And ended up using Rinkeby's consensus engine (Clique) as it was designed to be as minimally intrusive to the codebase as possible.
  • All other clients ended up implementing Clique.

These steps led to the successful launch of the Gorli network on Jan 31, 2019.

Rinkeby has a better track record than Goerli. The only difference was that Goerli tried to have many more validators whereas Rinkeby kept it to the original 7.

Goerli remains the only Proof-of-Authority network robust enough to guarantee consistent availability. Switching to PoS consensus, Goerli will be available for protocol & dApps testing.

Client Participation: This testnet is compatible with all major Ethereum clients including Geth, Parity, Hyperledger Besu, Nethermind and more.

Goerli’s Merge with Prater testnet: Prater is a beacon chain testnet that can be used to verify whether a setup is ready for deployment on Ethereum beacon chain mainnet. It also ensures that users can practice node operations such as adding and removing validators, migrations between clients etc. Goerli testnet is planned to be merged with the Prater proof-of-stake beacon chain testnet. This will ensure the end of the permissioned PoA phase and everyone will be able to run as a validator for Goerli-Prater testnet, post merge.

PoS Testnet

Single Client Testnets

All of these testnets were client specific testnets, i.e., focusing on single client.

Prysm

Name Date
Sapphire January 09, 2020
Topaz April 18, 2020
Onyx June 15, 2020
Sapphire Testnet

It was the first mainnet-capable test network for the beacon chain, launched on January 09, 2020. There were around 16,384 validators at the genesis and a queue of over 10,000 in line. This testnet was a huge success as during the first four days, it had over 19667 active validators with over 9000 more in the queue. It was the largest public ETH2 testnet of at that time.

Topaz Testnet

It was launched on April 18, 2020. In the Sapphire testnet, the dev team targeted the mainnet but used smaller 3.2 ETH deposits. But, For Topaz Testnet, validators will have to deposit the full 32 ETH Deposit like the mainnet(beacon chain). 97.4% of active validators were properly proposing blocks and voting on blocks consistently.

Onyx Testnet

It was launched on June 15, 2020. Within a week of its launch, Onyx has around 20,000 validators and stable participation. It was a new and improved version of Topaz Testnet. Some high-level changes included in this testnet were:

  1. Better handling of attestation subnets over p2p
  2. Improving the Robustness of the Networking Implementation
  3. Significantly improved testing around consensus code such as rewards/penalties calculations
  4. Improved eth1 data handling
  5. Ensure balances remain unchanged for optimal validators during inactivity leak, which will significantly improve user experience

Teku

Coorparoo Testnet

It was a short-lived Devnet that activates the Altair fork at epoch 10. Altair was the 3rd network upgrade for Ethereum ecosystem in 2021, but the first on the Beacon Chain (the POS chain) that went live on Dec 01, 2020 and runs in parallel to the Ethereum POW chain.

Multi-Client Testnets

Name Date
Schlesi April 27, 2020
Witti May 27, 2020
Altona June 29, 2020
Medalla August 4, 2020
Spadina September 29, 2020
Zinken October 12, 2020
Toledo November 10, 2020

There was need of multiple multi-client testnets that mimic mainnet conditions as good as possible and support multiple clients, ideally, all clients.

Criteria Schlesi Witti Altona Medalla Spadina
Reason 1st Multi-Client Beacon Chain Testnet Due to issues in Schlesi & For More Client Support To Ensure some degree of Stability b/w Clients Final Large Scale Multi-Client Testnet Final Practice before Beacon Chain Launch
Client Support Lighthouse & Prysm Lighthouse, Prysm & Teku Lighthouse, Prysm, Nimbus & Teku Lighthouse, Lodestar, Nimbus, Prysm & Teku Lighthouse, Nimbus, Prysm & Teku

Later, due to bugs in Spadina, Zinken Testnet was released for better dress rehersal before official beacon chain launch.

Schlesi Testnet

Schlesi was a multi-client Beacon chain Testnet. Its main goal was to show that clients were ready to support a potential beacon-chain mainnet. Participation in Schlesi was free and permissionless. Its Genesis event happened at 10:00 am UTC on April 27, 2020.

Why the name Schlesi was selected?

Schlesi, i.e., Schlesisches Tor is a subway station in Berlin.

Image Source

Schlesi Testnet had multiple severe consensus issues. Some of these issues are:

Before Schlesi Testnet, Developers were using multinet and beacon-fuzz.Multinet was a collection of startup scripts to simulate multi-client testnets with various parameters such as the number of validators to run the network. Beacon Fuzz was open-source fuzzing framework for beacon chain. It was maintained by Sigma Prime for the Ethereum Foundation. Its goal was to identify bugs and vulnerabilities on various client implementations.

Witti Testnet

Witti Testnet was the next multi-client Beacon chain Testnet after Schlesi Testnet. Due to multiple consensus issues, Witti was introduced, and support for new clients was added. Its Genesis event happened on May 27, 2020.

Why the name Witti was selected?

Witti, i.e., Wittenbergplatz is a subway station in Berlin. It's the first testnet named by a subway station in Berlin that is not located in the district of Kreuzberg, where many blockchain companies, including the ETH DEV, have their offices.

Witti

Image Source

Altona Testnet

The Schlesi genesis contained 50% Lighthouse and 50% Prysm validators. The Witti genesis featured three clients, i.e., Lighthouse, Prysm, and Teku. On the other hand, Altona featured four clients, i.e., Lighthouse, Prysm, Nimbus, and Teku. The goal of Altona was to ensure some degree of stability before an official announcement of a large-scale official multiclient testnet. Its Genesis event happened at 10:00 am UTC on June 29, 2020.

Why the name Altona was selected?

Altona is a subway station in the city of Hamburg, Germany.

Altona

Image Source

Medalla Testnet

The Medalla testnet aims to be the final multi-client testnet before the beacon chain launch. It supported five clients, i.e., Lighthouse, Lodestar, Nimbus, Prysm, and Teku. It was launched on August 4, 2020.

Why the name Medalla was selected?

Medalla means medal and can be seen as a reference to the Olympic testnet used to prepare the execution layer (eth1) launch. It emphasizes the importance of the network at this stage toward the consensus layer (eth2) launch. It can also be seen as a hint that Medalla validators will receive a proof of attendance medal on the Ethereum network for participation.

Medalla Testnet Bug

Due to a bug on Medalla Testnet, It was halted on August 14, 2020. Users noticed that their Prysm node was reporting their clock was off, and they saw blocks from the future. Prysm was using the roughtime protocol to adjust the client clock automatically. This protocol works by querying a set of servers in sequence with a chain of signed requests/responses, and the client would take the average of these responses to adjust their clock. When the roughtime client took the average of these results, it thought that the correct time was Fri, August 14, 2020, 22:20:23 GMT.

Rather than deleting the roughtime code entirely, the dev team modified it to require a runtime flag to adjust the clock instead of changing it automatically by default. The dev team decided to push an emergency release and ask everyone to update the new code immediately. However, right before the team did this, the roughtime servers recovered.

Image Source

At approximately 2 AM UTC, every validator active during the roughtime incident was now attempting to get slashed. The team later resolved this. If you want to know more about the Medalla Tesnet Issue, Read the Eth2 Medalla Testnet Incident Report by Raul Jordan, Ethereum core developer by Prysmatic Labs.

Spadina Testnet

Spadina

Image Source

The Spadina testnet aims to be the final practice or dress rehearsal before the beacon chain launch. It supported four clients, i.e., Lighthouse, Nimbus, Prysm, and Teku. It was launched on September 29, 2020. It was planned to be a short-lived testnet, i.e., about 72 hrs. This was a small-scale testnet with 1024 validators to genesis, where the mainnet spec requires 16384 validators to launch. Here is the live recording of the launch of Spadina Testnet by the Ethereum Foundation.

Why the name Spadina was selected?

Spadina is a subway station in the city of Toronto, Canada.

Zinken Testnet

Image Source

Ethereum developers launched a second dress rehearsal testnet after the Spadina testnet failed due to critical peering issues. Unfortunately, the Spadina testnet suffered from a lack of finality at launch, with very few Prysm nodes participating, leading to community confusion and a bad look for genesis rehearsal. Here is the Post Mortem Report by Prysm Team, if someone wishes to know more. Zinken Testnet was launched on October 12, 2020. The developers' community felt that it was essential to have an ideal testnet launch before moving to the mainnet launch.

Why the name Zinken was selected?

Zinkensdamm is a Stockholm metro station in Stockholm, Sweden.

Toledo Testnet

Image Source

Toledo Testnet was temporary dev-net to test the first v1.0.0 client candidates. It is not a public testnet. It was launched on November 10, 2020. It was used to test the Lighthouse slasher. After that team launched Pyrmont Testnet in the next week

Why the name Toledo was selected?

Toledo is also a city and municipality in Spain. This is another Toledo: Toledo Via in Naples, Italy and its metro station filled with art.

Public Attacknets

These attacknets were incentivized with multiple tiers of bounties to break them.

Single-client beta-0 attacknets

All these networks were single clients and were very small, i.e., only four nodes, each with 128 validators. There were three types of active beta-0 attacknets:

  1. lighthouse-attack-0
  2. prysm-attack-0
  3. teku-attack-0
    The goal was to prevent finality on a single network for 16 continuous epochs. $5k was rewarded to those that achieved the goal.

Multi-client beta-1 attacknets

It comprises 15 nodes and 4500 total validators, split across three clients, i.e., prysm, lighthouse, and teku. Goals and Rewards were divided into 4 separate tiers:

Reward Goals
$25k (i) sustained network (p2p) split of all nodes of 1 client from others (> 16 epochs) (ii) consensus split of 1 client type from others (iii) multi-client DoS vector able to disrupt finality (> 8 epochs) or take a set of nodes entirely offline
$15k multi-client DoS vector able to reduce the majority of nodes' peer count to less than 5
$5k single-client DoS vector able to reduce the activity of all nodes of a single client type to less than 10% success rate (> 8 epochs)
$1 - $25k novel and interesting attacks not explicitly mentioned above

Pyrmont Testnet

Image Source

Client developers successfully launched the Pyrmont testnet at genesis time afternoon UTC on November 18, 2020. Pyrmont genesis started with 100,000 validators, about 160 beacon nodes, and more than 250 signatures per second. It replaced the existing Medalla multiclient testnet.

What the name Pyrmont was selected?

Pyrmont is an area in Sydney, a favorite of Sigma Prime (Lighthouse) devs, and the location of EDCON 2019.

Features:

  • It was planned to run until mainnet launch and serves the purpose of testing v1.0.0 with mainnet settings on a large network.
  • It was larger than the average testnet with over 100,000+ live validators.
  • It was similar to the mainnet w.r.t. configuration.
  • Users were able to try staking setup ahead of mainnet launch.

Prater Testnet

Image Source

Prater is one of the largest and longest running Beacon chain testnet that was deployed in March 2021 by Ethereum Foundation and is a successor of Pyrmont testnet.

Why the name Prater was selected?

Prater is the name of a large amusement park in Leopoldstadt, Vienna, Austria.

Features:

  • The basic idea behind creating it was to make a testnet twice as large as the Mainnet so that we could push the limits of the client’s performance.
  • It is a testnet that we can use to verify that our setup is ready for mainnet, as well as safely practice node operations such as adding and removing validators, migrating between clients, and performing upgrades and backups.
  • It is run by client teams, the Ethereum Foundation, and community members.

Special Case of Prater: Insecura Testnet

It was the spin-off of Prater testnet to demonstrate the weak subjectivity attack.

Subjectivity is one of the essential elements in PoS blockchains because selecting the correct chain from multiple forks is done by counting historical votes. Unfortunately, this exposes the blockchain to several attack vectors.

Also, if 33% of validators withdraw their stake but continue to attest and produce blocks, they might generate an alternative fork that conflicts with the canonical chain. New nodes or nodes that have been offline for a long time might not be aware that these attacking validators have withdrawn their funds, so attackers could trick them into following an incorrect chain.

Ethereum can solve these attack vectors by imposing constraints. To know more about it, Read Insecura - Consensus for the Pyrmont Network by EthResearch Team.

Merge Testnets

Name Date
Rayonism April 30, 2021
Nocturne May 12, 2021
Amphora October 7, 2021
Pithos October 14, 2021
Kintsugi December 20, 2021
Kiln March 15, 2021
Ropsten - RBC Jun 08, 2022
Sepolia - SBC July 06, 2022
Goerli - Prater Aug 11, 2022

Rayonism Testnet

Image Source

Rayonism is a style of abstract art developed in Russia. Rayonists seek to break the barriers between the artist and the public.

  • Rayonism is a project that takes the research and engineering efforts of the Eth1-Eth2 Merge and Sharding, and builds a testnets around the ETHGlobal Scaling Hackathon. The name is taken from an early abstract art movement with sharding and beacon motives.
  • It is a reference to Optimism. The goal is to build a version of Optimism with shard data. This may spin out as post-hackathon effort.

The Rayonism project was focused on building a testnet to simulate the merge to Proof of Stake. It was a month-long hackathon in May 2021 to prototype the Eth1 (execution layer) and Eth2 (consensus layer) merge. Its main goal was to Built prototypes with:

  1. Consensus: Prsym, Lighthouse, Teku, Nimbus
  2. Execution: Geth, Besu, Nethermind

Rayonism's Roadmap:

  • March 28: Initial Merge specs land in dev eth2.0-specs
  • March 29: Rayonism project starts
  • Early April: Initial Phase 1 refactor lands in eth2.0-specs, modularizing Sharding
  • Early April: target for Eth2-Eth1 devnet following the Merge specs
  • April 16: ETHGlobal Scaling Hackathon starts
  • Mid April: Sharding minimal viable specs target (No Custody Game or Data Availability Sampling)
  • During hackathon:
    • develop merge functionality on top of participating Eth1 and Eth2 clients
    • develop sharding functionality on top of participating Eth2 clients, enable KZG in EVM on Eth1
  • Stretch goal: Initial L2, Optimism-Eth2 prototype
  • May 14: Hackathon ends
  • Post-hackathon: launch public trial testnet with Merge and Sharding

The final testnet, Nocturne, was a proper post-merge network.

Source

Nocturne Testnet

Image Source

The Nocturne testnet, that was introduced in the Rayonism Hackathon, went live on 12th May, 2021 and lasted for a week. This testnet had a block explorer, which was helpful to see transactions in the Beacon chain blocks. It was a multi-client Merge testnet consisting of 4 consensus-engines and 3 execution-engines. It was also useful for debugging. The developers were able to reach finality during the first possible epoch. By achieving finality it proved that the execution clients and consensus clients were in consensus with each other. There were no bugs in the communication protocol design. However there was an issue with the Eth1 data voting.

The network was able to process EVM transactions and use the beacon chain to request and finalize blocks, all while allowing any combination of execution & consensus engine.

Over the course of four weeks, two simulation “testnets” successfully emerged: Steklo, which ran for a day, and Nocturne, which ran for a week.

Genesis time: 1620820800 😉

eth1 chain id: 702

Devnets 0-5

Devnets are testnets where there is no participation from the community, they are for the developers internally to make sure everything works well and perfectly.

There has been 6 Devnets so far starting from "merge-devnet-0" till "merge-devnet-5".

The main goal of Devnets is to go throgh the merge transaction.

The devnets help us in testing:

  • Interoperability between different client combinations
  • Stability of the network in different scenarios
  • Optimistic sync targets
  • Tooling to visualize/debug issues

Here are all the devnets till now:

  • merge-devnet-0
    It is a broken devnet due to edge. It is added as a base to test future scenarios.

  • merge-devnet-1
    There was a Geth bug at the begining and was relaunched after which it worked perfectly fine.

  • merge-devnet-2
    It worked smoothly and was used as an initial target for public testing.

  • merge-devnet-3
    There was a ommunication issue which caused post merge problems. After an update it worked well. It was used to test some internal tooling as well as interesting transactions.

  • merge-devnet-4
    Here, multiple TTDs were detected and the chain was finalized without intervention or problems.

  • merge-devnet-5
    In this devnet, there was more client participation. It was also closer to the mainnet and had a longer PoW time.

Amphora Testnet

Image Source

Amphora was not a single testnet, it was a bunch of devnets.
The Ethereum Foundation planned the Merge interop workshop with 40 representatives of Execution Layer and Consensus Layer from October 2nd to 9th, in Greece. The goal of the woekshop was to tackle engineering-related problems on Ethereum Merge implementations, track clients’ progress on the devnet called Amphora. The developers’ team considers this to be successful testing for the Merge, where Ethereum will move from PoW to PoS algorithm.

The Amphora Milestones aimed to first get clients confirming with the specs, then gradually adding more complexity and finally growing the amount of other clients they could interoperate with.

There are 5 milestones and are named M1, M2, M3, M4 and M5. The goal of the milestones were:

M1 - only required clients to implement the merge specification.

M2 - had execution layer and consensus layer teams pair one on one, and launch a post-merge devnet. This ensured that both layers could successfully communicate via the Engine API in a PoS context.

M3 - M3 is where the Amphora workshop moved a step beyond Rayonism. The clients set up emphemeral devnets which ran through the PoW to PoS transition.

M4 - M4 was the real target for the event which was to get multiple EL & CL clients on a devnet which went through the entire PoW to PoS transition. M3 was about one-to-one devnets, M4 was about many-to-many.

M5 - This milestone aimed to turn Amphora from a short-lived event to longer-lived infrastructure that the community could use. M5 required client teams to start a devnet that would not only run through the entire transition with all client combinations, but that would persist beyond the Amphora event.

Source

Pithos Testnet

Source Image

Pithos is the first public merge testnet on Ethereum and was launched on October 14th, 2021. Initially it had 3 consensus clients + geth and later Besu + Nethermind was added.

To achieve this M5 milestone of the Amphora Milestones, a network of 10,000 validators across 100 nodes launched on the top of proof-of-work (PoW) consensus, successfully transitioned to proof-of-stake (PoS) and finalized the chain.

Kintsugi Testnet

Image Source

Kintsugi is the Japanese art of repairing broken pottery by mending the areas of breakage with lacquer dusted or mixed with powdered gold, silver, or platinum. As a philosophy, it treats breakage and repair as part of the history of an object, rather than something to disguise.

The introduction of Kintsugi testnet facilitates Ethereum’s transition from a proof of work network to a proof of stake network, which will help reduce the network’s high energy consumption mining issues.

The Kintsugi merge testnet that was launched on 20th December, 2021 has been a valuable testing ground for The Merge.

In its early months, the Kintsugi testnet experienced major client bugs that resulted in the network forking twice. Soon after, the Kiln testing network was launched with improvements to re-test the post-merge environment. After the launch of the Kiln testnet, the Kintsugi network was officially deprecated.

Kiln Testnet


Image Source

The Kiln testnet is a testnet that simulates the integration of the Ethereum mainnet with the beacon chain and begins a complete transition from proof of work to proof of stake network consensus. Kiln's merge testnet is a development environment for developers, node validators, and stackers to experiment with application functionality in future upgrades to Ethereum's Proof of Stake consensus before the actual merge takes place.

The Kiln Testnet launched as a proof-of-work system and transitioned to proof-of-stake on March 15, 2022.

The public Kiln testnet at the day of writing has 110,000 active validators with 3.5 million ETH staked. The network has processed 1.3 million total transactions.

Kiln is the last merge testnet created before existing public testnets are upgraded. Application & tooling developers, node operators, infrastructure providers and stakers are strongly encouraged to test on Kiln to ensure a smooth transition on existing public testnets. See GitHub for Ethereum testnet configuration files.

Shadow Forking

It refers to using data from a testnet or the mainnet to test sync assumptions for a network upgrade so that developers can test features before deploying the actual upgrade to the mainnet.

A shadow fork is a test limited to a few weeks. Here, Developers fork an existing testnet, take its config, and add merge related fields such as Total Terminal Difficulty (TTD) and Merge Fork Block (for peering, forkID changes). Then, they have to spin up a new beacon chain for testing purposes. The new fork essentially inherits the state/transactions of the canonical testnet. Inheriting the state of existing testnets allows stressing test sync assumptions and assumptions around how long it takes to build a block/timeouts. The exciting part of staying connected to the peers on the canonical chain allows the team to import some of their transaction gossip as well.

  • It allows developers to see how nodes react when The Merge happens using only a small number of nodes without disrupting the canonical chain.
  • It gives developers a more realistic environment to test in than launching new testnets because existing testnets already have transactions happening organically on them and a large state size & block history, which put nodes under more stress than new testnets.
  • It possibly exposes bugs in clients and would suggest optimizations needed.
  • It helps developers test the realistic scenario and test Optimistic Sync on Consensus Layer and Snap Sync on the Execution Layer.
  • It helps developers increase their confidence that implementations work as expected.

Ref. Shadow Fork post for details.

Goerli Shadow Fork

So, firstly developers deployed a contract on Goerli with all the validators. Then, once the TTD, i.e., Total Terminal Difficulty, was hit, developers configured those nodes to follow the proof of stake chain after a specific block or after a particular total difficulty went on and merged, i.e., switched to Proof of Stake. Then, they tested The Merge on a real testnet by creating a fork:

  1. Developers deployed a genesis contract on Goerli and deposited enough validators to start a chain.
  2. It went through all the stages of the merge.
  3. Transactions from Goerli were also executed on the testnet, and the network was finalizing.

In the above Image, The top row of Goerli blocks shows a node on the canonical chain which are not aware of the shadow fork. The middle row of Goeli blocks shows a node on the shadow-forked chain, which has a modified configuration telling it to fork once the TTD is hit. Finally, the bottom row shows a Beacon Chain, which was launched for the shadow fork only. It will provide consensus to the chain when TTD is hit. After TTD is hit, the nodes on the canonical chain continue producing blocks, usually as if nothing has happened to them. After TTD is hit, nodes with the modified configuration fork off and run through The Merge. The next validator produces the first post-merge block in the Beacon Chain.

So this makes shadow forking a good technique as it gives us a way to test whether the fork works and the merging mechanism works without disturbing the public testnet. Here is a link to the Goerli Shadow Fork Testing Plan. This document aims to list various test cases that can be performed. The goal is to repeat this shadow fork process relatively often, allowing us to test the merge transition in multiple scenarios.

Here is quick overview of all GTSF & MSF happened till now

Mainnet Shadow Fork

S.No. Goals Issues
Mainnet Shadow Forking 1 MSF was done 1st time. Nethermind & Besu stopped at the transition, Nethermind Sync, Minor Bugs in Besu & Erigon
Mainnet Shadow Forking 2 This SF used every client's develop/unstable branch. Prysm & Nimbus Deposit Processing
Mainnet Shadow Forking 3 Devs purposefully made a few nodes fall out of sync to check how they resync Bugs in Prysm & Nethermind
Mainnet Shadow Forking 4 Better Testing & Preparation Couple of Client pairs creating Empty blocks
Mainnet Shadow Forking 5 Equal distribution of clients, i.e., equal client split on EL and CL Block Explorer Bug
Mainnet Shadow Forking 6 Testing out Edge Cases Besu-Erigon & Nimbus-Nethermind propose blocks woth 0 txns, Outof Sync in some clients
Mainnet Shadow Forking 7 To test fixes deployed on Ropsten & make sure that there were no regressions. There was also an equal client split for all validators. Erigon peering, Besu nodes had trouble with database corruption, Nethermind-Teku Deadlock
Mainnet Shadow Forking 8 To test a mix of forest/bonsai nodes for Besu and using static peers for Erigon. Erigon Syncing, Besu proposed blocks with 0 transactions
Mainnet Shadow Forking 9 Check More Test Cases Lighthouse nodes were falling out of sync, 4 of 5 nodes hit an invalid block in Besu, Erigon nodes did not sync in time
Mainnet Shadow Forking 10 For Better Preparation before Merge Some Besu nodes ran an older version, Lodestar-erigon were facing trouble fetching a block

Transition of Public Testnet Merge

Beacon chain is the PoS (Proof-of-Stake) version of the Ethereum blockchain. At present, it doesn't change much on Ethereum mainnet except the consensus mechanism. It has been running PoS successfully for over 18 months, giving confidence to Ethereum developers plan the Merge upgrade.

Ropsten - RBC

To handle the merge (a shift from Proof of Work mechanism to Proof of Stake consensus mechanism) of the Ropsten chain, Ethereum developers launched a Ropsten Beacon Chain (RBC). It was generally decided that Ropsten Beacon Chain to be unpermissioned but for devs to have the majority of validators.

Ropsten Merge:

Having tested client implementations on Kintsugi, Kiln and many shadow forks, client teams prepared themselves to run Ropsten, the oldest proof-of-work testnet – through The Merge.

Ropsten Testnet launched its beacon chain on 30th May and switched to Proof of Stake on June 8, 2022.

Genesis time - 1653922800
Genesis validator count - 100012

After years of work to bring proof-of-stake to Ethereum, developers tested the protocol upgrade on Ropsten, one of the longest running public testnet.

To know more about the Ropsten testnet Merge read our article here.

Sepolia - SBC

Sepolia Beacon Chain (SBC) had a minimal validator set, that is, it was restricted with a permissioned deposit contract. Therefore becoming a validator is permissioned. List of validator set participants was decided by the dev before the launch of the SBC chain.

Sepolia Beacon Chain genesis was launched on 20th June 2022 at 2pm UTC and gave client teams a week to setup their infrastructure.

SBC generated its own ERC-20 token to become a validator.

Merge TTD: 17000000000000000
Genesis Time: 1655733600 (Jun-20-2022 02:00:00 PM +UTC)
Genesis Validators Count: 1570

Sepolia after The Merge

After “The Merge”, Sepolia will be supported for a long term. Sepolia will not have a public validator set and the post-merge testnet will be limited to running applications on it. Sepolia is expected to be around for future protocol upgrades.

If you're an app developer looking for a stable testnet with support on multiple clients; Goerli will be a better testnet to test dapps. If you need to have conditions as close as possible to mainnet, but less stability than Goerli, choose Sepolia.

To know more about the Sepolia testnet Merge read our article here.

Goerli- Prater

Goerli is a PoA (Proof of Authority) testnet that was introduced by ChainSafe. PoA is a consensus mechanism that leverages the identities of validators, that is, the block validators are not staking their coins rather, they are staking their ”reputation”.

Goerli promises "safety, security and cross-client experimentation".

Prater is a beacon chain testnet that can be used to verify whether a setup is ready for deployment on Ethereum beacon chain mainnet. It also ensures that users can practice node operations such as adding and removing validators, migrations between clients etc.

Prater is a larger and longer-term Beaconchian (PoS) testnet which was launched in June 2021 and is a successor of Pyrmont testnet. The basic idea behind creating Prater is to make a testnet twice as large as the Mainnet so that we can push the limits of the client’s performance.

Georli testnet is planned to be merged with the Prater Proof-of-Stake beacon chain testnet. This will ensure the end of the permissioned PoA phase and everyone will be able to run as a validator for Goerli-Prater testnet, post merge.

Bellatrix, the Prater upgrade readying it for The Merge happened at epoch 112260.

After Bellatrix is activated, the Goerli/Prater merge happened when Goerli hit a total terminal difficulty (TTD) of 10790000 on August 11, 2022.

To know more about the Goerli-Prater Merge read our article here.

Others Testnets - Ganache CLI & GUI

Ganache is a local blockchain for rapid Ethereum and Corda application development. We can use Ganache across the entire development cycle, i.e., development, deployment, and testing DApps in a safe and secure environment. All versions of Ganache are available for Windows, Mac, and Linux. Ganache is available in two modes: GUI and CLI. Ganache GUI is a desktop application supporting both Ethereum and Corda. Ganache CLI is only available for Ethereum development.

Why use testnets?

  1. Developers Friendly: Since testnets are meant to use different technologies without allowing the main software to be interrupted, the coins connected to the testnet are independent entities from the actual cryptocurrencies. Therefore, this system helps application developers and testers use it with the benefit of not thinking of causing any modifications to the actual blockchain.

  2. High Research: Since blockchain technology is still currently in its development, a high amount of research and advancement is required to achieve mass acceptance and use. So having testnets is a boon, as the testnet demonstrates how the actual chain protocol will work in real-world conditions.

  3. No Drawbacks: It should now be clear that a testnet offers a forum for developers to use protocol functionality and functions without the fear of disrupting anything on the main blockchain. However, conducting these experiments on the main chain would undoubtedly be challenging since it could adversely affect the network and eventually bring massive damage to the actual blockchain.

  4. Completely Free: Testnets offer a stable experimental base for developers interested in developing network implementations or checking those functionalities without spending any real currency. As it would be extremely expensive for developers to test their application features or run experiments on the main blockchain network.

Note: The cover image of this report has been updated to fix typo.

Resources

Acknowledgement

This research report is a group effort by team including Yash Kamal Chaturvedi, Priyam Keshwa, Vishal Thyagrajan, Anjali Mishra, Divyanshu Gupta.

We would like to thank Moloch DAO for support.

Prev article
Ethereum Bulletin #57
Next article
Ethereum Bulletin #58
Share Tweet Send
0 Comments
Loading...

Related Articles

No results found
↑ ↓ Navigate up/down
Enter Go to article
/ Search new term
Esc Close search
You've successfully subscribed to EtherWorld.co
Great! Next, complete checkout for full access to EtherWorld.co
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.