What could go wrong when starting a Zero Knowledge project?
Shit. A lot of things
Let’s have a look.
Do you even need ZK?
Zero knowledge is one of the new, trendy buzzwords. It’s not as cool as AI (yet), but ZK is already used to gain attention from investors — both in good and in bad.
ZK is complicated and difficult to implement. Using it unnecessarily in your project would be a huge waste of resources.
So the very first question I would ask myself is: do I even need ZK for my project? Surprisingly often, the eventual answer is “no”. There are many alternative (and easier) technologies available for preserving privacy.
Implementation issues
Fine. You’ve decided that you need ZK. How hard can it be?
To begin with, you need to decide what kind of ZK proving system you want to use. They all have their own characteristics, and choosing the right one for your needs requires quite some know-how.
Some proving systems focus on proving efficiency; others focus on verifying efficiency. Some have big proof sizes, some are small. Do you need a ZK-VM solution? Do you need proving in the browser? Is stand-alone proving enough for your needs?
Choosing a system with the wrong characteristics can be catastrophic. And it’s not just like choosing between Android and iPhone — the wrong system may turn out to be unusable for any potential users.
Taking it into use
Well, you can’t just take it to use. Maybe the proving system you chose requires a trusted setup? Who’s going to perform that, and how? How do you make sure the setup is performed securely?
After that, you get all the issues regarding infrastructure. Where and how do you run the provers, or how do others run them? How is all the communication managed between entities?
There are so many questions, and somebody needs to have the answers.
Shouldn’t there be an easier way?
Actually, you may not need to decide all of this by yourself. Depending on your needs, there are services that offer some of this ready-made.
Various ZK ecosystems offer their own platforms for projects. You just write your code, deploy it on their ZK blockchain, and that’s mostly it. This makes you depend on the blockchain and on the underlying ZK system, but those tend to be quite good in such battle-tested ecosystems.
There are even some ZK-rollup providers (RaaS — Rollup as a Service) where you can click a few buttons and deploy your own L2 ZK-rollup. Pretty cool!
You will suffer, regardless
The issues listed above are just the tip of the iceberg. However, countless projects have managed to integrate ZK successfully, so it’s not an impossible task. It’s just a bit difficult.
Remember that this is all bleeding-edge technology. It means that you will face issues, no matter what decisions you make. Technology, ecosystems, languages, and developer tools are evolving rapidly. What works today may not work tomorrow.
This is a huge source of frustration for many projects. But still, it’s part of the price you pay for working on cutting-edge technologies. We’ve all suffered. Join the club!
About the author
I’m a ZK and EVM freelancer. I organize ZK courses and, in general, try to educate people about ZK. Always open to new projects.
Happy to discuss anything related to this post or ZK in general — get in touch!
This post was inspired by the Ethereum Writers cohort.
