Making Neptune Cash Verifiable from One Block

Embedded in the phrase "don't trust, verify" is the implicit promise "because you don't have to trust". Every blockchain makes this same promise: you do not have to trust anyone. Not a bank, not a company, not the developers. You might have to trust maths and hardware. But you should never be required to trust people.

In practice though, keeping that promise is expensive. To verify Bitcoin from scratch, you download over 600 gigabytes of history and replay every transaction ever made since it began in 2009. That takes days on good hardware and is out of the question on a phone. Consequently, most people do not do that, and instead use a wallet that asks someone else's server for their balance, and they trust the answer. The promise of "you don't have to trust anyone" quietly becomes "trust, because verifying is too expensive".

Neptune Cash was designed from day one to fix this problem. The property is called succinct validation, or succinctness for short. Once it is activated, you will be able to verify the entire history of the chain in a matter of seconds by downloading and checking one block. This article explains what that means (and what it does not mean), why it matters, and how it will be switched on.

Succinct Validation

The Problem with Replaying History

When a new participant joins the blockchain network, they face two questions about whatever chain their peers show them:

Is it valid? That is, did every block follow the rules: no coins created out of thin air, no coins spent twice, no coins spent without their owners' assent?
Is it canonical? If peers show different chains, which one is the real one? In proof-of-work blockchains the answer is the chain with the most accumulated work behind it.

On a conventional blockchain, the only way to answer the first question is to check every block, one after another, from the very first (the genesis block) to the latest. The cost of joining the network grows with every block ever mined. The older and more popular the chain, the more expensive it becomes to verify -- exactly the wrong way round for a system whose security depends on many independent verifiers.

Proofs Instead of Replays

Neptune Cash takes a different route, built on a branch of cryptography called interactive proof systems, or more precisely zk-STARKs. A STARK is a short proof that some computation was carried out correctly. The proof is small and quick to verify, no matter how long the original computation took, and can be verified by anyone. Crucially, checking it requires no trust in whoever produced it: a false "proof" will be rejected with overwhelming probability.

Now apply this to the blockchain. Suppose every block comes with a proof that says:

"My predecessor block was valid, and so was the proof attached to it."

The same proof also covers the incremental checks relating the block to its predecessor, such as the validity of the block's transaction and the difficulty and proof-of-work calculations. This is called recursive block validation. Block 1000 proves that block 999 was valid, including block 999's own proof, which in turn proved that block 998 was valid, and so on all the way back to genesis. By checking just the proof in the latest block, you transitively check all of history. Answering the second question, which chain is canonical, is equally cheap: every block records how much proof-of-work the chain behind it has accumulated, and the proof guarantees that that number is correct. Comparing two candidate chains comes down to comparing two numbers and checking their tips' proofs.

The result: joining the network and syncing takes the same effort whether the chain is one day old or one hundred years old. A phone can verify Neptune Cash with the same rigor as a data center.

Every block proof becomes a chain proof, authenticating not just the block it is attached to but the entire history before it as well.

Why This Matters

Succinct validation is not a performance optimization, not least because it does not improve the workload across the board: Composers are burdened with the cost of producing the proof, which makes everyone else's lives easier. But even for the beneficiaries of this trade-off, characterizing succinct validation as an optimization misses the point. Non-succinct validation is prohibitive, and until now, the only way to escape that cost has been to trust someone else. Succinct validation changes who gets to participate without trusting anyone. The consequences are profound.

Light wallets without trust. Wallets on phones and in browsers can check the chain themselves instead of asking a server and believing the answer. Servers are still needed to serve UTXO membership proof data upon request, but that data can be validated against the chain, so the servers cannot lie.
Fast onboarding. A new node verifies the chain in seconds instead of days.
Decentralization that does not erode with age. On conventional blockchains, the number of people willing to run a node that trustlessly validates the entire chain tends to shrink as it grows. With succinct validation, the cost of verifying stays flat forever.
Privacy, scaled. Neptune Cash transactions are private: amounts and the links between sender and receiver are hidden behind proofs. Private blockchains have historically been heavy to verify. Succinct validation removes that tension.
Full nodes become light. The line between a full node and a light node blurs. A node that validates everything no longer has to replay history to do so. Archival nodes are still needed for UTXO management, mining, and reorganization-tolerance -- but not validation.
No need to store block proofs. Once a descendant block has been verified, the proofs of earlier blocks become irrelevant. Their validity is implied by the block's membership in the tip's block MMR and its valid block proof. Beyond this stage, there is no longer any need to store or transmit historical block proofs. At the time of writing, the storage cost of all historical blocks is around 60 GB, and dropping the proofs would reduce that number to around 2 GB -- a 97% improvement.

Soft Fork

Succinct validation will be activated through a soft fork. The block proof establishes the truth of all claims in the block appendix, and it is always possible to add more appendices. The upcoming soft fork simply adds an appendix that asserts that the previous block is valid.

Succinctness has been live on testnet since block 7144 and will be activated on mainnet at block 62500.

What Changes for You

If you hold Neptune Cash: nothing is required of you. Your coins are unaffected. Upgrading lets your node verify the chain near-instantly; finding and updating your own coins works as it does today.
If you run a node: upgrade before activation. Nodes that do not upgrade keep working and keep following the chain that is backed by the majority of mining power. It matters only in case the majority of mining power rejects the soft fork, and if that happens eager upgraders will be on the succinct validation chain and slow-to-update nodes or nodes that intentionally reject the fork will sync to the linear validation chain.
If you mine: upgrade before activation. After activation, blocks without the recursive claim will be orphaned, provided that the majority of hash power accepts the upgrade. Note that the extra claim increases the proving time of Composers by around a factor 3.5.

The rest of this article is for readers who want the design rationale.

Other Forms of Succinctness

When used without context, the term "succinctness" is equated with "succinct validation" -- the task of chain validation performed succinctly. It turns out there are other tasks related to operating a blockchain node that one might consider doing succinctly:

Mining. Contribute to the consensus mechanism.
Asset Management. Receive and send transactions, and manage funds in between.

The upcoming soft fork will achieve only succinct validation. Succinct mining is an explicit non-goal. Succinct asset-management is already possible and the activation of succinct validation will not degrade this possibility -- but at a cost worth mentioning.

Succinct Mining

Succinct mining means participating in the consensus mechanism without maintaining the complete archival state. However, succinct validation raises a difficulty that succinct mining exacerbates: a miner could exploit the fact that succinct validators only need the latest block to withhold data contained in predecessors.

Specifically, the attack goes as follows. Mine two blocks, withhold the first, and broadcast the second. The (succinctly validating) network, including the competing miners, will adopt the second one as their new tip, but the first contains essential mutator set proof data that UTXO holders need to update their proofs. Without that data, which only the attacker possesses, the funds are stranded.

The countermeasure comes in two parts. One: online miners reject out-of-order blocks. So a block that skips a withheld one is rejected even if it is valid. Two: miners are required to demonstrate knowledge of the archival mutator set when producing a new block. So if they don't have the complete mutator set, they are going to incur a penalty on mining rewards; and in order to get the complete mutator set they must have validated blocks incrementally.

In other words, succint mining is an explicit non-goal because archival mining is the countermeasure against the above attack.

What about Succinct Asset Management?

To spend your coins, your wallet needs up-to-date membership proofs, which establish membership in the mutator set, which in turn establish that the coins really do exist and are not being spent a scond time. The membership proof may change with every block. A wallet that stays online keeps it current by processing each block as it arrives. This is a succinct solution technically speaking, but in practice it is slower than maintaining an archival mutator set and reading the membership proofs from there when needed. Moreover, the succinct option comes with the rather onerous obligation of staying online continuously and fails in the context of reorganizations unless the node remembers, or is served with, all blocks on the path from abandoned tip to new canonical one.

A wallet that has been offline for a while, or that is being restored from its seed phrase, must catch up somehow. Right now it catches up in one of two ways:

By processing every block it missed, which is not a succinct task and requires nodes serving historical blocks.
By getting the data from a node that maintains an archival mutator set. That node cannot trick it, since data can be authenticated against the mutator set accumulator and that last object is contained in the (succinctly validated) block.

Against that backdrop, the controversial question remains: at what cost do we want to keep the data in the block that enables succinct membership proof management? Dropping that data would sacrifice the ability of nodes to succinctly manage UTXOs in the general case, namely if they remain continuously online and barring reorganizations. But in exchange, the blockchain's transaction throughput capability stands to benefit. Two limitations are lifted: First, the data in question occupies scarce block space. Second, that data must be authenticated -- a cheap task on the CPU but as succinct validation is an objective, Triton VM cycle count is the relevant metric, and that number is substantial. At the end of the day, every extra input (removal record) substantially increases the workload of Composers, giving them a disincentive to confirm a large number of basic transactions.

To reduce this cost, the recursive block program in the upcoming soft fork does not authenticate the data needed for succinctly updating UTXO membership proofs. Its authentication does remain as part of the host machine block validation rules, so blocks containing inauthentic removal record data will be rejected when broadcast. The remaining attack vector involves a significant portion of the mining power skipping a block with inauthentic removal record data. That discrepancy is worth closing, but closing it without incurring a huge cost requires a hard fork.

Conclusion

Verifying a blockchain should not require a data center or a week of patience. With the upcoming soft fork, verifying the entire Neptune Cash blockchain will take one block, a few seconds, and no trust in anyone -- not in a server, not in a wallet provider, not in us. That was the promise from the beginning.

Acknowledgements. Thanks to codewordneptune for framing, feedback, and the diagram.