Sounds like a good idea. Until, like Tornado, the tech gets sanctioned.

I feel like your downvotes are undeserved. From an engineering perspective, all Tornado did was add anonymity/plausible deniability to the blockchain--which is all that ZK will do. Maybe there's a question as to whether OFEC will also see ZK as money laundering, but my guess is they won't until it gets to a certain scale and then they will--exactly like Tornado. That limit was ~$7 billion, which is < 1 FTX, and far smaller than the current market cap of Ethereum.

Yeah, I feel like cryptocurrencies only have a chance of providing value to some users if it's not actually very succesfull.

- If it's successful in providing anonymous transactions to everyone: Regulated to death due to laws aimed at combating money laundering and organized crimes. Even cryptocurrencies that aren't perfectly anonymous will probably eventually be regulated to death for not providing good enough guarantees about the identity of the wallet holders. - If it threatens the Eurodollar as a world reserve currency: regulated to death at least in USA and probably Europe.

In what scenario can cryptocurrencies actually achieve its goals without risking being regulated to death?

And yes, I know you can't effectively ban all trade of cryptocurrencies. But trade will always be a niche if most people can't use it in the real world.

I confess I possess only a shallow understanding of ZK rollups - can anyone explain how you can have an opaque proof that transactions are valid and still solve double-spending problems?

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.