Why do people overly trust zero-knowledge technology?

Exploring the Prevalent Reliance on Zero-Knowledge Technology

Author: Misha Komarov, Blockworks; Translation: Song Xue, LianGuai

Web3 places such importance on the basic concepts of zero knowledge technology that it has now become a foundation and a focal point for every development. However, its scalability, security, and privacy advantages do not make it trustworthy.

People fail to realize that in the Web3 environment, zero knowledge (ZK) technology is still relatively new and not without flaws. Developers are actively addressing the current issues with ZK technology, but the nature of innovation in this field means that conceptualization often outpaces construction.

Continuing to trust ZK technology without fully understanding its issues is dangerous for the sustainable future of Web3. Before blindly relying on this technology, we need to thoroughly examine it and its potential drawbacks.

• Bloomberg reveals US government and Binance settlement plan $4 billion fine, CZ faces criminal charges in the US.
• LianGuai Encyclopedia | PYTH Airdrop Finally Arrives What is the Pyth Network?
• Flip, flip, and flip again The story of the fight within OpenAI

No heroes should exist in Web3 – no technology should be idolized.

In an ideal future, ZK technology will play a more integrated role in all on-chain activities. However, currently, this technology exists mostly as an add-on or accessory rather than something that fundamentally supports on-chain execution. This is because the field and products being developed are still relatively new.

But the ZK technology field has progressed to the point where it faces the risk of excessive complexity. The gap in knowledge between ZK builders and Web3 users is growing.

Other challenges that ZK technology development faces include optimizing listing times without compromising project integrity. ZK proofs and circuits currently lack accessibility, as developers need to learn specific domain-specific languages (DSLs) to further prove these computations.

This is a knowledge-intensive process, as evidenced by Scroll’s almost one and a half years between the pre-alpha testnet and mainnet launch. By taking the time for proper implementation and code review, the listing time of Scroll could potentially be hindered by an in-depth review process of the zkEVM circuit code implemented with custom Halo2-related zkDSL.

This is a concern because only a few individuals globally possess firsthand knowledge of DSLs and cryptography. As we enable more developers to use advanced ZK technology, we need to ensure that each component of ZK technology is independently verifiable.

Then, there are the challenges of configurability. Every necessary upgrade ultimately becomes a thorough overhaul of the newly constructed system rather than a mere “upgrade” on the existing framework built by developers.

Projects supporting ZK are already dedicated to developing solutions that simplify the development process for developers. This will help address critical issues, including slow listing times, the cost of generating proofs as an independent party, circuit configurability, and the requirement to learn specific cryptographic languages.

Building a simpler way to compile code and fully functional circuits is crucial for ensuring the composability of ZK-supporting applications. Tools like compilers can quickly help validate the functionality of the code. Developers can also use multiple coding languages to develop more efficient applications.

Continuing to focus on scalability and security will impact the key work of other ongoing issues in this field. The flaws of ZK technology have been overlooked simply because the industry urgently needs scalability and security, ignoring the drawbacks of cost and complexity.

The fact is, ZK technology needs to make itself simple. Even developers who are not cryptography or circuit design experts should be able to use the technology.

ZK infrastructure providers need to create tools that make it easier to build ZK-supporting applications and simplify the development process for developers.

Simplifying production programs and reducing costs associated with infrastructure is one way to address these issues. Another possible approach is to provide more resources and support to developers who wish to enter this field, such as educational programs and guidance opportunities.

In the end, even with ZK technology, don’t just trust, but also verify.

This goes beyond the scope of baseline transaction settlement, it should apply to the tools we use to build or compile code, and developers and users should be more aware of this to encourage integrity between projects.

We can avoid disappointment by fully understanding the ZK space – the future of ZK has the potential to validate almost anything in a trustless manner. Builders must understand that its capabilities go far beyond scalability and security.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!