Testnet [Beta] Retrospective — Phase 2.3

Almost four months ago, Coda’s Testnet Beta Phase 1 was launched. Today, we’ve arrived at Testnet Release 2.4, named ‘Rising-Phoenix’. This release is the result of many testing and moments, where we saw our hopes diminish, rise again and reach higher peaks. Today, the testnet community is sending transactions, staking, producing blocks, producing zk-SNARKs and building tools on the first succinct blockchain using PoS Codaboros that we’ve been building for almost two years. We feel extremely grateful for where the project is today and we are excited to continue this journey towards the goal of enabling a truly decentralized succinct blockchain in a sustainable way.

If you like to be involved in the project early on, then we invite you to connect to the testnet and complete challenges for Testnet Points*.

Table of Contents

Release 2.4 Challenges

Retrospective Release 2.3 and Updates in 2.4

Release 2.3 Testnet Challenge Winners

Release 2.4 Challenges

Testnet Phase 2 will be concluded soon, so this will be one of the LAST opportunities to earn a spot on the Phase 2 leaderboard! Join the other testnet users and dive in by connecting to the testnet and completing challenges.

Release 2.4 features the familiar challenges of previous releases, but with more points* that you can earn by participating in the Magic Windows challenge.

Challenge: Magic Windows

[BONUS] A co-op challenge for the community: if the objective of sending and including at least1080 transactions in a block during a “Magic Window” hour is achieved, then everyone in release 2.4 will get double points* for points* scored during the Magic Windows.

There will be 4 one-hour windows in the week where node operators can do one of two things: 1. Send as many transactions as you can (measured as the # of transactions that made it into a block during the hour). 2. Win as many tokens from snark work as possible (measured as the total amount of coda earned through snark fees during the hour).

500 pts* per magic window — 1 transaction included in a block (during a window)

500 pts* per magic window — 5 coda in fees generated from SNARKs (during a window)

1000 pts* — for top 20 in most transactions included in a block, or most fees gained from selling SNARKs on the snarketplace (during a window)

The 4 one-hour windows are:

Thursday Nov. 14th, 9–10pm UTC-8

Saturday Nov. 16th 9–10am UTC-8

Tuesday Nov. 19th, 9–10pm UTC-8

Wednesday Nov. 20th, 9–10am UTC-8 Will you join pk, kunkomu and davidg during the Magic Window hours of release 2.4?

Other on-going challenges to earn testnet points*:

• Staking on Rising Phoenix for up to 4000 pts*
• Coda Stratego for up to 500 pts*
• Community MVP for up to 1000 pts*
• You Complete me for up to 1000 pts*
• Bug Bounties for up to 1000 pts*
• Introduction on Discord for 100 pts*

See here for all details on on-going challenges.

Retrospective Release 2.3 and Updates in 2.4

Thank you to all the node operators who patiently worked with us to debug the underlying issues from Release 2.3.

A quick recap — Release 2.3 started off stable, but after about 4 days of uptime, there was a period of slowed and halted block production that lasted several hours. The network recovered naturally by itself for a few hours and then stalled again. This time it stalled for an entire epoch that killed the network.

Why does an empty epoch kill the network? Well, in Ouroboros consensus, there is a strong assumption that no epoch will be empty. This is because each epoch’s activity is used to seed randomness for the VRF (verifiable random function) for the next epoch. This is then used to calculate the slots that block producers can win for the upcoming epoch. If there is no activity in the previous epoch, then the random seed is not actually random, since it could be computed ahead of time. Hence, the underlying assumption in the protocol breaks, and stalls the network.

So in order to first mitigate the bug from entirely bricking the network, we updated epoch times to 48 hours when we restarted the network for 2.3. This allayed the major concern, but we were still seeing oscillating periods where blocks wouldn’t be produced for hours at a time. We investigated the logs to see where the root cause was, and discovered that it was due to the SNARK verifying function. We dug deeper and discovered that the issue arose due to a change we made to associate a state hash (ie. block hash) with each transaction.

Basically, when a new block gets added, the protocol updates the current state to the new state. In order to do this, it takes the current state and the previous SNARK proof as inputs into an update function which ensures that the new state transition will update the state properly. This update function was correctly verifying inside the SNARK circuit but was incorrect outside of the SNARK. In order to mitigate this, we removed the check inside the SNARK, and are currently adding a fix to the SNARK circuit to verify properly.

What this taught us was that when updating protocol logic that changes the SNARK logic, we need to do more QA to ensure that the verification doesn’t break due to a mismatch. This was a great bug in retrospect because it shows that SNARKs do exactly what they are intended to do — catch improper updates during verification. However, the SNARK circuit must also match the update logic taking place in the protocol, and this discrepancy should never arise. We have adjusted our test suites and QA processes to catch any issues like this in the future.

Thanks again for the community for bearing with the instability — this was very useful for hardening the protocol. As always, onwards towards a strong mainnet candidate!

Release 2.2 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.3!

Challenge ‘Community MVPs’

We want to give a big shout out to the community members who helped out during the previous release. It was a busy period for our team and we truly appreciate the members for jumping in and helping others in the community.

GOLD 1000 pts* :

• @whataday2day for always being around and helping out other community members.
• @Dmitry D and @Gs for always being around and helping out with answering (testnet) questions from the Russian community.
• @Star.LI, @kunxian, and @niuniu for always being around and helping with questions in the Chinese community.

Challenge Staking on ‘Van Helsing’

1. 4000pts* – @Mikhail (created 60 blocks!)
2. 3000 pts* – @pk (created 52 blocks)
3. 2500 pts* – @Kunkomu (created 37 blocks)

Challenge ‘Bug Bounty’

See GitHub for all submitted reports.

1000 pts* Major — @bgibson (#3787), @crisF (#3788), @Greg (#3931)

500 pts* Minor — @lukeyoungblood (#3730), @victorxu0411 (#3756), @niuniu (#3785)

Check out the (full) leaderboard for all winners and earned testnet points*.

Once again, we want to put the block explorer built by garethtdavies in the community spotlight, since we still see members start using it and being excited about it!

Our entire team is grateful for the community’s active involvement in the project. 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.