Staking Hub: Coda Protocol AMA
On Sep 23, 2019, Evan Shapiro, Pranay Mohan, and Emre Tekisalp joined us to reveal the much-awaited staking mechanics for Coda Protocol.
- Mainnet target: Q1 2020
- Coda will not launch with smart contract functionality
- Likely no bond slashing; no unbonding (lockup) periods
- Uptime is key — delegators should select block producers based on uptime
- Coda will use off-chain governance
What we don’t know
- initial CODA token distribution unknown
- network inflation rate and parameters unknown
- unknown how governance decisions will be executed
What is Coda Protocol?
Coda Protocol will be a single, tiny blockchain-important for a couple of reasons. It won’t rely on sharding, which is complex and difficult to implement. Coda will also avoid the problem of state bloat-no ever-expanding blockchain, making it easy for anyone to sync and maintain a full node.
However, there are no immediate plans for smart contracts, so Coda will initially support only some compute features (TBA) in addition to standard transaction functionality.
How Coda began
The project began in mid 2017, according to Evan:
“Myself and Izaak (now our CTO) wanted to make a protocol that would be more decentralized and more scalable. Izaak was studying cryptography at Berkeley for a PhD at the time, and was learning about zkSNARKs.”
At some point they realized the connection between zk-SNARKs and decentralization. While existing protocols seemed to be redoing a lot of work downloading and verifying chains, they realized that SNARKs could break free from that tradeoff. How? Participants could simply verify a SNARK proof to instantly sync with the chain, enabling large block sizes and more nodes. These breakthroughs gave rise to Coda.
Full nodes for all 👐
Today, according to Emre, it’s difficult for the average end user to access Bitcoin without trusting a third party that runs a full node. Ethereum developers tend to use services like Infura or Alchemy for app development. O(1) Labs regards these as centralization points that 1) make the underlying blockchain less trustworthy and 2) create a bad user interface and developer experience. Coda should enable anyone to run a full node.
The team believes that Coda has a chance at succeeding where prior blockchains have not: as a payments use-case. They’re making Coda more accessible to developers-you can run a full node inside of a web app or an IoT device-so they hope to see many diverse use-cases.
What kind of network bandwidth can developers expect? Evan told us that that metric like transactions per block and block time will be tested in the next testnet. He predicts things to be pretty fast, since Coda should only be limited by network and local compute.
Coda Protocol’s token, CODA, is no different from the native token of other blockchains, in that it represents ownership of the network. The token will be used to pay for transactions, and new CODA will be minted to pay block producers for creating new blocks. This incentive mechanism will be critical for the various participants to co-ordinate and work together in a decentralized manner.
Besides being the network’s native token, CODAs may be used to transfer value, act as collateral, or anything that a digitally-native store of value is capable of. O(1) Labs envisions the token being used in novel, yet-to-be-imagined ways by applications built upon the protocol.
We don’t yet know what the initial distribution will look like (to be announced by the team), and the policy for inflation is still being determined. O(1) Labs is still considering a few different inflationary models that may tie Coda’s inflation rate to a staking participation rate. Check out our recent article to learn more about this general relationship, illustrated using Cosmos.
Though Ouroboros, the consensus mechanism they’ve selected, does not require slashing, O(1) Labs is still considering slashing for Coda. But that’s TBD: they’re hoping that future testnets will give them an indication of whether or not they’ll need to add slashing.
When staking with Ouroboros, you can come and go, so uptime can be thought of as being available to accept work, like with Uber or Lyft. When your block producer (validator) is down, you don’t work or get paid, and when you come back online, you’re back in the game.
However, being offline will discourage delegations. Anyone not producing blocks will likely be delegating, so they’ll want to select the most productive block producers. Delegator rewards will be distributed in a non-custodial manner and available to be withdrawn at any time. Similar to slashing, bonding may not be required. We’ll see in later testnets how that plays out, but Evan’s hopeful that bonding CODA tokens won’t be needed to stake.
Inflation will be used to fund block rewards for Coda’s block producers, as well as the delegators that back them. I’ll discuss snark workers (aka “snarkers”) later, but you should know that snarkers don’t participate in staking.
Block Producers (aka Validators)
Though current testnet block producers require 8 Gb RAM, 4-core processor, and 1 Mbps down, GPUs will have produce faster blocktimes. The Coda team’s goal is to have many consensus nodes, so they’re targeting common gaming GPUs, with no minimum or maximum stake.
Block production on Coda is intended to have a low barrier of entry so that anyone can run a staking node in their home with access to the same protocol incentives as those of a staking business. Want to try out consensus and staking? O(1) Labs has a staking testnet running right now, which is supposed to be super easy to get going.
The block producer, selected randomly by stake-weight, will receive the entirety of the block reward and transaction fees, for which delegators will receive a pro-rata portion (after commission fees have been deducted). There appears to be no incentive for one entity to run multiple block producers, beyond running infrastructure to assist with optimal block production.
Corrupt block producers will waste compute generating invalid blocks that will be rejected by the network. If the node gossips bad data to the network, a decrease in trust score can result in a temporary ban.
Deciding how to delegate
Coda is aiming to avoid slashing, so block producers and delegators may only need to focus on minimizing opportunity cost. You may only delegate to one block producer per address, so choose wisely.
I have the impression that in order to maximize staking returns, delegators should choose block producers with 1) maximum uptime and 2) latency that does not exceed the slot time window.
On the current testnet, slot time is six (6) minutes. But that’s slated to decrease, possibly to 30 seconds, thanks to the snark challenge and its winning solution. That reportedly sped up the Groth16 SNARK prover by 3.6x! The lower the slot time, the more compute power a block producer will need.
In order to participate, block producers will require snarks, which may be purchased from snark workers, or “snarkers.”
Snarkers (Snark Workers)
While a snark worker doesn’t directly participate in consensus, they are critical for moving the network forward. According to Pranay, a snark worker (or snarker) is a node that generates SNARKs for transactions. As mentioned, block producers must buy SNARKs from the snark workers (in what the team calls the “snarketplace”) before they can broadcast their block.
Snarkers will be permissionless and not required to stake, but at minimum they’ll require 8 Gb RAM, a 4-core processor, 1 Mbps down. In order to scale up operations, there’s an incentive to run more snarker nodes. In this case, Pranay suggested running a snark coordinator as a master node farming out requests to the child nodes. The performance of CPUs versus GPUs has yet to be seen, and snark work will be about speed and efficiency of production.
A trust system similar to block producers will also apply to snark workers-produce bad data, get a temporary ban. Snarkers must set a fair price in order to successfully sell SNARKs to block producers. I’m curious to know what happens if zero-fee snarkers show up and disrupt the market.
Changes to Coda’s network will initially involve on-network signalling for surfacing network consensus, followed by hard forks. We’re looking forward to learning more about O(1) Labs’ thoughts on governance, of which we weren’t in a position to learn details about in this AMA.
In terms of a potential Coda foundation, we also didn’t receive any specifics, only that the team is considering whether they will need a foundation for what they’re working to accomplish.
O(1) Labs has finished Phase 1 of the Coda testnet, and the staking challenge of Phase 2 has just begun. The goal of Phase 2 will be to test the durability of each network and the set of features that they initially tested in Phase 1.
The challenge in Phase 2 involves “testnet points,” which won’t have any monetary value, but a future phase may include an incentivized testnet (details yet to be announced). The team is targeting Q1 2020 for the Coda Protocol mainnet.
Looking for more ways to get involved?
Coda is open source, and O(1) Labs is just launching their grant program (which is still a work in progress). The team has a GraphQL API and plenty of work needed to be done. Take a look and dig in, and reach out to Pranay if you have an idea not covered. Join the Coda community on Discord, where I’ve found the team to be responsive and helpful.
Special thanks to Evan Shapiro, Pranay, and Emre for spending an hour with Staking Hub to answer our many questions, and to Claire Kart for helping to organize. Thank you to Andrew Cronk for co-hosting.
Thanks to our Staking Hub community for the thoughtful and impactful questions that inspired high-quality answers. Since you’ve read this far, you might as well join us over in the Staking Hub Telegram channel :)
Hopefully you found this useful. Feedback is always welcome! I’m on Twitter.
Originally published at https://figment.network.