The History of Ethereum Testnets
A test network is an alternative blockchain that simulates the mainnet blockchain, created for the purpose of testing and experimenting to decrease errors in production like the loss of real funds. These blockchain testnets can be likened to a “staging environment” in traditional web development, where developers can test protocol upgrades and smart contracts before deploying to the main network.
Some test networks use the same underlying technologies and consensus mechanism as the main network, while some use different technologies and consensus mechanisms depending on how closely these networks mirror the main network. An important distinction to note is that the tokens obtained from test networks hold no economic value.
The Olympic Testnet – early 2015
The first-ever public Ethereum test network was called Olympic and was released before the official launch of the Ethereum mainnet. It was a Proof-of-Work test network and was intended to be the ninth and final test to be conducted before the official public release of the Ethereum main network.
Application developers, data providers, and exchanges were encouraged and incentivized to push the test network to its limit by sending high levels of load to stress-test the network.
The Olympic test network was referred to as Ethereum 0.9 and had a network ID of 0. It was discontinued in July 2015, after the successful public launch of the Ethereum main network.
The Morden Testnet – July 2015
Upon the launch of the Ethereum public main network, there was a need for a new public test network to go hand-in-hand with the mainnet. This lead to the development of the Morden test network, another Proof-of-Work testnet.
This network had a network ID of 2 and would remain the only Ethereum test network for over a year before being abandoned in November 2016, mostly due to accumulated junk and some testnet-only consensus issues between the two most dominant Ethereum clients – Geth and Parity.
Although the Morden network was discontinued by the Ethereum team, it remained active in the Ethereum Classic community and was renamed the Morden Classic test network.
The Ropsten Testnet – November 2016
Ropsten is the third and last Proof-of-Work test network for Ethereum, launched after a mainnet upgrade. This new test network was named after a subway station in Stockholm, Sweden.
The Ropsten test network supports all major Ethereum clients and is the only available test network that uses the Proof-of-Work consensus mechanism.
In February 2017, the Ropsten test network went through a major Denial of Service attack. 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 Kovan Testnet – March 2017
The February 2017 attack on the Ropsten test network led to the birth of several other test networks. The Kovan Testnet was created by the Parity team. Kovan, like other test networks launched after the attack, was borne from the need for a stable and client-compatible test network for developers to test their applications.
The Kovan test network uses the Proof-of-Authority consensus mechanism which sacrifices 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.
Because these validators’ identities are known, they are encouraged to uphold the network’s values as they do not wish to be attached to a negative reputation.
Like Ropsten, 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 not supported by some major Ethereum clients like Geth and does not fully reproduce the current production environment (Proof-of-Work mainnet).
Although the Kovan test network is a more stable and faster testing environment compared to the Ropsten test network since no CPU intensive mining is required to keep the network alive, it is still considered by many in the industry to be:
- An inelegant solution since Ethereum is supposed to have a dynamic block limit.
- Not portable since other clients need to implement new fork logic themselves and
- Incompatible with sync modes
The Kovan network is still active today and remains a favorite testnet for many teams across the community.
The Rinkeby Testnet – April 2017
Because the Kovan test network was spun up so quickly in response to the Ropsten attack, the Ethereum team created the Rinkeby test network as a longer term solution, which uses the Clique Proof-of-Authority consensus mechanism.
This network was also named after a subway station in Stockholm, has a network ID of 4, and a block time of 15 seconds.
The new Proof-of-Authority network is simple to implement and embed into any existing Ethereum client. It also allows the use of existing sync technologies like Fast, Light, and Warp without needing client developers to add custom logic to software.
It would maintain a list of trusted signers that changes over time by:
- First, repurposing the 32-byte “extra-data” field in block headers into a 65-byte field that would hold the secp256k1 miner signature, allowing anyone obtaining a block to verify it against a list of authorized signers. This means that the “miner” section of the block header would now be obsolete.
- Next, repurposing the newly obsolete “miner” field and the Proof-of-Authority obsoleted “nonce” field to create a voting protocol within regular blocks. Both of these fields are set to zero but if a signer wishes to enact a change to the list of the authorized signer, they would have to set the “miner” field to the signer they wish to vote about and set the “nonce” to 0 or ‘0xff…f” to vote in favor of adding or kicking out a signer.
Any client syncing the chain can tally votes during block processing, thus maintaining a dynamically changing list of authorized signers by popular vote.
Despite the Ethereum team’s efforts to create a standard Proof-of-Authority protocol, Rinkeby would only be supported by the Geth Ethereum client, leaving room for the creation of yet another test network that would be supported by all major clients.
The Gorli Testnet – 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 (primarily written in Rust) into Geth by rewriting it in GO (the language in which Geth is writing in).
It became an official project when Afri Scohedon came together with the Chainsafe team to create a “next-generation” PoA public test network that would be compatible with all major Ethereum clients including Geth, Parity, Hyperledger Besu, Nethermind e.t.c.
The early steps taken by the team included:
- Sufficiently specifying a Proof-of-Authority engine such as Aura or Clique in an Ethereum Improvement Proposal (EIP-225).
- Implementing one or multiple of these engines across different clients.
- Bootstrapping a new simplistic proof-of-authority test network based on the available implementation that mimics the main network’s conditions.
These steps led to the successful launch of the Gorli network in early 2019. It remains the only Proof-of-Authority network robust enough to guarantee consistent availability.
Final Thoughts on Testnet History
There are a number of Ethereum test networks available today, each attempting to solve a unique problem posed by their predecessors. Although this article only touched on the most popular and widely used test networks, there are a few other test networks with unique specifications available today like the Sokol test network.
One might ask which option is the best for testing applications before deploying to the mainnet. The answer is that there is no one “best option” as it really depends on what features the team is looking to test. And how closely they need the test network to resemble the main Ethereum network. Most software teams, as a part of their development process, choose and stick to one or more of these networks.