Coda Protocol Code Review: Ultra Compressed Blockchain
Coda Protocol code review, wondering if their claims make any sense. Over here, look! The Ethereum blockchain, currently 667GB! And over here, Coda… which claims that a pinch of recursive composition of zk-SNARKs and some clever ideas can reduce the size of their chain into a “tiny snapshot”. Mass adoption anyone?
So, anyway. Coda is a new cryptocurrency with a constant size blockchain, improving scaling while maintaining decentralization and security. No need to store the entire blockchain for verification. Instant mobile syncing (or somewhat instant, let’s be serious for a moment here).
I first visited this project back in May, so I’m jumping back in, lots to look at, excited to see this work.
605 commits, 80 branches, 13 contributors. Working off of RFC’s it seems.
Good issue management, great documentation.
From the documentation, we have verifiers, and we have the longest chain rule.
Quite a lot to go through. From the last review, remember that snarky is the magic sauce. Think of snarky as the VM and everything here the code running on top of it. Not a great analogy but let’s go with it for now.
Not a fan of Ocaml.
Praos, their PoS Ouroboros implementation if I’m not mistaken.
Difficult for me to understand, I’m not fluent. But we see VRF creation based on time seeds, and we see state verification off of zero knowledge proofs. Need to dive in deeper here though, these are the high level functions.
Mini proof of work implementation as well. Probably for testing, but pretty cool.
Need more low level functions to really see what is happening here. High level it seems to validate the state transition with the snark transition. But without seeing the low level this is difficult to comprehend.
At this point, I can’t really assess the quality of this code. Instinctively it is good, organizational structure, layout, standard best practices are all good.
Let’s try another way. Let’s start from sending a payment.
Not familiar with these CLI libraries. But we create a Payment object. So let’s head over to Payment.
Not saying much, we just see type var and we see type Currency. over to Currency;
Checked, circuits for snarks. Fee, amount, balance, mostly just circuits and safe math.
Account structure, public key, balance, nonce, receipt_chain_hash.
Ledger transitions from snarks, transaction_snark? Transactions are snarkable? Is snarkable a real term?
Receipt_chain_hash. We give a receipt hash (the top merkle hash) that includes the transaction. That hash is proof that the transaction is in the system. Given the transactions, previous chain_hash, do I prove the current hash?
Need more data.
Now we are on the server side. The RPC receives the send_payment we created earlier. Let’s figure out where it goes.
Main -> Run -> send_payment (from RPC) -> schedule_payment -> into transaction pool.
prove_receipt grabs the proof payment, and checks against the receipt chain database.
Add Payment as txn into tx pool. Straight forward enough.
Proposer grabs tx from pool and adds into next proposal. Compress all transactions into a single snark?
Trying to understand ledger builder…
Conceptually, let’s look at it. send_payment, normal setup, circuits for currency transitions. Tx into tx pool, normal setup. Proposer, normal setup, agreement on block, normal setup.
Now you have a root receipt hash. You ask a node that has all the receipts, if the receipt is valid and contains the transaction.
So I’m still storing all the transactions and all the hashes? I’m missing a part of the picture, the zk inputs is where I’m getting stuck.
Coda Protocol Code Review Conclusion:
More research to do on my end, but phenomenal code. I’m not an Ocaml guy, but this made sense. This and snarky gives them a lot of power, and while I don’t see the single proof just yet, I see a very strong contender.
Great team, lots of hard (and smart) work has gone into this. I would like to see this in production. I think it is unique.
You can chat about Coda Protocol in our Telegram group.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
Coda Protocol Code Review Timestamp: November 17th 2018