Testnet [Beta] Retrospective — Phase 3.2a

While the core team is working hard on launching a public testnet, more than 300 members participated in release 3.2a ‘Coda Sandbox’, which launched on Monday, April 20th. For two weeks, the users participated in challenges, racked up over 500,000 testnet points* together on the Testnet Leaderboard, and increased their chances to become eligible for the Genesis token program.

In release 3.2a, users used Docker to spin up a single-node private network on their machines, and became competent to carry out core Coda functionalities, like sending transactions, creating zk-SNARKs, and producing blocks. They also tested new features, such as the Graphical User Interface (GUI) Wallet, a Javascript Client SDK, decimal-ed tokens, etc. and provided the team with valuable feedback — read on for more details.

The ‘Coda Sandbox’ was a helpful stepping stone towards the next, interactive testnet release. If you’re ready for a more chaotic (and fun) experience, then sign up to join Genesis and get notified when the public testnet goes live next! Community members practicing to become node operators and block producers on Coda

Tables of Contents

Retrospective Release 3.2a

• Succinct blockchain: compute power and SNARK rewards
• Feedback on new features

Preparing for Public Testnet

Retrospective Release 3.2a

Succinct Blockchain: Compute Power and SNARK rewards

Coda swaps the traditional blockchain for a tiny cryptographic proof, enabling a cryptocurrency as accessible as any other app or website. This makes it dramatically easier to develop user friendly crypto apps that run natively in the browser, and enables more inclusive, sustainable consensus.

However, members who played with the ‘Coda Sandbox’ noticed that it had high CPU requirements. The reason is that creating zk-SNARK proofs and compressing the blockchain requires computing power. And since the sandbox node is the only node on a private network, it’s running 2 different SNARK proof creators at the same time: block production (the blockchain SNARK) and SNARK worker (the transaction SNARKs). Anyone running a node on a public testnet doing neither would actually only require minimal CPU (around 2 cores of CPU). And as SNARK constructions and proving systems improve over time, SNARK work is likely to become cheaper computationally, and more accessible in terms of what hardware can generate proofs at expected speeds. If a user decides to use their computing power to become a Snarker on the public network, they will receive SNARK fees as reward, see below image.

In the future, a special “non-consensus” node will be implemented that, while not participating directly in block production, verifies that the blockchain is secure without delegating any trust. This node will have such low CPU and memory requirements that it will even be able to run from JavaScript. Specifically, even mobile browsers on smartphones will be able to participate! Key roles on Coda and their incentives: the block producers and the snarkers. For more information, check out the economic whitepaper

Feedback on New Features

Based on the feedback that members submitted, here are some of the main takeaways from ‘Coda Sandbox’:

• Pending transactions — Improvements to user experience around pending transactions from the Command Line Interface (CLI) — We plan to address this in the following months, before mainnet launch. We understand that it would be handy if an user could look through the pending transactions.
• Scary log messages — There are several warning and error messages that happen at bootup in the sandbox container and this confused many folks as these actually are benign. On the other hand, if your node crashes, then the errors and warnings that occur close to the crash are useful to investigate. If your node hasn’t crashed, don’t worry about the errors in the logs. We plan to address these log messages before mainnet.
• User experience around account unlocking — We automatically lock accounts every time Coda daemon turns off and back on. This is done for security reasons, but we need to be clearer why this is happening. Private keys are encrypted when they are not in use. By not having to run the daemon inside the sandbox in the future, you’ll be turning on and off the daemon much less frequently.
• Documentation — This was the first release where we supported a flow through the Docker sandbox container and we didn’t get the chance to produce as much documentation as we would have liked before the release! For future releases, we will consider including a video and additional resources. If we utilize something like Docker in the future, we will also make it more clear that you need to set resources on your Docker daemon above the defaults to run a node successfully on many machines.
• Account creation fee — Many folks don’t realize that there is an account creation fee when sending a transaction to a new account for the first time. This is a technique we have in place to mitigate a potential attack where an adversary would choose to generate lots of accounts to fill up the ledger and make it so others cannot create accounts. It is especially important in networks that rely on zero-knowledge proofs (like we do with zk-SNARKs) because we need to fix the maximum size of the ledger (until a hardfork). Specifically, what happens is when you send a transaction to an account that doesn’t exist we take a small fee away. We received feedback that it is better to “opt-in” to this behavior by setting some special parameter of your transaction — we’re planning to work on adding that soon as well.
• Sandbox is a friendly environment to learn about Coda — A new member in the Coda community, gar, built a collection of scripts that wraps all sorts of different actions you may want to perform on Coda (delegating, importing keys staking, snarking, etc.). Check it out here! As Nightguy1688 says, we’re lucky that the Coda community is so passionately testing the protocol and working hard with the team to improve Coda together on the ‘play nets’!

We’ve also compiled feedback from forum discussions on Sandbox’s other features, such as the GUI Wallet, Javascript Client SDK, decimaled tokens, and the ability to send coinbase elsewhere.

• GUI Wallet — We received many great ideas and suggestions from our community on the GUI Wallet, which enables users to operate their node through a Graphical User Interface besides the Command Line Interface (CLI). Some of the community suggestions included moving more useful actions up and center, supporting multiple tokens (when that exists in Coda), and implementing better private key recovery mechanisms. Some modifications that occur directly via commands from the daemon do not trigger refreshes on the GUI Wallet (specifically: if you create a new account from the daemon directly). We have noted all of your valuable feedback for the future development of the wallet!
• Javascript Client SDK — Overall, those in our community who were developers were successful playing with the Client SDK. One community member, NarayanaSupramati, built a script to brute-force search for public keys with fun words or phrases in them! The biggest mistake in the SDK was a typo in some of the code examples, which was fixed here.
• New token format with decimals — There was a minor issue that we resolved early last week that was caused by an un-updated homebrew version. Otherwise no issues here!
• Sending coinbase elsewhere — This functionality mimics the ability to send your coinbase reward to a cold wallet in the future. We didn’t give easy pointers on how to do this, but many users figured it out! It’s great to see members like kromato4 (see below) explore the testnet docs and collaborating with each other on Coda’s Discord server.

Preparing for Public Testnet

Our original hope was to launch a public testnet around this time, but due to some persistent bugs related to the p2p networking, we postponed it. Our intention is to bring a testnet to our community that passed our internal testing with 200 nodes, and will give the node operators a good user experience.

Therefore, in parallel to launching the Coda sandbox, we also formally kicked off our internal task force on improving our velocity for root-causing and iterating on bugs and features. Our sub-group task force is devoted to getting the public testnet ready.

Recently, we successfully ran a 200-node network internally for 3 full epochs and are running with more network simulations, such as ‘chaos’, where we kill nodes randomly, to see how the network reacts. Stay tuned on the #task-force discord channel, as we’ll be following up with more details on all the projects we’re thinking about. If you’re interested in more juicy, technical details, feel free to participate in the discussions or contribute!

Keep your eyes peeled on the #reliability-engineering Discord channel for bleeding-edge information on how the internal testnets are going, and stay tuned for news. You can sign up here for the Genesis mailing list to get notified when the public testnet goes live!

As always, we want to give our heartfelt thanks to our community for being with us on this journey, their help in improving the protocol and continuing to build Coda’s community of users! Top 10 users in release 3.2a, see Testnet Leaderboard for the entire ranking

*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.