What if there was a way to get the benefits of Zero Knowledge Proofs but with less hassle?
Here’s a fun game you can play. Go spend some time wherever crypto people hang out. Time how long it is before one of them says ‘Zero Knowledge Proof.’ If it’s more than an hour I’d be surprised.
It seems like Zero Knowledge Proofs (ZKPs) are a ‘go to’ solution whenever problems like privacy or scalability are raised. And this is entirely reasonable. The ZKP concept is a game-changer: first popularised in the context of blockchains, they could also solve some fundamental privacy problems we face when building any type of distributed system.
To see why, let’s first remind ourselves what a ZKP actually is. Everybody might be talking about them but how many of us, hand-on-heart, can say we understand them? The good news is that the concept is simpler than it may appear. It comes down to this:
A Zero Knowledge Proof allows somebody who possesses some information to prove that they possess this information but without revealing anything else whatsoever.
To see what this means, and why it’s important, here are some of the things ZKPs can let you do:
- If I have a digitally issued passport, I could prove to somebody that I was over eighteen years old, without revealing my name or date of birth.
- If I possessed some cryptocurrency, I could pay it to somebody else and prove to them it was now theirs, without them or anybody else learning where I obtained it from or how much else I happened to own.
- If I wanted to build an Ethereum scaling solution, I could gather a bunch of pending transactions, execute them myself — ‘off chain’ — to figure out what their combined effect would be, and then submit a single transaction to the network that just applies those effects, massively increasing the capacity of the network.
It’s as if a clever person woke up one morning and asked:
Wouldn’t it be awesome if we could use advanced technologies to convince somebody of something but without having to show them the evidence?
And the answer is obviously yes. It would be awesome! It is awesome! And it’s no surprise that so many people see this as the solution to a whole bunch of problems.
But there’s an issue…
The problem is that ZKPs have gained a reputation for being complex and slow, and hence only to be used if absolutely unavoidable. Now, it’s true that the ‘proving’ step can still be slow but the technology itself is becoming more consumable all the time. Even so, it’s still not the kind of thing a regular programmer working for a normal business could just pick up and use.
The result is that, whilst it feels like everybody is talking about them, it’s only a few projects, staffed by extremely talented people, that are actually able to ship. ZCash, ING’s work for Corda and zkSync are notable by how rare they are and how strong their teams are. Smart people are working on general-purpose solutions, such as zkEVM, but I think they’d acknowledge there’s still some way to go.
So it’s a shame that the rest of us have to wait for this tech to become more consumable, because the underlying idea of proving things without unnecessarily revealing secrets truly is awesome. And the world would be so much better if it were deployed at scale. And if we could do it today.
I think there’s a way through that many people have overlooked, and which could deliver benefits right away. And the key to unlocking this is to ask ourselves: what do we care about more? Solving a problem? Or applying a specific technology?
If we didn’t have a team with the skills to solve our problem with today’s ZKP technology, but could solve the problem some other way, could we live with that?
Here’s what I mean. In my introduction, I boiled down the attraction of ZKPs to this:
“Wouldn’t it be awesome if we could use advanced technologies to convince somebody of something but without having to show them the underlying evidence?”
And I pointed out that this is indeed what ZKPs can do. But there’s a point that many people don’t realise. ZKPs aren’t the only way to do it.
This is because the inventors of ZKPs, extremely talented mathematicians and cryptographers, weren’t only trying to solve the problem I outlined above. They had an extra goal. They wanted to solve this problem purely in mathematics. They wanted their solution to be something that could be implemented on any computer using regular software, eliminating the need to trust anybody other than the cryptographers.
And this is a noble endeavour: if you can prove that your implementation is sound then you know your solution will work — and be secure — regardless of which computer it is run on.
But it comes at a cost. As we’ve already noted, the skills required are still fairly rare, although new tools to simplify the process of developing ZKP solutions are emerging all the time. It is also extremely computationally intensive — and hence slow — to generate the ‘proofs’ upon which ZKPs depend.
So, is it worth taking a step back? Are there other techniques we could consider if we relax the self-imposed constraint about only using regular hardware? Could we get comfortable with broadening who we’re prepared to trust, to encompass more than just the clever cryptographers who have developed the ZKP mathematics, and the software engineers building the associated tools?
It turns out that the world’s CPU manufacturers have also been working on this problem. Firms such as Intel have added features to their chips that let you run code in a ‘protected’ mode, that locks out the operator of the computer. Now, at first glance, it’s not obvious how that would be relevant to our problem.
But there’s an extra piece of puzzle. These CPUs can also cryptographically ‘attest’ to third parties that they are running in this special mode and are running a specific piece of code. You may have heard of these technologies — they go by the names of Intel SGX and AMD SEV, for example.
And now it gets interesting.
To see why, think back to the first example I gave: somebody who has a digitally issued passport who wants to prove their age to somebody. Imagine you were to write a simple computer program that does the following:
- A digitally signed passport file
- Parse the file and check it is valid
- Check the signature belongs to the correct Passport Agency
- Is the date of birth on the passport more than eighteen years before 2022?
- If not, fail. Otherwise, extract photograph from the passport file and produce output
- The photograph from the passport; and
- The statement: “The person whose face matches this photograph is over eighteen years old”
This program does do what we want, right? It outputs the statement we require and does not output anything else about the person. But, by itself, it’s useless. If I were to take the output and show it to you, why would you believe it? I could have typed that statement myself!
But now imagine this program runs on one of these CPUs I mentioned above. Now the output is different. In two very important ways:
- The first is that the output is digitally signed.
- And the second is that the output is accompanied by a statement, that comes from the hardware, that states that the signature could only have come from that specific program.
This is really interesting. Provided you’re willing to trust the hardware, then you can squint your eyes and realise that this is a Zero Knowledge Proof!
The only difference is that you’re relying on the hardware to work as claimed: the ‘trick’, if you like, is that the hardware is promising you that this really was the code that ran and this was the output, and you are trusting the hardware not to have screwed up.
To be clear, this isn’t a panacea: you’re still trusting lots of clever people: Intel’s engineers, the developers of the ‘Confidential Computing’ software development kits, and the authors of the business logic, rather than the mathematicians and cryptographers we rely on for the safety of regular ZKP systems.
But that might be OK for your business problem. Ultimately, you always must trust somebody. The only question is who. Sadly, nothing in life is perfect: just as the mathematicians can, and have, messed up their ZKPs, the CPU manufacturers have famously shipped versions of their chips that could be hacked. Life is nothing but a bunch of risk-based trade-offs. But I don’t think most people doubt that these secure CPUs are getting more secure the more they’re researched and tested, so both approaches are genuinely legitimate.
And the advantage is that it’s usually quicker and easier to write a program for a secure CPU than it is to implement an equivalent zero knowledge proof. And platforms such as Conclave make it easier still, by letting you do it in languages like Java and Python rather than assembler or C or C++.
And this speed increase — both in terms of development time and execution time — is why I think we should start talking about ‘Hardware Accelerated Zero Knowledge Proofs’ as a key weapon in our arsenal.
Of course, if you do have access to a well tested ZKP-based solution, where proving costs are not an issue then you’re probably in the best of all worlds. I’m not proposing that ZCash’s users replatform onto Trusted Execution Environments! And the Corda community is going to benefit hugely from the investment made by ING’s ZKP team.
But if you’re looking at an as-yet unsolved problem, wondering which way to go, the calculation is different. If you have a problem that a traditional Zero Knowledge Proof could solve, it means you now have an additional option: maybe you could write your business logic in regular high-level languages and deploy to a commodity CPU with ‘Confidential Computing’ support and go live quickly.
So perhaps one way of thinking about it is as choosing the right set of tradeoffs for your business problem.
I’m not entirely satisfied with this breakdown — and I’m sure proponents for each technology may take issue with some of my assessments! But the principle is, I think, sound: if you’re building a system that needs to prove something to a third party without revealing too much information in the process, there are a range of options available to you; there’s never been a more exciting time to solve these sorts of problems.