You can run an arbitrarily large, arbitrary long program, and whatever the program outputs, you can make a tiny proof-signature that says "this is the output you'll get if you run this program yourself".
The proof-signatures are relatively small, and you can verify them on small devices in milliseconds.
Another computer can trust the claimed output without having to run the program itself, by verifying the proof-signature.
This scales to arbitrarily large computations, so for example if a supercomputer says "I ran a quadrillion petaflops of your program for 1 year, and the result was the picture attached to this signature", you actually can verify that the picture is correct, quickly and efficiently - without having to trust the supplier.
It's as good as if you re-ran the program yourself (up to cryptography-grade probabilities, which is good enough).
Or if the big computer says "this entire Debian distribution of binary files was indeed compiled with this version of GCC", you can quickly verify that all the binaries are exactly what they should be - without having to trust anyone.
The proof process is rather slow, but it has gotten a lot faster over the last few years, and will continue to.
I was amazed when I learned that it's possible to securely check an arbitrarily large computation's output or result without running it yourself.
It was so counter to my intuition: it seemed like you would have to trust whoever makes the claim, or run it yourself. But you don't!
(So amazed and intrigued that I had to learn how it's done, and now part of my work these days is optimising the proof process.)
> So amazed and intrigued that I had to learn how it's done
Any chance you could just illustrate this somehow with a basic example? I just don't see how you could possibly verify that a program is produced with GCC without going through approximately as much effort as it'd take to compile it.
More useful cases include decoupling payment information from users, to preserve their privacy. You can prove that somebody paid for the action you want to perform, without identifying the payer. For example to offer cloud storage without knowing which data belongs to which user, so when there is a data breach or law enforcement order, the answer to "tell me everything you know about user X" is their payment history, but not which data is theirs.
Correct.
People who need the privacy can set up isolated bank accounts and legal entities.
Less cryptography, your accountant will even understand.
The basic concept here is: ZKP lets you prove arbitrary statements.
Instead of:
Here is entire bank history, you decide.
Had a fixed income above $X for 12 months.
Had a surplus of $X after fixed expenses in the last 3 months.
Did not buy anything irregular above $1000 in the last 3 months.
Think of a ZK proof as a program that can take both public and private knowledge as input, and produce public and private knowledge as output.
This is what seems magical to me: A program with secret input. You can't run the program to verify that my execution of the program is correct, but you can verify a proof that I ran the program with input you didn't have.
The way private knowledge works is through cryptographic commitments.
For example, the bank may start by giving you a signed, structured document with your transactions.
You can then feed their signature and the document to your program, and produce any derivation.
This requires cooperation from the "bank", ideally providing Merkle trees to make sure no tx is missing in the proof like it would be for a blockchain-based solution.
Eg Goldman Sachs could encode all their compliance rules in a program, and publish a proof that their books pass the check by that program, without revealing anything about their accounting.
More crypto focussed: suppose you build a 'better FTX'. You could publish a proof that you ain't hiding an Alameda, ie that everyone who should have been liquidated actually got liquidated, and doesn't get special treatment.
In a banking context, you could in theory also run your know-your-customer (KYC) rules against customer provided data, store the proof, and delete the original data. That way, you still have proof that your customers don't have ties to North Korea or Russia, but you can't be compelled by anyone to reveal the data later (nor accidentally leak that data, etc).
Of course, for that latter application, you need a sharp lawyer to make sure that storing the proof instead of the original data is enough for your KYC obligations.
If you want to go further, you could have your customers run the KYC rules locally, so that their data never leaves their premises.
(For all these applications, you still have to have a mechanism that connects the real world to the inputs of the programs whose execution you are proving.
So eg Goldman Sachs would still need an auditor that checks that the assets and obligations they have in their balance sheet actually exist, but the auditor does not otherwise need to make judgement calls or apply any rules.)
Digital signatures are useful, we all know that, now imagine if you could sign not only data, but also computation result. As in “I ran this code with these inputs and it produced that output”.
If you imagine that this would work, and it takes less time to verify that signature than running the program myself, you have a succinct proof.
If in addition you can hide some of the inputs you used, then you have a zero knowledge proof.
So ZKPs are “stronger” signatures as they can sign more than data. Sometimes a signature is enough, sometimes you need more. Sometimes you need privacy so you verify a signature inside a ZKP :D
- verifiable, auditable, anonymous online voting
- anonymous signatures, authenticating that a whistleblower complaint comes from a real employee, without knowing who the employee is
- verifying your personal data without making it public. E.g. verifying that you're over 18, either black, disabled or low-income, revealing no other identifying information about yourself. This would require collaboration from the government and "compatible" ID cards.
- Blacklist handling, letting you comment anonymously on line, verifying that none of your previous comments have been banned for abuse.
But it is early days and I think there's going to be many more use cases in the future around data privacy. Take an example of credit bureaus. What if instead of a lender sending over all the personally identifiable information needed to do a lookup it could instead send a ZKP to prove it knows enough information about an individual to be authorized to retrieve their record, meaning instead of sending SSN, DOB, Address, Phone, Name, they could instead just send enough specific values in the hash of a combo of some of those fields to prove that the full hash is known but without exposing the full hash itself (along with the existing shared secret to have authorization do lookup a value in the credit bureau in the first place).
Your server costs would only need to be for the metaprogression/persistence related stuff that could be done relatively infrequently based on updates from the client.
ZK proofs are potentially a transformative tool for real-tine distributed systems in general, not just games. They potentially improve laency ("ping"), by changing the communication patterns in a distributed consensus system. That's great for games and other real-time systems.
Right now, the way this works is essentially through a lot of trust and some guarantees by the fed. This has some downsides: because you need a lot of confirmations, it makes transfers take longer. Also, small players can't really get in on this system, so some regional banks are at a disadvantage.
How do you make this safer and more robust? GS obviously can't send info on all of its clients accounts and balances to Citi. You could imagine a protocol where the client/GS sends Citi a zkp to prove that the client has the money (as long as all inputs are agreed upon).
Of course, you don't really need zkps. You could also have the fed keep a database on all money in all accounts (like they do in Brazil), so that the bank only has to ask the central bank to give you an ok. But that is a whole lot of power in the hands of a central authority, as well as a single point of failure, which is something banking systems should avoid imo
At the moment this is all handled with Swift, and I’m not sure you what you gain from adding ZKPs. Depending on the transaction you might send a Swift MT799 with a pre-advice letter, a proof of funds letter, or a blocked funds letter. Again depending on what you’re doing you might need a MT760 to send a bank guarantee or some sort of letter of credit, and finally a MT103 to initiate the actual transfer of funds.
At this point your counter party risk lies with the banking institution itself, and their willingness and ability to complete the transactions they have legally committed to, rather than the account holder, and this risk doesn’t go away with the addition of ZKPs.
I think what could be gained with a zkp protocol would be timeliness. Not needing to confirm if the client has funds in the other institution manually or from trusting their in house APIs would be pretty nice.
The Brazilian central bank has a system that does essentially that, and wires here (even for very large sums) take seconds to fill, instead of the usual 2 days for US interbank wires.
When using Swift, the financial institution crafts the content of the messages, some of which describe the state of their systems (like an account balance). So as a counterparty, you are trusting the institution, the jurisdiction the institution is based in, and the laws and enforcement in that jurisdiction.
If you introduce ZKPs, perhaps you could take the human out of the message authoring for some message types, but those messages would still be based on the state of systems controlled by that institution, and really a lot of the “trust” involved with Swift transaction is the trust that an institution will meet its future obligations (something ZKPs don’t help with at all). So the end result is that as a counterparty, you would still be trusting… the institution, the jurisdiction the institution is based in, and the laws and enforcement in that jurisdiction.
There are other payment systems that don’t have the same features that Swift has (like the ability to send bank guarantees, or proof of funds letters, etc…) like ACH and SEPA. But if those things are needed, you’ll just use Swift, or a different system entirely.
The delay in processing Swift transactions is also a feature not a bug for large institutions. If I send you a Swift payment for $100, unless one of us is on a watch list or something, it’ll just go through without any additional input required from either of us. But if I wanted to send you $1,000,000,000, at that level the banks want the opportunity to scrutinise the transaction for AML and anti-terrorism reasons. There is no definition of what a transaction that is involved in money laundering or financing terrorism looks like, so these checks cannot be automated in any way. If you want your transaction to go through, you have to answer whatever questions the bank officers ask, provide any material they ask for, and this can include literally anything they deem necessary. If the transaction is successfully completed it is not because you met some statutorily defined requirements, or somehow proved you weren’t money laundering or financing terrorism, it is because you convinced the appropriate bank officer that the risk of them being implicated in money laundering or financing terrorism was small enough to be acceptable in relation to processing your transaction. So ZKPs can’t help you here either.
Sounds you indeed have zero knowledge of zero-knowledge proofs. Congratulations!
If you want, I could prove to you that I know what zero-knowledge proofs are and how they’d be applied in industry, but you’d be no closer to understanding it. I would do it in a specific way that would basically impart zero knowledge to you, beyond the fact that I know what I’m talking about. Interested? :)
- Anonymous credentials (this is what Signal does) - maintain an encrypted blob representing a group chat (members list etc all stay encrypted and Signal cannot tell who is in a group chat). A normal client can provide a zkp that they are in a particular group chat (the decrypted blob contains this member for example) and have a message delivered to other group members. Both the client and the recipient can keep their identities encrypted and the zkp proves the membership of the plaintext client / recipient.
- Encrypt some metadata of a message sent to someone. You can build a ZKP that the plaintext behind the encrypted metadata satsifies some properties such as recipient is not in some blacklist (and so on). All this can be done by maintaining privacy because the metadata stays encrypted.
- Given an electronic medical record, you can prove that the record contains a vaccine without sending the record over the wire to some other party.
Lots more such ideas exist.
zkVMs are a good place to start playing with things.
I guess I'm wondering if Signal still basically has enough info to make good guesses at group existence.
The central authority in this scenario cannot discriminate between transactions - any function that would compare two or more transactions cannot glean any useful information that would allow to discriminate. And and security of the anonymity of past transactions will be reducible to the security of the cryptographic hash function used (the next best thing to Information-theoretic security). As for forging money, depending on what ZKP approach is used even a quantum computer will be insufficient.
The central authority can still print money and can obviously shut the entire system down.
It is interesting to ponder whether or not some government will decide to take such a step and surrender all control (except for the nuclear option) over how their currency is used. It will certainly boost demand for the currency.
Roughly: you have 2 secrets that you hash together and the central authority adds the result you disclosed to a list (either to print money or as part of a transaction to transfer money). To spend a note you reveal the hash of one of the secrets (to be added to a list of nullifiers to prevent double spend) and you do ZKP to demonstrate that you possess both of the secrets to *some* note from the public hash list and that the nullifier for that note is what you claim it is. Central authority rejects if nullifier is present in the list.
There are some other approaches to such a system, I believe the Tornado Cash one is the most elegant though it limits you to a discrete number of note denominations.
Note that the proof system Tornado Cash uses is not secure to a quantum computer and such a device will allow to "print money" - in reality, drain the smart contract.