From Theory to Practice: Unlocking the Infinite Possibilities of ZK
TechFlow Selected TechFlow Selected
From Theory to Practice: Unlocking the Infinite Possibilities of ZK
This article takes you on a journey to explore zero-knowledge proofs and uncover the new potential of ZK.
Navigating Web3 tides with focused insightsCompiled by: LXDAO
Zero-knowledge proofs (ZKPs) have emerged as a shining star in the field of data security, renowned for their exceptional privacy-preserving capabilities and even topping the list of hottest terms in the crypto industry. However, the depth and complexity of ZK technology often deter many eager learners. In this edition of the LX Talk series, we invited Guo Yu, founder of Anbii Lab, to share his insights and forward-looking perspectives. Let's revisit the highlights of this session and unlock the boundless potential of ZK 🚀
The Gap Between Theory and Practice: Where Are ZK’s Application Scenarios?
Guo Yu pointed out that among various branches of cryptography, ZK has already seen substantial practical implementation. However, compared to theoretical research, ZK’s engineering practices and rapid product iterations have led some products to adopt relatively immature protocols that haven’t undergone rigorous validation. Currently, most available learning materials on ZK are theory-heavy, primarily due to two reasons:
1. The majority of active ZK researchers focus more on theoretical work than engineering practice. The output cycle for theoretical research is significantly shorter than that of engineering development. For instance, engineers working on product refinement often come from diverse backgrounds and require considerable time to learn underlying algorithms/mathematics and apply them practically—this creates the impression that most available content is theoretical.
2. The industry is evolving rapidly with fast-paced product updates; certain engineering components may be replaced or phased out by newer protocols within specific application contexts. Although the technical barrier for ZK has lowered considerably, theoretical advancements still consistently precede practical implementations.
For those aiming to engage in ZK practice, collecting high-quality reference materials such as well-designed codebases can serve as an effective starting point—imitating, using, or making minor modifications while first understanding their purpose and operational principles. If one wishes to modify code further or add new functionalities, deeper comprehension becomes essential. Taking it a step further, building a product from scratch requires significant investment and dedicated learning. Regardless of whether focusing on theory or practice, imitation remains a pragmatic approach. As your expertise grows, so will your capacity to undertake more complex tasks. Once you understand and master the underlying principles, you’ll gain greater confidence to innovate.
Over the past decade, ZK engineering practices have made remarkable progress and continue to evolve rapidly. Meanwhile, ZK theory has entered a flourishing phase of diversification. Yet this abundance presents its own challenges—such as where and how to begin learning—especially given that cryptography involves vast, deep datasets whose purposes and algorithmic origins may remain unclear. As for real-world applications, viable use cases remain limited, with many application-level products still stuck at the proof-of-concept stage. Nevertheless, the continuous emergence of new ideas brings renewed hope. The industry needs innovation, experimentation, and exploration to identify viable paths forward.
ZK Off-Chain Applications and Monetization Pathways
Regarding monetization, Guo Yu emphasized that while ZK holds immense future potential, generating revenue ultimately depends on whether the product genuinely addresses core problems and aligns with market needs/pain points.
Currently, off-chain ZK applications with clearly defined use cases show particular promise—examples include wallets, bridges, Layer 2 solutions, and off-chain computation for smart contracts. Drawing from years of experience, blockchain has long faced well-defined challenges such as scalability and storage limitations, along with protocol-specific issues like insufficient node count and inefficient data transmission compression. Additionally, there are non-blockchain-related areas like privacy protection. However, privacy isn't purely a technical issue—it's also deeply social, involving questions about what constitutes privacy and societal acceptance levels, which reflect broader collective negotiations.
More specifically, addressing pressing issues such as Ethereum state bloat, data availability (DA), increasing validator counts, mitigating MEV (Maximal Extractable Value), enhancing on-chain contract security and complexity, and improving cross-chain bridge safety—all represent domains where ZK-powered applications hold strong development prospects.
What Is CRS, and Why Does ZK Need It?
Guo Yu explained that CRS (Common Reference String) means Prover and Verifier do not blindly trust each other but instead rely on even a single-bit consensus as a foundation for mutual trust—that is, trust built upon shared agreement.
For example, a fundamental concept in ZK is "circuits," which publicly express the computational process that both Prover and Verifier must agree upon. With the verifier knowing the circuit structure in advance, the prover computes private inputs and proves the integrity of the computation. The circuit itself must be public, though input parameters can remain hidden from the verifier. This circuit forms part of the common consensus, meaning both parties must agree on it beforehand—and according to definition, this agreed-upon circuit should reside within the CRS. Most current zero-knowledge proof protocols—particularly ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge)—include a CRS component.
In elliptic curve-based systems, two types exist: One, like Groth16, involves a trusted setup phase—a secure multi-party computation protocol—which finalizes and embeds ("burns") the consensus circuit into the system. Another type, such as Marlin or Plonk, doesn't require burning the full circuit but still necessitates pre-committing certain consensus elements.
Another category based on elliptic curves relies on the hardness assumption of the discrete logarithm problem (ECDLP). These require transparent setup, which still demands prior consensus—for instance, selecting a specific elliptic curve, key generation algorithm (Generator), and prime numbers P, Q. Similarly, hash-based protocols like Stark and Risc Zero (hash-based zkSNARKs) also require CRS, encompassing choices such as the selected hash function and Reed-Solomon codes (RS codes). Strictly speaking, all these components fall under the scope of CRS.
In summary, CRS is essentially mandatory, though its contents vary significantly across protocols. Its primary purposes typically include reducing communication overhead and minimizing proof size, although different protocols implement it differently.
How Real-World Requirements Translate into ZK Polynomial Expressions
From a theoretical standpoint, Guo Yu noted that realizing polynomial representations in ZK requires computation—whether for scaling or privacy—that must be expressed via appropriate circuits. Moreover, this computation must be fixed—not only in algorithm but also in scale. When an algorithm reaches a deterministic stage where computational load can be easily decomposed, it becomes much easier to operate on, a process known as “writing circuits.”
With deeper research into ZKEVM and the rapid advancement of ZKVM stacks, free-to-use open-source zero-knowledge computing platforms such as Risc Zero, SP1, and zkWASM have emerged. These enable developers to build ZK applications directly through Rust or custom code without manually constructing circuits, making it increasingly straightforward to ZK-ify business logic.
Beyond writing circuits, another approach leverages the RAM (Random Access Machine) model, akin to running a virtual machine. Here, instead of writing circuits, developers define state transitions. Effectively translating business logic into efficient state transitions—or even lightweight or direct polynomial expressions—depends heavily on individual skill and accumulated experience.
Nonetheless, there remains a learning curve—even circuit writing has its barriers.
Highlights from the Q&A Session
Why Do We Need ZK?
Guo Yu believes there is currently a lack of large-scale applications demonstrating ZK’s usability and effectiveness. However, ZK offers a powerful way to establish trust and stands out in cryptography as one of the few foundational tools designed specifically to address trust issues. Furthermore, during blockchain’s evolution, numerous challenges have arisen—such as a sharp decline in node count and Ethereum state explosion—that ZK could help resolve. Thus, ZK plays a crucial role in both present and future blockchain ecosystems.
At the same time, ZK also needs blockchain: it presupposes the existence of trust, followed by trust interactions and protocol engagements. Blockchain serves as an indispensable element in ZK’s trust cold-start phase. The two complement each other and are mutually dependent.
Getting Started with ZK: Learning Tips and Experience Sharing
Guo Yu shared that his initial motivation stemmed from a deep interest in theoretical foundations—he wanted to fully understand what ZK is and why it works. For beginners, he recommends studying academic papers and foundational resources to build essential knowledge and pursue in-depth learning. Over time, consistent accumulation leads to breakthroughs. Many papers lack clear context or contain mixed quality information, so repeated reading is often necessary for smooth comprehension.
For job seekers, gaining hands-on experience in circuit design is particularly practical. Engage with high-quality project codebases, practice imitating circuit designs, and summarize experiences to form personal knowledge repositories. You might discover brilliant insights in unexpected corners of existing code.
Additionally, pay attention to non-professional enthusiasts in the community who often publish accessible tutorials or share learning journeys. However, given the fast pace of industry development, always check publication dates and maintain a critical mindset when evaluating such content.
Those interested in theory should adopt a focused, bottom-up approach—master a narrow area first before expanding outward. Depth-first search (DFS) learning proves more effective than breadth-first search (BFS). To find reliable, in-depth resources or papers, collaborative study (“co-learning”) is highly beneficial. Learning alone is challenging; discussing deeply with like-minded peers greatly enhances sustainable and effective exploration.
How Proficient Must One Be in ZK to Land a Job?
Guo Yu believes now is the best time to start applying. Even if unqualified initially, reach out anyway—many roles have public requirements. Try contacting teams to assist with code improvements or bug hunting. There's a significant shortage of skilled engineers, and ZK evolves quickly, so lack of experience isn’t a major obstacle. In fact, due to rapid technological shifts, newcomers face fewer disadvantages.
If We’re Using a ZKVM Like Starknet (STRK), Do We Still Need to Write Circuits?
Guo Yu clarified that current VMs provide special instructions or interfaces for system calls. Directly compiling repeated computations into standard VM instructions causes significant bloating. Therefore, frequently used operations are typically circuit-optimized. Circuitization shortens the trace length required for VM proofs and enables preprocessing optimizations, making the process far more efficient than raw tracing.
In some advanced proof systems, even when executing the same algorithm multiple times (e.g., hashing ten times with varying parameters), techniques exist to parallelize these ten circuits, yielding substantial performance gains. Modern VM design principles could allow users to write custom circuits for specific functions and integrate them seamlessly—though currently, most functionality remains VM-provided.
Moreover, emerging techniques like folding schemes can compress repeatedly chained circuits into a single instance, drastically reducing memory usage during proof generation—but impose higher demands on circuit-writing skills. In conclusion, whether to learn or write circuits depends strongly on your goals. Theoretically, blind compilation via ZKVM is possible, allowing direct invocation without manual circuit writing.
Besides Blockchain, Are There Other Potential Directions for ZK?
Guo Yu suggested privacy protection as a potential direction, though demand remains questionable—even in Web3, user concern for privacy is limited, let alone in traditional industries. Academia explores several non-crypto integrations, such as zero-knowledge machine learning (ZKML), ZK databases, and anonymous voting systems. However, whether these truly solve real-world pain points remains uncertain. Progress tends to accelerate when driven by urgent, concrete needs. For example, ZKEVM development was motivated by EVM compatibility requirements on Layer 2. Despite EVM's imperfections, transferring related technologies to ZKEVM yielded notable success.
At This Stage of Blockchain Development, What Value Do Technology and Use Cases Respectively Offer?
Guo Yu responded that within the Crypto ecosystem, ZK offers numerous utilities—such as decentralized identity (DID) authentication and privacy preservation in social networks. The key lies in identifying a compelling use case that resonates with actual user needs and gains traction. Those building applications should closely follow ZK developments, as current technological capabilities are already sufficient—or nearly so—for simple scenarios.
Audience member Shi Tou added that under current operational models, establishing trust or consensus consumes enormous bandwidth and storage resources. ZK can boost efficiency exponentially, giving it immense technical value. Once technical value is demonstrated, application value naturally follows.
Guo Yu补充 noted that a current challenge in ZK development is the absence of clear direction, making it difficult to predict which path will succeed. With numerous diverging research branches, it's unclear which fork will thrive or whether any will converge. This creates a wide gap between theorists and practitioners. Theorists often struggle to grasp real-world pain points and end up inventing hypothetical scenarios for papers. At the same time, rising entry barriers make it harder for product and business developers to understand what ZK can actually do. Practitioners should familiarize themselves with basic concepts and common tools—understanding what typical ZK tools and documentation can prove, the scale of logic they handle, and computational limits. Deep expertise isn’t required; knowing the basics—what ZK can and cannot efficiently solve—is sufficient. Ultimately, synergy between both sides is vital to advancing the blockchain ecosystem.
Conclusion
Through this LX Talk session, we hope participants now possess a more comprehensive and nuanced understanding of zero-knowledge proofs—their development, practical applications, and pathways to entry. As the industry continues to grow and ZK technology innovates and breaks new ground, we believe ZK will reveal tremendous potential and expansive application horizons. This momentum will also inject fresh vitality into the crypto sector and the broader Web3 landscape. Looking ahead, we look forward to continuing our journey together—exploring ZK, shaping its future, and co-building a safer, more efficient, and transparent digital world!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@LXDAO_Official
