Are there any real uses of ZKP outside of blockcrap?
I can't get anyone to explain how it's different than a password hash other than in these elaborate hypothetical scenarios that don't relate to technology.
The verifier would need the government public key and then can see "This ID that has been signed by the governments private key shows XYZ"
The police scanner then verifies the signature and checks that the certificate is correctly signed by the government's public key.
No need for ZKP.
Literally yes, in some places. Passports have a chip in them, and licenses in some countries as well.
> Over the internet?
Tunneling private information over untrusted networks is literally how you're seeing this message.
The whole point of ZK proofs is the zero knowledge part. If you don't care about the person being able to see the information of course there's no need for them.
> It doesn't answer arbitrary questions about the data.
Why would you need a "ZKP" to prevent anyone from "asking arbitrary questions" you simply don't build that functionality.
When I create a web server and allow people to login through an endpoint, they can't ask arbitrary questions about user data either - how would that functionality even exist without me writing it? Typically the server doesn't even know passwords. It simply compares a hash - the hash is computed client-side and the server never sees the real password.
Any peripheral user data you want to return is up to you. Identity is not "built in" to conventional programming languages.
Furthermore, none of the ZKP libraries on npm do anything. Most of them are utility libraries with functions like "generateUUID" and "leftPad". The ones from providers like Cloudflare (their least popular stuff) are just private/public key encryption libraries that they call "ZKP".
I posted this earlier (and it's in the article...) but will reiterate again: ZK proofs are used when the prover (server) and verifier (client) don't trust each other and don't want to give each other data on each other. If you trust the server you can just give it a copy of your passport, if the server trusts the client they can just show a checkbox asking if they're old enough.
I linked to a working library earlier, it's here https://github.com/zk-passport/openpassport
The circuit won’t query DB but rather return your name or maybe a hash that can be used to query the database.
My question is then: What is unique to ZKPs? Are the ZKP folks just asking us to start calling these techniques "ZKPs"?
When I use Clear for IDV is that a ZKP? Just like your example, they show the ID to Clear, but I never see the ID.
Clear is not ZKP because Clear servers learn all data from your documents. With ZKP Clear would only know that you hold an ID with details matching the ticket you also hold. This is just 1 bit of information instead of many.
Anyway, the ZKP concept is not about decrypting hashes at all, but looking at peripheral data to prove something (Alibaba Cave - Victor only knows Peggy knew the password because he had access to some other data - the path she took). "checking length etc." only if those hints are already available to the system in some way. And because of this approach, why would you need the hash? Just don't use passwords at all in the case of ZKP right? Simply rely on the other identifying data that you have access to, that you use anyway. Also - how secure is this loose profiling technique compared to email-backed passwords over HTTPS?
I imagine few product use cases allow for a server to trust all the clients with encryption, while not trusting itself - but there are some use cases like when the server is not the source of truth - file system service, or peer-to-peer stuff like ledgers: If the server's purpose is just to maintain a shared ledger and all the clients in the network are trusted.
But in the case we're talking about, of a service that authenticates clients, you're saying you can't trust the authenticator when that is kinda the point of authentication - they don't trust you, or rather - the server cannot tell for sure that any incoming connection is who they say they are, even if it has "zero knowledge" like their IP address and a face scan (your brother in the same house might pass). The point of a username and password is that you want the server to not trust any connecting clients unless they have this specific data precisely.
So I wouldn't use it for auth.
At the moment, producing a zero knowledge proof has roughly a million-fold overhead compared to running a program directly. So there aren't many applications where that's acceptable. So I am very grateful that the blockchain people are more than happy to throw money at the math here. Very generous of them.
In principle, you can use ZKP for privacy preserving compliance work in real (ie traditional) finance.
To quote myself (https://news.ycombinator.com/item?id=41422250):
> 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.
> 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.)
"Goldman Sachs could..." but they do NOT. Like they don't use blockcrap for interbank settlements, asset tracking, notary, etc.
So basically, no actual uses so far. And it's not even clear _why_ I would want to use ZKP.
No, they won't.
> worldcoin ID verification is another.
In other words: cryptocrap.
I'm not so sure. That would only make sense, if the lawyers and regulators are on board.
> Like they don't use blockcrap for interbank settlements, asset tracking, notary, etc.
Yes. So far the only way to track real world assets on a blockchain is to have a trusted third party (or third parties) that connect whatever your blockchain says to the real world.
But if you have that trusted third party, you might as well have them run the database that keeps track of who owns what. No need for a blockchain.
ZKP is different in the sense that it's one of only a few things to come out of the 'crypto' world that has at least a _chance_ of being useful in the real world. One day. Perhaps.
(Cryptography in general is enormously useful. Have a look at HTTPS for one example. When I just say 'crypto' I mean specifically everything to do with the blockchain ecosystem. So far the only real applications of crypto / blockchains that I've seen are gambling (generously called 'speculation' or 'investment') and ransomware payments. Cryptocurrencies aren't even good for buying drugs on the black market so far.)
In any case, ZKP is still very immature. But we are very fortunate that the crypto-people are generously funding this area of essentially pure mathematics research.
> examples like confirming someone is of age
When where are the companies that do that? Can I replace my Washington driving license with a ZKP that I can show to police officers or to enter a pub?
There are really no practical examples of the actual usages. Just hand-waving. And moreover, all the examples you provided make no sense. They are far better achieved using classic asymmetric systems.
On the contrary, your sentiment reads less like wisdom and more like hardheadedness. I am glad there are plenty of others here who do not share such a narrow-minded sentiment.
The venn-diagram between cryptocurrency and ZKPs is not a circle, or really even close. They're a mathematical concept first and foremost, and thanks to crypto dumping tons of money into the scaling problem, now much more easily worked with in code across any application. So much for all cryptocrap being, well, cryptocrap!
Your example is terribly contrived. No, you won't replace your drivers license with a ZKP. But a service might validate that you're of age, or meet some other criteria, without you(or they) revealing actual information about yourself.
All of the examples I gave(none of which are my own, but from other commenters who are I'm sure happy to discuss further) require the context of established trust. "Classic asymmetric systems" have problems with this.
Like: "Company XYZ uses ABC to provide asset tracking, and it's now used by 99% of the DEF sector".
> The venn-diagram between cryptocurrency and ZKPs is not a circle, or really even close.
Then it should be treated as such, instead of trying to claim that it has practical applications.
If you can't think of the possibilities that unlocks beyond the examples others have already discussed(none of which were crypto related), that's a limitation on your end.
And? Why is it better than good old PKI?
And even then, it hand-waves away the issues with revoked licenses. How do you do license revocation with ZKPs?