LibraryConsensus2020Design paperCorpus record
Coda: Decentralized Cryptocurrency at Scale
Mina. Joseph Bonneau, Izaak Meckler, Vanishree Rao, Evan Shapiro.
The Coda paper, later the Mina protocol: a chain whose certificate is a constant-size succinct proof, so a client can check the state without replaying history. The project renamed from Coda to Mina. The paper keeps the original name.
Mina, described in the Coda paper, replaces a growing block history with a short zero-knowledge proof that the current state is the result of a valid chain. A phone is supposed to check the proof, not the history.
The five-minute read
The chain's size is the problem being named
A new Bitcoin or Ethereum node downloads years of blocks. Coda asks for a constant-size proof instead, so joining the network does not mean joining a data centre.
A recursive proof attests to the previous proof
Each new block includes a proof that there exists a previous valid proof and that this block follows the rules. The proof object stays small because it does not contain the history it talks about.
Pickles and the proving system matter
The paper's claim depends on a succinct proof system that can prove its own verifier. The cryptography is the product. A narrative about 'a tiny blockchain' without the proof system is empty.
Provers are a specialised role
Not every node produces the recursive proof. Block producers and snark workers split the work in the design that shipped. That split is a labour market inside the protocol.
State is small to verify, not small to use
A light client checks a proof quickly. A wallet that must know one account still needs a way to fetch that account and a witness. The paper compresses verification, not the world's data.
One action, walked through
- A producer builds a block of transactions against the current state.
- A worker produces a succinct proof that the state transition is valid and that it extends a previous proof of the same kind.
- The network gossips the new state, the block data needed to serve it, and the short proof.
- A new client downloads the proof and the current state root, and verifies them without replaying history.
- To learn one account, the client asks for a Merkle witness and checks it against the root it already trusts.
The argument, unpacked
Recursive verification is the entire shortcut
If the proof only said 'this block looks fine' and not 'the chain behind it was fine', a client would still need the past. Recursion is what folds the past in. An implementation that checkpoints every month and calls it Mina has changed the trust model back toward 'I trust the checkpoint'.
Prover concentration is the new mining
Whoever can produce proofs fastest earns the right to extend the chain in practice. The paper's egalitarian node is the verifier. The prover may be a specialist. Say so when you talk about participation.
A short proof does not make data available
The proof can be valid while the transaction data is hard to fetch. Users still need a data source for witnesses. The design pairs a cryptographic statement with a networking problem and only solves the first completely.
What has to be true
- The proof system is sound. A bug that accepts a false state transition is an undetectable inflation bug, because there is no history sitting beside it to audit by replay.
- There are producers willing to generate proofs at the block interval.
- Some party will serve Merkle witnesses. The protocol does not magically place an account in the client's pocket.
- The genesis parameters and any trusted setup the proving system required are the ones the client assumes.
What happened after the paper
Coda shipped as Mina. Prover marketplaces, pickles, and later upgrade work are the implementation history. The constant-size claim is about the proof a client verifies, and it remains the right sentence to test. It is not a claim that running an archive of all transactions is unnecessary for every service.
What to check before you use the idea
- What exactly is constant-size: the proof, the state, or the data a wallet must download?
- Who produces proofs, and what do they need to earn to bother?
- If the proof system failed, how would anyone notice without a replayable history?
- Where does a client get an account witness, and who can lie in that answer?
Terms
- Recursive proof
- A short proof that verifies a previous short proof, so a chain of validity collapses into one object.
- Succinct state
- A state a new client can check without replaying every prior block.
- Snark worker
- A specialised prover that produces the recursive proof the block needs.
- Witness
- The path that shows one account is inside the state root the proof already certified.
The problem the paper names
A new node that wants to know the current state of a normal chain downloads a growing history or trusts someone who did. The paper asks for a certificate that stays small even as the chain gets longer, and that a phone can check.
What the design proposes
- Each new block carries a succinct proof that there exists a valid history leading to this state.
- Provers do the heavy work. Verifiers check a small proof.
- The consensus story is about who is allowed to produce the next proof-carrying block, not about the proof system alone.
How the mechanism is specified
- A recursive composition of proofs is the reason the certificate does not grow with the block height.
- The proof attests to the transition function the paper defines. A different virtual machine is a different circuit.
- Pickles and later Mina engineering are implementations. The 2020 paper is the argument.
What this page does not treat as proven
- A small proof does not make block production cheap, and it does not remove the need to trust the circuit.
- The paper is not a statement about Mina's later token distribution or foundation.
- Clients who want historical queries still need data. Succinctness is about the current-state certificate.
Why a venture studio still reads it
When a venture says users should not run a node, ask what those users verify instead. Mina's paper is the strict version of that answer: a proof of the transition, not a branded API.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.