blockworks.co
Web3 has placed so much emphasis on the baseline concept of zero-knowledge technology that it now sits on a pedestal, a spotlight cast over every development. But its scalability, security and privacy benefits do not make it trustworthy by default.
People fail to recognize that zero-knowledge (zk) technology, in a Web3 context, is still fairly new and not without flaws. Developers are actively addressing zk tech’s current issues, but the innovative nature of the space means that they are often conceptualizing faster than they can build.
Continuing to put trust into zk technology without fully understanding its problems is perilous for a sustainable Web3 future. We need to thoroughly examine the technology and its potential drawbacks before blindly relying on it.
Heroes shouldn’t exist in Web3 — no technology should be put on a pedestal.
In an ideal future, zk technology will play a more integrated role in all on-chain activity. However, the technology currently exists almost as an add-on feature or accessory, rather than something that can fundamentally support on-chain execution. This is because the field and products being developed are still relatively new.
But the zk technology space has gotten to a point where it risks overcomplicating itself. There is a knowledge gap growing between zk builders and Web3 users.
Other issues facing zk tech development include optimizing time-to-market without compromising on the integrity of projects. Zk proofs and circuits currently lack accessibility, because developers need to learn domain-specific languages (DSLs) to enable further proving of these computations.
This is a very knowledge-intensive process, the perfect example being the almost one-and-a-half years between Scroll’s pre-alpha testnet and mainnet launches. By taking the time to carry out proper implementation and an audit of the code, Scroll’s time-to-market was likely set back by an intensive review process of its zkEVM circuit code implemented via some custom Halo2-related zkDSL.
This is a problem, because there are only a handful of people globally who have firsthand knowledge of DSLs and cryptography. As we onboard more developers into using advanced zk technologies, we need to ensure that each component of zk tech is independently verifiable.
Then, there is the challenge of configurability. Every necessary upgrade ends up being a complete overhaul of a freshly built system, rather than an “upgrade” in the sense of developers building onto an existing framework.
Zk-enabled projects are already working on solutions that simplify the building process for developers. This would help solve key issues including slow time-to-market, the costs behind generating proofs as an independent party, the configurability of circuits, and the demanding nature of learning specific cryptographic languages.
Read more from our opinion section: It’s time for blockchain security firms to join forces
Building simpler ways to compile code into fully functional circuits as easily as possible is crucial in ensuring the composability of a working zk-enabled application. Tools like compilers can quickly help verify the functionality of code. Developers can also use multiple coding languages to develop more efficient applications.
Continuing to fixate on scalability and security takes away from the crucial work in other issues ongoing in the field. The flaws in ZK technology are ignored simply because the industry desperately needs scalability and security, overlooking the cons of cost and complexity.
The truth is, zk technology needs to uncomplicate itself. It should be possible for developers to use the tech even if they aren’t cryptography or circuit design experts.
Zk infrastructure providers need to create tools that make building zk-enabled applications easier, and simplify the building process for developers.
Streamlining the production procedures and reducing the costs associated with infrastructure is one solution to these problems. Another could be to provide more resources and support for developers looking to onboard into the space, such as educational programs and mentorship opportunities.
At the end of the day, even with zk tech — don’t merely trust, but verify.
This goes beyond baseline transaction settlement, it should apply to the tools we use to build or compile code and this should be recognized more by developers and users to encourage integrity among projects.
We can avoid disappointment by taking a holistic view of the zk space — the future of zk promises as-of-yet untested implementations for trustlessly validating almost anything. Builders must understand that its capabilities go far beyond scalability and security.