Introduction
This is a crucial update regarding the CASPER TestNet. Due to a recent consensus failure – specifically, three separate node clusters failing to agree on a single ledger state – the team has made the strategic decision to redeploy the TestNet.
CASPER TestNet 5.0 Redeployment
CASPET TestNet 5.0 will be redeployed sometime later this week. We will share the official redeployment announcement and a detailed guide shortly. The team will be available to offer technical support for specific, escalated cases that are NOT covered in the guide.
What Happened? A Root Cause Analysis
Now that the dust has settled, it is important to clearly summarize the issues encountered over the last week:
- RPC Endpoint Overload – Validators running multiple nodes from a single IP address triggered rate-limiting by RPC endpoints. This heavy traffic ultimately led to the halting of EVM block finalization.
- Uncoordinated Node Shutdowns – Following the initial issues, several validators suddenly turned off their nodes without initiating the required chilling process. This action significantly exacerbated the lack of consensus on the CASPER TestNet side.
The combined effect of these two factors resulted in the formation of multiple conflicting clusters, stopping both block production and finalization, and putting the CASPER TestNet ledger at a standstill.
CASPER TestNet 5.0 Improvements
The redeployment to CASPER TestNet 5.0 will implement key improvements for stability:
- Ledger State Source of Truth – All CASPER TestNet 4 state data will be saved and transferred to TestNet 5.0. To resolve discrepancies caused by bridging issues (which resulted in the loss of some TestNet funds), the EVM side $CSPR balances will be used as the ultimate source of truth for all accounts.
- Enhanced RPC Stability – We will increase the pool of available RPC endpoints. While this will help prevent validators from reaching the request threshold as quickly, it is not a final solution. Validators MUST still proactively monitor their own node activity.
- Future Validator Responsibilities – To ensure long-term stability, the community will be required to run EVM RPC endpoint nodes. For example, if ghostDAO is live on 10 EVM TestNets, each validator will be expected to run 10 corresponding EVM TestNet nodes or be subject to the public RPC endpoint node rate limits.
- Novel Bridge-In Architecture – improved user experience when bridging. The Bridge In architecture include both novel consensus mechanism as well as more controlled slashing mechanism to penalize irresponsible validators.
Conclusion
The addition of the ghostDAO to the GHOST stack introduces an extra layer of complexity. While CASPER TestNet is a fully in-house product, the EVMs are not, making diligence on the EVM side critical.
This is why I strongly urge EVERY Whale to read the essential Honest Validator Checklist published by Harpocrates.
Finally, let’s view what happened as a massive success! We successfully identified a significant attack vector and stability risk. It is infinitely better to discover and fix this on a TestNet with fake money than on the MainNet with real capital and consequences.
I will leave you with this perspective:
I haven’t failed. I’ve just discovered 1,000 ways that don’t work.
— Thomas Edison
