Author: shew

Overview

As a public product donation fund, GCC is dedicated to advancing research on Ethereum infrastructure. Among the Ethereum infrastructure, the most commonly used and public aspect is the Ethereum testnet. The testnet is a testing environment similar to the Ethereum mainnet, providing crucial infrastructure that is consistent with the Ethereum mainnet. Since transactions on the testnet incur almost no fees, it benefits all developers, researchers, and users.

This report mainly introduces the history and current status of the testnet, and this research helps to understand the public attributes of the testnet more broadly, emphasizing how collaborative testing infrastructure supports innovation while maintaining accessibility for the entire community. By documenting the evolution and functionality of these networks, we aim to provide references for future testnet plans and demonstrate the value of community-supported infrastructure.

Public TestNet and DevNet

The Public TestNet is the most commonly used testnet by developers and users, where smart contracts can be deployed, and users can obtain ETH from faucets to interact with contracts on the testnet. The deployment timeline of the Public TestNet is as follows:

The latest Ethereum testnet plans are missing from the above diagram, and the latest testnet plans are as follows:

The naming of these testnets is quite interesting, as they are named after subway or train stations. Ropsten and Rinkeby are subway stations in Stockholm, Sweden, Goerli is a train station in Berlin, and Sepolia is a subway station in Athens, Greece. The latest Hoodi testnet is named after a train station in Bangalore, India.

In addition to the aforementioned public testnets, there are also a series of testnets within Ethereum for specialized testing, such as the YOLO testnet used for testing BLS signatures and other features required for the Berlin hard fork upgrade. We generally refer to these testnets as DevNet. They are sometimes also called Client Integration Testnets. These testnets are often not open to the public and are usually only accessible to client developers and auditors for relevant testing. These tests aim to verify whether different client implementations can function correctly and validate interoperability between different clients.

In All Core Devs Meeting 109, core developers discussed using geological fault lines as a naming convention for hard fork testnets. After establishing this principle, core developers launched the Aleut (representing the Aleutian Trench) and Baikal (representing Lake Baikal) testnets for testing the London upgrade. However, subsequent testnet naming did not adhere to this rule; for example, another testnet for testing the London upgrade after the Baikal testnet was named the Calaveras testnet. Nevertheless, core developers did not consistently follow this naming convention, as the latest Fusaka hard fork upgrade opted for simple and clear naming like devnet-1 / devnet-2.

History of Public TestNet

Pioneering Era: Olympic and Morden

The Olympic testnet emerged in early 2015 as Ethereum's first public testing platform. This groundbreaking network was even launched before the official launch of the Ethereum mainnet, serving as the final validation of the protocol's functionality. The chain ID of this chain is 0, indicating its pioneering status.

The Ethereum development team established a bounty system, where anyone who successfully stress-tested the network and created a large number of forks would receive a reward of 25,000 ETH, aimed at testing Ethereum's limits through high transaction volumes and extreme usage patterns. The following diagram shows the airdrop situation for testnet participants after the Olympic testnet activity ended.

The Olympic testnet played a significant role in early Ethereum development, to the extent that the genesis block of the Ethereum mainnet used block 1028201 from the Olympic testnet as a template. However, this testnet also had many issues, including an excessively large state set and potential private key vulnerabilities, leading to its abandonment after the successful launch of the Ethereum mainnet in July 2015. The excessively large state set issue was due to the Olympic testnet essentially incentivizing the initiation of spam transactions, as users sent a large number of spam transactions to obtain rewards, resulting in the Olympic testnet becoming massive. The potential private key vulnerability issue was mainly due to early code vulnerabilities in the Olympic testnet, which could lead to replay attacks.

The Morden testnet quickly launched after the retirement of Olympic and went live in July 2015 alongside the Ethereum mainnet. Since the chain ID of the Ethereum mainnet is 1, the Morden testnet chose 2 as its chain ID. Morden served as the only testing environment for more than a year after its launch, establishing its position as the primary development platform for early Ethereum applications. However, the network experienced severe consensus issues. To avoid potential replay attacks when Morden was initially created, all transaction nonce values within Morden started at 2^20. However, EIP-161 modified some rules regarding nonce, leading to a conflict between Morden's original nonce rules and the nonce rules specified in EIP-161, ultimately resulting in Geth and Parity creating incompatible blocks at block 1885074. This directly led to the abandonment of the Morden testnet.

It is worth mentioning that the ETC community adopted this abandoned network, renaming it "Morden Classic" and continuing to operate it within its ecosystem. However, in 2019, the ETC community replaced the Morden Classic testnet with the Mordor testnet as its latest testing network.

Ropsten Era and Security Challenges

Ropsten emerged in November 2016 as the third iteration of the Ethereum testnet, named after a subway station in Stockholm, with a chain ID of 3. This proof-of-work network was designed to be more robust than its predecessors and successfully supported all major Ethereum clients, making it a pillar of Ethereum's testing infrastructure.

The most interesting moment for Ropsten occurred in February 2017 when it suffered a devastating denial-of-service attack. Malicious attackers exploited the network's PoW mechanism, gradually increasing the block gas limit from a reasonable 4.7 million to an astronomical 9 billion. This attack generated a large number of spam blocks, consuming significant disk space and making client synchronization nearly impossible, leading to etherscan being unable to display data properly.

However, the Ethereum community could not simply abandon the Ropsten testnet. With the support of GPU computing power donated by the community, the Ropsten team successfully restored the network in March 2017, clearing the accumulated spam blocks and returning to normal operation. The recovery process was straightforward; Ethereum developers used the community-donated GPU computing power to mine blocks at the point before the attack, creating a heavier chain that replaced the original attacked chain. We can simply think of it as Ethereum developers successfully executing a 51% attack to alter the chain's history to achieve the goal of clearing spam transactions.

This incident became a watershed moment in the network's development, prompting the development of alternative consensus mechanisms and more robust testing environments. On June 8, 2022, Ropsten became the first major testnet to successfully complete the Merge, marking the successful evolution of Ethereum's testnet from proof-of-work (PoW) to proof-of-stake (PoS).

There were also some issues during Ropsten's Merge. In simple terms, Ropsten was expected to initiate the Merge process when the block difficulty value reached 43531756765713534, a value known as TTD (Terminal Total Difficulty). However, Ropsten's TTD was reached prematurely due to malicious attacks, at which point the Beacon chain used for consensus in PoS had not yet been launched. To prevent further issues, core developers requested that Ropsten's nodes manually set the TTD to 100000000000000000000000 and then wait for further modifications from core developers. The process of this event can be read in the Ropsten TTD Postmortem and Ropsten testnet Merge. The final result was that Ethereum core developers resolved the TTD issue, and Ropsten ultimately completed the Merge process.

Proof of Authority (PoA) Revolution

The Ropsten attack in February 2017 spurred the development of Proof of Authority (PoA) testnets, starting with the Kovan testnet in March 2017. Kovan was created by the Parity team and represented a fundamental shift in the concept of testnets, sacrificing pure decentralization for security and stability. The network is named after a subway station in Singapore, uses 42 as its chain ID, and maintains a block time of 4 seconds.

Specifically, Kovan used the Aura algorithm, which is very simple; the algorithm defines multiple trusted block producers that can produce blocks and rotates them based on time, with only one block producer producing blocks during each time period. Clearly, under the PoA algorithm, attackers cannot arbitrarily initiate DDoS attacks, as PoA block producers may directly refuse any transactions from attackers in extreme cases.

Despite Kovan's innovations, it still had limitations in client support, being compatible only with Parity and not with the broader Ethereum client ecosystem. This limitation meant that developers using other clients like Geth could not fully utilize Kovan for testing, leading to fragmentation of the testing environment.

Rinkeby was launched in April 2017 in response to the Ethereum team's demand for a more general PoA solution. Rinkeby is named after another subway station in Stockholm and implements the Clique Proof of Authority (PoA) consensus engine, designed to minimize interference with existing client codebases. Rinkeby has a chain ID of 4 and a block time of 15 seconds, providing a stable testing environment that facilitates easier implementation across different Ethereum clients.

Due to the Clique consensus being a general solution, Ethereum developers specifically described the consensus algorithm in EIP-225. This consensus algorithm reuses existing block header fields and introduces an innovative governance mechanism. The extra-data field has been expanded to accommodate secp256k1 signatures, while the miner and nonce fields have been transformed into a voting protocol for managing the list of authorized block producers. This elegant solution allows for dynamic validator management through a public vote while maintaining compatibility with existing technologies.

Rinkeby achieved exceptional stability, processing approximately 164 million transactions over its operational period, covering 11 million blocks. The final outcome for the Rinkeby chain was that the Rinkeby maintenance team decided not to migrate Rinkeby through the Merge, with specific reasons referenced in that tweet. In simple terms, Rinkeby was primarily maintained by Geth developers, and the network had accumulated a large amount of data over its long runtime, making the Merge difficult to execute.

Multi-Client Breakthrough: Goerli

Goerli originated from the ETHBerlin hackathon in September 2018. At that time, the ChainSafe team launched an interesting project aimed at implementing Parity's Aura Proof of Authority (PoA) consensus mechanism in the Go programming language to achieve compatibility with Geth. When Afri Schoedon collaborated with ChainSafe to create their envisioned "next-generation" public PoA testnet, this project gradually evolved into a formal plan.

The core goal of Goerli was to support multiple clients. To achieve this, the development team first attempted to implement the Aura algorithm designed by Parity within Geth. At the ETHBerlin hackathon, the development team achieved this goal but found it too invasive to the existing codebase. Ultimately, the Goerli team chose the Clique consensus engine to meet the goal of multi-client compatibility, which had already proven its value in the Rinkeby testnet, but the Goerli development team wrote extensive code to ensure that all major Ethereum clients supported this consensus protocol.

Goerli officially launched on January 31, 2019, with a chain ID of 5 and a block time of 15 seconds. The network achieved significant success in client diversity, supporting mainstream platforms such as Geth, Parity, and Nethermind. This broad compatibility made Goerli the first truly universal PoA testnet, addressing the fragmentation issues that plagued early networks.

The stability and reliability of the network made it the preferred choice for application developers, infrastructure providers, and protocol researchers. As Ethereum prepared for the Merge, Goerli was selected to merge with the Prater beacon chain testnet on August 11, 2022, successfully transitioning from PoA consensus to PoS consensus.

The most severe issue with Goerli was the limited supply of ETH within the network, which led to significant ETH supply problems towards the end of Goerli's life. Most developers and users working on Goerli had to obtain test tokens from multiple faucets and even had to pay funds to purchase test tokens.

Modern Testnets: Sepolia / Holešky and Hoodi

Sepolia is also a PoA testnet, primarily maintained by ETHPandaOps. ETHPandaOps is a team focused on monitoring and optimizing Ethereum infrastructure, currently serving as the core maintenance team for Ethereum infrastructure, providing capabilities in the following areas:

1. Network monitoring tools that provide data on the operational status, performance, and behavior of the Ethereum network. The team also maintains a dataset called Xatu regarding Ethereum network performance.
2. Testing tools primarily serving Ethereum core developers, helping them quickly build DevNets containing multiple different clients to test whether certain EIPs are correctly implemented in node software, with the representative tool being ethereum-package.
3. Other tools. For example, ETHPandaOps also developed the Funding-vault for testnet token distribution and the Snapshotter for node snapshots.

As a PoA testnet, Sepolia cannot conduct complete PoS layer testing, so this testnet focuses on execution layer testing. In simple terms, this testnet is designed for smart contract engineers and users. Compared to the Goerli testnet, Sepolia's biggest advantage is that the supply of test ETH within this testnet is unlimited, allowing developers to easily obtain test tokens from faucets.

In contrast to Sepolia, both Holešky and Hoodi are public testnets that focus on protocol layer testing. Protocol layer testing mainly refers to testing functionalities related to PoS, such as whether ETH stakers can exit normally. Holešky was once the preferred testnet for protocol layer testing, but during the Pectra upgrade, this testnet suffered severe damage. In simple terms, the Holešky testnet was misconfigured during the Pectra upgrade, causing three types of node clients to be unable to participate in consensus properly. Due to the consensus issues, a large number of stakers were penalized, leading to an extremely congested PoS staking exit queue. Ethereum core developers introduced a series of recovery plans, updated client software, and accompanied by about two weeks of large-scale penalties, many erroneous nodes were penalized to the point of losing all funds and could no longer participate in PoS consensus. After the correct node software and erroneous stakers were removed, the Holešky testnet eventually returned to normal.

However, the events surrounding the Holešky testnet led to its inability to participate normally in other tests of the Pectra upgrade by the end of February 2025. The significant impacts included:

• Due to previous consensus issues, the state of the Holešky testnet was quite chaotic, requiring test participants to deal with some consensus problems caused by prior misconfigurations, further increasing testing difficulty.
• Due to a large number of stakers being penalized and exiting, the exit queue became exceptionally large, making it difficult for testers to test staking exits. Staking exits were within the scope of the Pectra upgrade.

To avoid affecting the normal launch of the Pectra upgrade, ETHPandaOps launched the Hoodi testnet. Essentially, the responsibilities of the Hoodi testnet are consistent with those of the Holešky testnet, both aimed at verifying whether PoS and other protocol layers can function normally, but the Hoodi testnet is cleaner compared to the Holešky testnet.

Therefore, for smart contract engineers, using the Sepolia testnet for related testing is the optimal choice, while for protocol layer testing, using the Hoodi testnet is the best option, and the Holešky testnet is essentially in a state of abandonment. Recently, ETHPandaOps aimed to verify the impact of a 60M block gas limit on Ethereum, only using the Sepolia testnet and the Hoodi testnet.

Value Orientation of Bitcoin Testnet

In the above text, we introduced the foundational history of the Ethereum testnet. Each transition of the Ethereum testnet was due to some technical reasons. The transition from Olympic to Morden was because Olympic contained too many spam transactions; the transition from Morden to Ropsten was due to consensus split issues in Morden; the transition from Ropsten to Rinkeby was because Ropsten, as a public testnet, was vulnerable to denial-of-service attacks; the transition from Rinkeby to Goerli was because Ropsten completed its historical mission after the Merge upgrade, and the large amount of data accumulated by Ropsten was unsuitable for further operation; the transition from Goerli to Sepolia testnet was due to the ETH supply issues in Goerli and the operational cycle of Goerli.

In contrast, the replacements of the BTC testnet are quite "violent" in nature. Historically, BTC has had four major testnets, directly named Testnet1 / Testnet2, etc. It is quite difficult to find relevant history for Testnet1 and Testnet2, but there are many interesting factors regarding the updates between Testnet3 and Testnet4.

Testnet3 was introduced with Bitcoin core v0.7, primarily addressing the issues of high difficulty and long transaction confirmation times in Testnet2. However, there were problems with the related code of Testnet3, which can be detailed in the article "Bitcoin Testnet Block Storms" published by Lopp in April 2024. In simple terms, Testnet3 had a vulnerability that could lead to block difficulty resets, as shown in the following diagram:

We can see that the difficulty of the Testnet3 fluctuates greatly, occasionally experiencing a drop in difficulty by seven orders of magnitude due to block difficulty resets. When such an abnormal drop in difficulty occurs, theoretically, miners on Testnet3 could use ASIC miners or GPU programs to mine a large number of blocks in a short time.

In April 2024, Lopp published a new article titled "Griefing Bitcoin's Testnet." This article described how Lopp executed a fatal attack on Testnet3 using the previously discovered vulnerability, and in the article, Lopp also expressed his intentions, specifically:

1. Testnet3 should be abandoned.
2. BTC within the testnet network should have no value.

Of course, the direct cause of Lopp's attack on Testnet3 was the SatoshiVM project, which aims to build zk rollups on Bitcoin and seeks broad user participation for testing. Clearly, these users need to obtain testnet BTC as gas, etc. This led to BTC on Testnet3 starting to be sold.

Lopp believes that BTC on the testnet should have no value, and any developer should be able to obtain testnet BTC for free, with testnet BTC only being used for development purposes. The SatoshiVM project clearly does not align with Lopp's values. To express his dissatisfaction and to push for an update to the Bitcoin testnet, Lopp initiated an attack by mining a large number of Testnet3 blocks.

As seen in the above image, after Lopp began mining, the number of blocks on Testnet3 increased by 300% daily. After this operation started, Lopp observed some protests regarding the sale of testnet tokens and the Motoswap project. Upon investigation, Lopp found that Motoswap was operated by the BSV community. Lopp was not satisfied with the statements from these users, so he intensified his mining of Testnet3 blocks, achieving the terrifying block production speed shown in the following image:

This meant that Testnet3 was producing blocks at a speed 150 to 200 times faster than before, which dealt a significant blow to the infrastructure that relied on Testnet3. For example, the well-known BTC sidechain project Stack found that its Stack testnet, which depended on Testnet3, could not operate normally after Lopp began his attack. In the article "The Challenges of Building on Bitcoin Testnet," Stack stated that engineers spent a lot of time modifying the current testnet code to keep the Stack testnet operational on Testnet3, but still could not make it work properly. Ultimately, Stack decided to abandon the testnet on Testnet3 and use the sovereign testnet Bitcoin Regtest, which the Stack team could maintain.

Lopp wrote in his article:

Suffice to say that it’s a very bad idea to use testnet for anything of real value. Testnet is not secure, and I’m happy to prove it to folks who refuse to believe it. I’ll reiterate: I don’t care if folks are using testnet to test out controversial things like inscriptions / runes / ordinals / exchanges / etc. But if you’re going to do those things for actual value, you’re far better off using something like Dogecoin or Litecoin. You know, a production network that isn’t intentionally hobbled.

In simple terms, the fundamental reason for Lopp's attack on Testnet3 was the emergence of value for BTC within Testnet3. Of course, as a developer of Bitcoin Core, Lopp also stated that the attack on Testnet3 was conducted using only his own GPU and nodes deployed locally. Additionally, Lopp mentioned that the code for Testnet4 was gradually being completed.

At the end of the article, Lopp expressed that the only way to avoid the accumulation of value for testnet tokens might be to promote a culture of regular resets. Ideally, the testnet would be reset regularly, which would reduce the state occupied by the testnet and prevent the accumulation of value for BTC within the testnet. From this perspective, Ethereum has proactively planned the lifecycle of each testnet, and waiting for the lifecycle of a testnet to expire and be automatically discarded is a forward-thinking and effective design.

Ultimately, with the release of Bitcoin Core version 28.0 in October 2024, core developers added support for Testnet4.

Similar to Ethereum, BTC also has some other types of testnets. In addition to the public testnets supported by Bitcoin Core, such as Testnet3 and Testnet4 mentioned above, Bitcoin also has the following types of testnets:

1. Bitcoin Regtest is also a testnet provided by Bitcoin Core, but this testnet is a local testnet where the owner can directly generate blocks using RPC, etc.
2. Bitcoin Signet is a hybrid testnet that is public but requires blocks to have specific signatures, similar to PoA. All blocks can only be recognized with the administrator's approval.

As mentioned earlier, the upgrades to the Bitcoin testnet can be seen as "violent" from a certain perspective. Lopp used the most extreme method of mining Testnet3 blocks to push for the upgrade of the Bitcoin testnet and expressed his personal intentions.

If a similar issue to Testnet3 were to arise in Ethereum, the Ethereum core developers would likely invite stakeholders to resolve it through communication in core developer meetings. From one perspective, this approach is more elegant and does not affect the execution of testing projects within the testnet, but from another perspective, this method may not be very decentralized. Lopp's direct attack on Testnet3, however, expressed his personal intentions in the most decentralized manner, and the accompanying damage can only be seen as a transitional pain.

Public Goods and Isolation Theory

Both the Ethereum and Bitcoin testnets are considered public goods. In this section, we briefly discuss the economic properties of public goods and provide an economic explanation for some behaviors within the testnet. First, we need to define the nature of public goods, which refers to goods that can be shared by multiple people without interfering with others' enjoyment. The definition of public goods is simple, but identifying which products are public goods requires a specific perspective. Public goods often have both public and private attributes. For example, NFTs can be appreciated for their artistic value by everyone, and one user's appreciation does not affect another user's appreciation. From this perspective, NFTs can actually be seen as public goods, but the ownership of NFTs belongs to a specific on-chain address, which means that from this angle, NFTs are not public goods.

Why are public goods often not charged externally? The answer to this question may not align with common perceptions. Taking the Ethereum testnet as an example, the value it brings to Alice may be 10, while the value it brings to Bob may be 1. As a public good, the Ethereum testnet can be shared by both Alice and Bob. Therefore, if the Ethereum testnet does not charge any fees, Alice gains a benefit of 10 while Bob gains a benefit of 1, resulting in a total benefit of 11 for both. However, if the testnet charges a fee of 2, Bob, whose value from the testnet is less than the fee, would choose to forgo using the testnet, resulting in a total benefit of only 10 for Alice. In this simple case, we observe that once a fee is imposed on the testnet, individuals who could have enjoyed the public good withdraw, leading to a decrease in overall benefits.

One possible solution is price discrimination, charging Alice a fee of $10 while charging Bob a fee of $1. However, within a large-scale network, we would need to incur high costs to implement different fees for different users. Therefore, to achieve economic optimality, public goods can only choose not to charge fees. Thus, public goods are not inherently free; they are simply free because achieving global economic efficiency would require high costs for differential pricing. The core issue here is the cost of implementing price discrimination for public goods; if the cost is low enough, public goods can be priced.

Regarding how to charge fees externally while maintaining the public nature of public goods, the concept of isolation theory exists in economics. Isolation refers to incurring certain costs to separate a portion of public good users from other users and charging fees to this isolated group. First, for users who are not isolated, the public good remains free to enjoy, while for isolated users, they need to pay for the public good. Note that this payment does not necessarily mean direct monetary costs; it could also involve indirect costs such as time.

Taking the testnet as an example, the Ethereum testnet has implemented isolation operations. Ordinary users can obtain test tokens from public faucets. However, for users who need to consume a large number of test tokens, the Ethereum testnet isolates these users, requiring them to incur additional costs to obtain a large number of test tokens at once. Currently, the way to obtain a large number of test tokens in Ethereum is through the Funding Vault. This is a repository maintained by ETHPandaOps, where any user wishing to obtain a large number of test tokens for project testing can provide a series of materials to prove their need for a large number of test tokens and then directly obtain tokens from ETHPandaOps.

The BTC testnet series also employs isolation methods. For small amounts of test BTC, users can obtain them directly from public faucets, but for users with a high demand for test tokens, the testnet isolates these users. These users can only obtain a larger amount of test tokens by running testnet network nodes and spending resources to mine.

We can see that providers of public goods may consciously or unconsciously use isolation theory to achieve reasonable use of public goods. Although isolation theory sometimes appears under the guise of "preventing the abuse of public goods," it essentially establishes its own isolation. Of course, which users to isolate and which methods to use for isolation reflect the values of different testnets. Currently, both the BTC testnet and the Ethereum testnet generally agree on the principle that test tokens should not have value.

Conclusion

This article summarized the historical changes of all public testnets in Ethereum and introduced the dramatic events surrounding Testnet3 of the BTC testnet. At the end of the article, we discussed the economic issues of public goods, specifically that the fundamental reason public goods do not charge external fees is that any external charging would impact overall social benefits, and finally introduced the concept of isolation theory.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。