Hacker News Reader

Comment by mattlondon | Hacker News Reader

I don't see how privacy can ever be solved with blockchain. By design, everything you ever do is permanently out in the open for ever and ever for anyone to not only see what you did, but mathematically prove that it was you (well, your key at least) that did it.

Sure you can be "anonymous" when using your wallet etc, but as we all know it is usually trivial to de-anonymize large data sets. Likewise, being anonymous when using a wallet then removes a lot of the perceived value of using it for identity verification (e.g. sign-ins, proof of humanity etc).

View on HN

See https://docs.zksync.io/zkevm/#what-is-zkevm-and-why-is-this-...

Basically you can make transactions anonymous using much the same kind of protection as you have between public and private keys. There is a proof the transaction is valid but that is basically all you can see.

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.

Look at this code:

https://docs.zama.ai/concrete/getting-started/quick_start

This is a rust based Fully Homomorphic Encryption (FHE) example.

That is to say, you can encrypt two numbers, do a mathematical calculation on them without decrypting them, and then, only the person with the private key can decrypt the result to get the value.

If you add something like FHE to blockchains (it's coming) then you can get anonymous transactions on the blockchain directly.

By the way, Zero knowledge proofs are not what is needed to get anonymous transactions. When you use ZK, you are issuing the proof AND have knowledge of the inputs. The prover needs to know the inputs, but does not need to reveal them to the verifier (which happens on chain). This means the transaction can assert that the mathematical operation occurred without doubt, but when you need to get at the numbers, you are back to a transparent value on the chain.

Given the high complexity of FHE, surely there be limits to FHE based transactions?

Definitely. And, the founder of Zama says there are new chips which will optimize these types of calculations and make them more mainstream.

For the record, no clue how true that assertion is, but seems like now that the calculations are possible, Moore's law will solve that problem one way or another.

FHE is going to make things interesting and it seems like it is only a matter of time before they are workable on existing blockchains.

Plus, these types of calculations are not susceptible to side-chain attacks, since no private keys are used in the calculations.

FHE computations are hundreds of thousands of times slower than non-encrypted computations, and are non-parallelizable, and Moore's law is long since dead for single-core performance.

I didn't know that. I'm interested in understanding why they aren't parallelizable? I'm surprised that is the case. It's a good point you make, and makes me wonder whether a combination of zk proofs where the inputs to the zk proof are the encrypted inputs of the FHE conjuration. If so, that could be used against a verifier to move the computation off chain. Seems like a complicated circuit you would need to make but if you could do it, you wouldn't need to worry about the computational cost on chain. Thanks for that information, very thought provoking.

> new chips which will optimize these types of calculations and make them more mainstream.

There are quite a few people working on this problem from both the hardware and software side of things. Source: I've talked to a large number of them. It is still early days, but given the level of interest out there to do this, I believe strongly that it will happen.

>When you use ZK, you are issuing the proof AND have knowledge of the inputs. The prover needs to know the inputs, but does not need to reveal them to the verifier (which happens on chain).

Can you elaborate more on this? What is this a ZKP proof for? That the transaction is valid?

Also from all the ZKP examples I've seen in crypto[graphy] class, soundness relies on the ability to repeat the process again and again. How does this work for the blockchain case where it seems like there's only one round of communication between prover/verifier?

ZK rollups/EVMs are one among the myriad of arguably badly named things in maths & CS.

They are named so because they are an implementation of what is called ZK proofs, but they leverage them to be able to prove a succession of modifications of the state (i.e. the accounts and their money) in a quick & easy way to check. As a simplification, you may think of them as a hash of transactions & smart contract executions that are a tad expensive to compute, but trivial to check. The end goal typically being to multiplex multiple level-2 transactions onto a single Ethereum transaction to enhance bandwidth and reduce fees.

However, they are not ZK in the applied sense of it; e.g. they do not even try to mask the operations; anyone could rebuild them themselves with a bit of effort.

Check zero-knowledge proof based blockchains. They provide ways to build privacy-enhanced applications with smart contracts (called zkapps). I wrote about it a bit here: https://www.cryptologie.net/article/575/whats-the-deal-with-...

A reply you got already mentioned zk functions, which is the best answer (cool tidbit, Avalanche's custom VM allows you to build these functions and anything else you want as precompiled code. More gas efficient.)

My second reply would be a hybrid system. I've been tossing around this idea in my head for what I call a decentralized PBM. At first I struggled with the privacy idea. Then I had the realization that it was unnecessary to bring PHI on chain. I could accomplish all the stuff that would benefit from a chain without it.

You can realize a lot of value from blockchains even if you're not purely decentralized.

My bet is that a zero knowledge algorithm is what is hinted at.

You can prove that you have the keys to sign. Without having to produce the key.

Or something of that effect. Cryptocurrencies are bunker. Zero Knowledge is a big deal.

There is a solution called DECO: https://invidious.snopyta.org/watch?v=zWTx1iQOCDM

Backup video link: https://www.youtube.com/watch?v=zWTx1iQOCDM

Original paper: https://arxiv.org/abs/1909.00938

https://github.com/EYBlockchain/nightfall_3

You should look up how Monero and ZCash work.

Can those be built onto eth?

Aztec already is: https://zk.money/

It's like the Zcash shielded pool, but as an Ethereum L2.

Monero can't for the simple reason that for privacy to work well it needs to be on by default, not opt-in like ZCash does it.

However Monero has shortcomings, the main one being its auditability.

Some Monero developers have created a new project which tries to solve those issues, and add zero knowledge proof to the mix: https://pirate.black

You can audit Moneros math and source code, therefore you can audit the supply. It's more work than with Bitcoin to be sure, but it's still possible.

Monero already uses zero knowledge proofs, but in a different way than eg ZCash.

The opt-in nature of Zcashs privacy mechanism is not inherent. You can just flip a switch and disallow private transactions.

No. Privacy has to exist at the base layer.

Not true

Reply on news.ycombinator.com