Coda’s Testnet Beta Phase 2 is concluded! Release 2.4 ‘Rising-Phoenix’ made a great, stable ending of Phase 2. At the time of writing, the block height reached almost 4000 and it was capable of handling the activity peaks during Magic Window hours, where testnet users were loading the network with transactions. ‘Rising-Phoenix’ will stay online, so everyone is welcome to continue to play around and test features.
What’s next? We will check all entries for the challenges and announce the winners on the Phase 2 Leaderboard soon. Stay tuned for the Phase 2 Overall Retrospective and sign up for the Testnet Newsletter to stay updated about the next exciting and fun plans!
Table of Contents
Retrospective Release 2.4
Community in Action
Release 2.4 Testnet Challenge Winners
Retrospective Release 2.4
“Problems are not stop signs, they are guidelines.” — Robert Schuller
We were very hopeful about testnet release 2.4 ‘Rising-Phoenix’ after finding the root causes and working around the issues that arose previously. And ‘Rising-Phoenix’ did not disappoint. At the time of this post, we’re at a chain of almost 4000 blocks with the majority of the stake in the community and out of the hands of O(1) Labs. The network proved to be much more stable and robust than the previous releases as it was capable to handle all the traffic during the large Magic Windows. Testnet users Niuniu | BitCat and Igor888 ran an oiled snark working machine in the 4th magic window (our largest window) collecting the majority of the 1000 CODA snark work fees earned and getting the 985 transactions from the testnet users through! Well done, everyone!
Although Testnet Beta Phase 2 has ended, we’re keeping ‘Rising-Phoenix’ up as long as we can in an attempt to catch any issues that may appear in a very late phase of the networks’ lifetime.
In Testnet release 2.4 ‘Rising-Phoenix’, we were heads down on testing new features, see below.
GUI Wallet: We shipped a new version of the GUI Wallet that supports staking and delegating — click here to learn more. Many testnet users tried it out and sent us a ton of valuable feedback. A big thanks to the community! We’ll be working hard to bake a new version soon.
Persistence: An enormous refactoring of multiple core components of our system enabled us to support the persistence of consensus data across restarts of the daemon, check it out on GitHub (along with a few smaller follow up PRs). We have a few small follow-ups related to ensuring data is not corrupted after non-graceful shutdowns, and then we’ll be good to go. Expect this in one of the next testnet releases.
Gossip over libp2p: For the past few weeks, we’ve been relying entirely on libp2p for our discovery layer, however, we were still gossiping around messages manually on top of that. With this update, we’ll be delegating out to libp2p for the gossiping as well. There are many advantages for this: (1) We can multiplex connections over the same socket, (2) gossip logic is handled by libp2p and the libp2p folks are working on sophisticated routing algorithms, and (3) this enables us to use the “bitswap protocol” in the future to transfer large files through libp2p.
While the testnet users were testing the new features, the team has also been working on an important fix of the bug that was uncovered in the previous release.
Fix — aligning the protocol logic with the SNARK logic: The testnet users uncovered an important bug in the previous release, 2.3. During that time, we faced a bug that halted the block production and killed the network. In retrospect, this was a great bug. It was caused by the SNARK verifying function and a change we made to associate a state hash (ie. block hash) with each transaction, and it proved that SNARKs do exactly what they are intended to do — catch improper updates during verification. We worked around the issue in release 2.4, but in the meantime, we added a fix to the SNARK circuit.
Let’s first take a step back to understand the root cause and the fix. There is a data structure that we track in the SNARK called the “pending coinbase”. It’s essentially a Merkle tree of coinbases that are pending to be SNARKed and corresponding state hashes in which these coinbases were generated. We initially implemented this without state hash tracking — when we added state hash tracking (in preparation for supporting more interesting kinds of transactions), we introduced an inconsistency in our logic inside and outside SNARK. Inside the SNARK it was correct, but outside the SNARK we were updating a part of the pending coinbase structure incorrectly in specific moments of transitions between “scan states”. A “scan state” is the data structure we use to keep track of all the transactions we still need to produce SNARK work for. We discovered it by pulling out the pending coinbase logic in and out of the SNARK and writing a quickcheck (property-based) test to attempt to find a counterexample in the statement “The output in and out of the snark is the same for all inputs.”. And we successfully found the counterexample! This counterexample is fixed and landed in our develop branch (see GitHub). This fix will be included in the build for the next testnet release.
Interested in all the other technical developments in the last weeks? Check them out here. If you want to learn more or have any questions, feel free to let us know! Our entire team is hanging out on Discord.
Community in Action
While the team was working hard on the protocol, the community has also not been standing still during release ‘Rising-Phoenix’. Garethtdavies continues updating and refining the CODA block explorer that he built.
CODA block explorer built by garethtdavies. He refined it by marking blocks (with a red circle) that were not included in the main chain.
Greg started to play around on the testnet and the CODA Graph Viewer. He exchanged testnet tokens with Kunkomu to see how the transactions would be visualized in the CODA Graph Viewer. We’re happy to see that Greg had fun exploring!
CODA Graph Viewer visualizing transactions and fees on the blockchain
Gordon Freeman was leading the effort to get the community organized in preparation for the Magic Window challenge. We didn’t reach the goal of 1080 transactions in the Magic Window, but we came close. It was a good attempt, Gordon! Let’s hope we can achieve it next time!
And we’re happy to see that new members are joining the testnet. Kunkomu invited Richorca over, who successfully connected to the testnet with the help of friendly testnet veterans, like pk.
Again, we want to express our heartfelt gratitude to the community members who are standing with us in this journey. Up to the next phase!
Release 2.4 Testnet Challenge Winners
Every release, we reward community members who are making testnet a great, collaborative experience. Please join us in congratulating the winners of release 2.4!
Challenge ‘Community MVPs’
GOLD 1000 pts* :
Gordon Freeman for initiating a collaboration with other community members. He reached out to other members to start a transaction circle together, in order to reach transactions target for the Magic Windows Challenge. We almost succeeded — it was a nice try!
SILVER 500 pts* :
Kunkomu for inviting his friend Richorca over, who successfully connected to the testnet!
Challenge Staking on ‘Rising Phoenix’
- 4000pts – Ilya | Genesis Lab* (created 88 blocks!)
- 3000 pts – niuniu | Bit Cat* (created 87 blocks)
- 2500 pts – novy* (created 86 blocks)
Challenge GUI Wallet Feedback
1000 pts – pk, whataday2day, niuniu|Bit Cat, Alexander, Star.LI*
Challenge ‘Bug Bounty’
1000 pts Major – Greg, Star.Li, Igor888, niuniu | Bit Cat*,
500 pts Minor – Viktor*
See GitHub for all submitted reports.
Check out the (full) leaderboard for all winners and earned testnet points*.
Our entire team is grateful for the community’s active participation in making the testnet a positive experience for everyone. We are working hard to iterate and work towards a robust succinct blockchain. Stay tuned for more exciting things in the public Testnet Beta and see you over on Discord!
*Testnet Points (abbreviated pts) are designed solely to track contributions to the Testnet and Testnet Points have no cash or other monetary value. Testnet Points are not transferable and are not redeemable or exchangeable for any cryptocurrency or digital assets. We may at any time amend or eliminate Testnet Points.
About Mina Protocol
Mina is the world’s lightest blockchain, powered by participants. Rather than apply brute computing force, Mina uses advanced cryptography and recursive zk-SNARKs to design an entire blockchain that is about 22kb, the size of a couple of tweets. It is the first layer-1 to enable efficient implementation and easy programmability of zero knowledge smart contracts (zkApps). With its unique privacy features and ability to connect to any website, Mina is building a private gateway between the real world and crypto—and the secure, democratic future we all deserve.
