Hacker News Reader

Comment by milkey_mouse | Hacker News Reader

Yes. The proof of block n's validity proves both that the state transition from block n-1 to block n is valid and that the previous block's proof was valid. The arithmetic circuit for a state transition proof actually encodes a program which verifies SNARK proofs (in addition to the less academically interesting "doesn't create $ out of thin air" sort of rules). The proof of the latest block at any height (which is all the state you need to know you're on at least a valid chain history) remains constant size because of the indirection of proving that a verifier accepts the last block's proof without actually including it (taking advantage of the fact that a zero-knowledge proof doesn't have to include or even reveal the data it's proving something about).

View on HN

I realized this is misleading as an answer to your question, but it's too late to edit. Block producers (i.e. miners) don't need to keep track of chain state, but provers need to know the state of block n-1 to generate a proof for block n. In practice, the current state is pretty small, but admittedly way more than 22KB: I just synced a node and its data directory is 235MB.

The zero-knowledge proofs still provide the advantage that historical state doesn't need to be kept by anybody: if news of a better chain tip comes along (including while bootstrapping), it'll come with a recursive proof of its validity, whereas with Bitcoin et al. it'd need to check if it's building on a valid block (and thus keep at least the hashes of previous blocks).

Thanks for this explanation.

Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts? For something like a DeFi DEX to be useful, it's not enough to know that specific operation succeeded. It has to be possible for anyone to invoke the operation themselves, and that means that the state of the smart contract, and the contract's executable code, need to be publicly known.

Each block contains a commitment to the state of the chain in the form of a Merkle tree. In that regard it's not that different from Bitcoin's MAST or Ethereum's (WIP) stateless clients. To prove something (say, an account balance) is in the block, one would need to know the data you're trying to prove as well as its Merkle path in that block's tree.

> that means that the state of the smart contract, and the contract's executable code, need to be publicly known.

Yes, they would need to be separately distributed somehow. But I think this is similar to how Ethereum contracts typically have their source code (and by extension ABI) uploaded to Etherscan, without which they'd be difficult to interact with.

> Do you know anything of how Mina would handle things that need to exist in the public state of a blockchain, but which cannot be learned from the 22KB proof—for instance, DeFi smart contracts?

A good rule of thumb is that Mina full nodes behave like other blockchains' light clients that just happen to sync quickly & trustlessly. I am not an expert on smart contracts, but I think in practice, a Mina DEX would probably work something like this:

- You visit minaswap.io or whatever (or a copy on IPFS). The static page includes a copy of the contract's interface.

- The page tries to call a hypothetical Mina browser extension running a full node in the background. If it's installed, it uses it; otherwise, it downloads & runs a Mina full node compiled to WASM as a "polyfill".

- As the WASM node syncs & verifies the latest block's proof, it asks someone for the contract's current state and the Merkle path to it within the block.

- Once the node has synced, it verifies the contract's data is actually in the Merkle tree using the given path. Now we know the interface & state of the contract and that's all we have to keep locally.

Also: although block producers don't necessarily have to, provers always keep a copy of the current ledger state (see my above comment; sorry if my first comment was a bit misleading). This would include smart contracts' state (but not their code). If you run one of these nodes, it knows every contract's state, which should still be small compared to Ethereum as so much can be done off-chain.

These are called snapps in Mina, basically the state of a smart contract is nothing more special than the balance of an account, so you can store it on the blockchain in the same way. Now Mina is a succinct blockchain and zkp allows most data to be stored off-chain so I think the idea will be to limit heavily the amount of on-chain data.

I just get the feeling that "on-chain data" doesn't mean the same thing in Mina as it does with other blockchain systems. The 22kb is a ZKP and would not contain any contract logic or contract data, I think, so any contract data and logic would have to come from another source.

The 22kb, which is more like 11kb I believe? is a proof of the state, you don’t get the balances of all accounts within the proof itself, that’s something you need to download separately.

Reply on news.ycombinator.com