This thread might be helpful: https://twitter.com/LuozhuZhang/status/1538171370814570497

Essentially, zkEVMs map EVM bytecode to equivalent zero-knowledge circuits (containing the logic of what is and isn't valid, i.e. double-spending) so that the entire execution can generate a proof. It is a lot of math.

Thanks for the link. I've glanced at it, and so far my understanding of it says that the ZK proof allows verification that the results of each individual transaction is exactly as what is given, so that the resultant state provided by the ZK commitment can be trusted.

My original confusion was more about how consistency of state can be maintained across completely opaque commitments of transaction validity.

Now that I think of it, it seems that my original concern was a matter more trivially dismissed than what you've explained - my doubts were more about how state could possibly be consistently yet opaquely maintained, but the blockchain state machine, and I gather the ZK commitments, are simply not opaque with respect to the VM state - the opaqueness provided by ZK commitments is opaqueness in the intermediate transaction state (essentially irrelevant information - perfect candidate to be optimised away). The problem of double-spending is never relevant within a single chain of block commitments, as any second-spending of resources is simply an invalid transaction and is rejected, given the (necessarily public) hitherto state reached by consensus (- the problem of which, is precisely what the blockchain mechanism was designed to solve).

Disclaimer: I have no idea what I'm talking about with respect to ZK, and may be completely wrong.

> more about how consistency of state can be maintained across completely opaque commitments of transaction validity.

I have the same confusion as you, and I'm not sure I understood your last paragraph. The prover (person submitting a new transaction) can provide a ZKP that the transaction he is making is valid, and the blockchain will adopt it if indeed it's a valid proof. So then the onus of preventing the double-spend here effectively on the prover: he can only provide a valid ZKP for a valid transaction, and a double-spend would not be a valid transaction.

But then at the end of the day, seems like the underlying balance needs to be accessed somehow (otherwise how would the prover even know if he has enough funds avaliable?). I guess the prover (and only the prover) can do this because he presumably has access to the right private keys?

it’s similar to how you can hash passwords to know that the user knows it without knowing the password. so you don’t know the amounts you just know that, for example, the output (debit) is affordable by the sender (in the case of a payment). the sort of “magic” of zk systems lies in the part where you can turn complex programs into something similar by converting them into polynomials. it turns out that pretty much any program can be represented as polynomial math and the second magical part is that although the proofs might be expensive to compute, they can be verified in constant time (in the case of a SNARK at least).

zk rollups do not inherently provide any privacy, but there are different ways to use zero knowledge proofs to provide privacy on a blockchain. See for example the Zerocash paper, the currency Zcash started off the back of the paper, and various follow up systems.