Originally published on Medium.
You can consider Coda to be ‘A wallet that fits in your pocket’.
- The first cryptocurrency with a succinct blockchain.
- Blockchain compressed from 100s of GBs (as seen in existing protocols) down to kBs in size.
- Scalable, secure, and decentralized.
- Allows for verification of the blockchain on a mobile phone.
Coda’s blockchain always remains a constant size — the size of a few tweets, no matter how many transactions are conducted on the network.
In the ‘cryptosphere’, we’re often encouraged to follow the motto “Don’t trust, verify” and despite understanding the need to be an active network user, end users in blockchains today are less likely to run full nodes due to the perpetually increasing requirements to do so.
The growth rate of the Bitcoin blockchain in megabytes from ‘09-’18. (https://www.blockchain.com/en/charts/blocks-size?timespan=all)
Why can’t everyone be a full node? Before diving in, we should first establish an understanding of the basic setup of a typical cryptocurrency protocol — a processor, otherwise known as a miner or staker (PoW vs. PoS respectively), applies a transaction to the database. A full node then observes these transactions, to ensure they’re acting honestly. End users typically due no checking independently — instead, they delegate trust to willing network participants. Why is this?
- Resource requirements & complexity of running a full node discourages end users to do so.
- It is intensive to run a full node on a computer, impossible on a mobile phone.
- Easier to trust third parties to complete this validation.
In the early stages of any particular cryptocurrency, it’s relatively easy to operate a full node, as the blockchain is small — maybe a few megabytes. However, as time goes on and more transactions are recorded, this grows to hundreds of gigabytes (as seen in the chart above). In turn, making it less realistic to operate a full node without a computer designated for that purpose, much less on a smart phone.
How can we be convinced of the current state of the blockchain, without seeing the entire history of that state?
“Coda is a new cryptocurrency protocol which makes it possible for anyone to sync with the network [on any device] with full node level security while only downloading a few kilobytes of data and completing a few milliseconds of computation compared to gigabytes and gigabytes in traditional cryptocurrency protocols.”
O(1) Labs is developing the Coda Protocol to address the issue of blockchain size by creating the first succinct or compressed blockchain — the size of a few tweets. This provides end users with a low barrier to entry way of validating transactions.
What makes this possible?
- Utilization of zk-SNARKs — effectively compressing blocks into a single proof or certificate.
- End-users check this proof instead of checking the entire transaction history of a block.
- Recursive composition of these SNARKs/certificates— enabling a constant sized blockchain.
zk-SNARKs are an iteration of zero-knowledge proofs — a cryptography scheme where zero knowledge is relayed to a verifier when providing them with proof of a computation.
zk-SNARKs in Coda
At the core of the Coda Protocol, is the usage of zk-SNARKs which can be used to certify any computation.
zk-SNARKs function as unforgeable certificates to prove that a computation was performed correctly, without proving the entire computation. As mentioned, we can take any computation, such as verifying the transactions in a block, and create a SNARK out of it. This SNARK proves the accuracy of a block’s transaction history, without having to show all of the transactions. This effectively decreases the size of a block to a single SNARK (~1kB).
The SNARK verifies ALL of the rules for consensus.
- Transactions are signed.
- They are valid.
- Consensus rules (total hash power + chain strength for PoW, and the Variable Random Function/other rules for PoS).
If the SNARK isn’t honestly generated, it’s not valid. Anyone on the network would be able to see that near instantly on something as ‘lite’ as a Raspberry Pi or smartphone.
Maintaining a low resource requirement for verifying transactions in a block trustlessly is the first step to creating a sustainable & scalable solution to the problem at hand.
a SNARK processor creating a SNARK/certificate of validity for a block which could be passed on as a proof, without including all of the transactions.
A very real conversation between a Coda processor and an end user:
“Hi verifier/end user! I created a certificate so you can easily verify the transaction history of a block. This process required a lot of computing power, so I’m rewarded for doing this. You can verify the accuracy of this proof by checking the SNARK which will only take a few milliseconds and a few kilobytes of free space. This way, you won’t have to download hundreds of gigabytes to verify the blockchain!” — SNARK Processor.
“Thank you SO MUCH, processor. I will verify this certificate! Since it is so small I don’t have to trust someone else to verify the blockchain for me and I can finally run a validating node & wallet on something like my smartphone. Thank you! Life is so great now.” — End user.
Replacing each block with a SNARK isn’t a complete solution.
Initially, it was thought that we could simply create a SNARK for each block, shrinking each block to about a kilobyte, and call it day. However, this would still result in linear growth over time as SNARKs pile up, albeit to a much lesser degree than existing blockchains.
How can we fix this?
Well, we know that a SNARK can be used to certify any computation. Creating a SNARK is a computation in itself — so what if we created a SNARK of multiple SNARKs?
Multiple certificates/SNARKs, each verified by an end-user.
A Recursive Composition of SNARKs in Coda
As previously mentioned, we can chain these certificates together in a recursive composition and allow the blockchain to remain a constant size of ~20kB (SNARK + tail-end Merkle path).
Each time a new block is produced, a new SNARK/certificate is created. By creating a single SNARK comprised the previous certificates, you’re able to create a single “mega” SNARK in a sense, that proves the entire transaction history of the blockchain allowing you to jump from the genesis block to the current state while remaining the size of a single certificate.
Multiple certificates/SNARKs placed into a single certificate/SNARK.
To simplify this idea, let’s say you have:
- One certificate stating you can go from Block 0 to Block 2.
- An additional certificate stating you can go from Block 2 to Block 4.
You could then combine these SNARKs into one single SNARK which states you can go from Block 0 to Block 4.
The new SNARK/certificate remains ~1kB. On a greater scale, you can create a certificate for the entire transaction history of the blockchain which remains constant in size — despite the number of certificates ‘jammed’ into the most recent SNARK.
A validating node in Coda will comprise of:
A recursively composed zk-SNARK (1kB) which proves the validity the entire past history of the blockchain and merkle root path of the current state (20kB); together proving the validity of a user’s balance. All of which takes only milliseconds to sync up to.
End-user verifying a SNARK of the current state which includes all past certificates, as well as a merkle path. All of this comes together allowing a user to validate their balance.
The construction of the Coda protocol allows for the blockchain to be easily accessible to end users through your browser and in applications without downloading hundreds of gigabytes and without delegating trust.
Imagine an application such as a hyper-lite wallet where you aren’t required to trust that the developer is performing the verification process correctly. This validation process could be completed by the end users without requiring them to have hardware dedicated for this purpose.
Any device would be able to run a validating node, including but not limited to smartphones, in browser, or on feature phones (yes, your old indestructible Nokia).
As mentioned, end users in today’s existing cryptocurrency protocols end up delegating trust to services such as online wallets or light clients in the case of mining. This could become problematic in the event of something like a 51% attack as the duty of verifying transactions is often concentrated in the hands of these service providers.
By providing network participants with an easy way to host validating nodes, decentralization is augmented as transactions would be validated by a broader range of network participants — the end users.
In terms of enhancing scalability, increasing throughput to thousands of txns/sec in existing protocols would produce an increased amount of data needed for verification. You would inevitably end up with a blockchain that grows faster than it can be verified. However, since Coda keeps its blockchain at a constant size, you have a way of mitigating the data required to verify transactions which makes it possible to achieve a high throughput as the verification data is compressed by many orders of magnitude.
By creating a creating a blockchain which remains at a constant size, Coda enables end users with a low barrier to entry way to verify transactions on their own.
- No need to delegate trust to those willing to keep up with the requirements to operate a full node — as is the case in traditional blockchains.
- Obtain full node level security on virtually any device by downloading a single SNARK which acts as a certificate for the entire blockchain & a tail-end merkle path.
- Using a recursive composition of SNARKs, the blockchain size is able to remain ~20kB.
- Having a broad network of validating nodes increases decentralization as more end users are equipped to participate in network verification.
You can think of Coda as a blockchain compressed into a PokéBall. Instead of a cramming a Snorlax into a Pokéball, Coda compresses the blockchain into a SNARK.
From ZCon0 Presentation — Izaak Meckler — https://www.youtube.com/watch?v=qCVACpgQSjo