In a significant step forward to address fragmentation in the zero-knowledge space, Veridise has been awarded a grant from the Ethereum Foundation to build an open-source Intermediate Representation (IR) for ZK circuit languages.
We call this LLZK — a flexible framework inspired by LLVM, designed to unify diverse front-end languages and backend architectures, eliminating the need to reinvent solutions. The framework aims to unify and streamline circuit compilation, improving both maintainability and security across the ZK landscape.
The overall workflow of compiling circuits using LLZK, our IR. It consists of three main components: frontends, transformations/optimization passes, backends.
Addressing fragmentation in the ZK ecosystem
zkSNARKs and zkSTARKs are a mainstay of the blockchain industry, securing billions of dollars in the form of rollups and privacy preserving blockchains/applications. At the same time, both are a relatively new technologies and we are seeing rapid development in the underlying methods and related tooling. For example, the ZK ecosystem is filled with a plethora of circuit DSLs/frameworks including Circom, Halo2, Arkworks, Gnark, Zirgen, etc with new tooling or custom languages being created frequently to take advantage of improvements in the underlying SNARK algorithms.
While this rapid development is exciting, there is a large degree of fragmentation in the ecosystem. Unlike mainstream languages, every ZK language has an end-to-end compiler which converts a circuit/program into a particular set of constraints. We see this fragmentation as having two negative consequences: Poor maintainability and limited security tooling.
Poor maintainability
If the research community introduces a new type of proving system, then language developers will need to modify their compiler to support that system. In fact, if languages do not quickly add support, developers may create their own DSL or fork an existing language to support it, further fragmenting the development ecosystem. Furthermore, the process of adding a new translation phase for a new type of arithmetization can introduce bugs as well. Yet, we believe adding support for a new arithmetization is work that can be shared across languages.
For example, to support a new arithmetization, developers need to translate constraints into a specific arithmetization scheme, which requires 1) adding logic to extract the constraints, 2) rewrite them into a normal form (e.g, R1CS) and 3) adding optimizations to make the constraints simpler.
Limited security tooling
ZK is used in security-critical applications like rollups or privacy-preserving blockchains, yet there is very limited tooling available to help ZK developers check the correctness of their circuits programs. We believe that this is (in part) due to the fact that the circuit languages are so fragmented. Existing ZK security tools (Picus, ZKAP, CIVER, CODA, Circomspect, Halo2-analyzer) support only one of Circom, R1CS or Halo2.
Supporting a new framework is oftentimes a non-trivial task as tooling developers will either need to modify their underlying tool or write translators to convert circuits written in one language into the language their tool can accept. Such work is oftentimes tedious and error-prone.
At Veridise, we’ve developed tools for ZK circuit verification (Picus, ZK Vanguard) and published academic research on zero-knowledge security.
Design goals for Veridise LLZK
To address key challenges, our IR will incorporate the following key features:
- Modularity. In order to compile and analyze large circuits, the IR must preserve modularity present in existing languages. In particular, the IR should have the ability to declare subcircuits/modules. At a high level, these components should be the equivalent of Circom components.
- Domains & Co-domains. Inputs and Outputs to circuits are overloaded terms that usually have different meanings across frameworks. This affects tools such as Picus, ECNE, Civer which reason about determinism of circuits. As such, the IR should include a notion of Domains/Co-domains for modules defined in the IR.
- Flexibility for backends. The IR (along with the surrounding infrastructure) should be designed to support different backends. In particular, we want the circuits expressed in the IR to be able to be compiled to constraints in different arithmetization formats like R1CS, AIR or Plonk. Moreover, different security tools like Picus can easily write extractors to translate ZKIR constraints into their own internal representation.
- Formal Verification. Ideally the IR should be designed so that different aspects can be formally verified — especially optimizations performed on the circuits. As such, we want to choose a tech stack that has growing support for formal verification.
- Witness Generation & Constraints. We want the ability to define both witness generation logic and constraints. Additionally, we want the ability to “split” the two into different modules.
- We also plan to include other features such as: Succinct Circuit Representation, Efficient Code Generation, Parameterized Circuits, Diagnostic Information, and Transformation & Analysis Friendly
Also, we want to design LLZK and surrounding infrastructure in a tech stack that is accessible to a large portion of developers so that they can contribute to/extend the IR as they see fit.
LLZK: A unified IR for ZK languages
To solve these challenges, Veridise is developing LLZK, an intermediate representation that standardizes circuit compilation and security analysis across ZK languages. This approach provides two key benefits: consolidation compilation and unified circuit analysis.
Consolidated compilation
Once a ZK circuit is compiled into an IR, the IR compiler handles constraint extraction, rewriting, optimization, and the generation of both the prover and verifier. Thus, any circuit language which compiles to the IR gets these steps for free.
Unified circuit analysis
A well-designed IR simplifies the development of program analyses that can be reused across multiple languages, aiding in both bug detection at compile time and circuit optimization. These analyses are accessible to any programming language that compiles to the IR. Additionally, advanced bug-finding and verification tools can leverage the IR to ensure circuit correctness. Writing security tooling on top of the IR allows them to have broad applicability as they can target any program that compiles to the IR for free.
Architecture
The architecture of LLZK consists of three parts: Frontend components, Transformations and Backends. Let’s revisit the same graph again.
Frontend components take as input a circuit program written in a circuit language/framework and emit a LLZK AST (Abstract Syntax Tree). They will use a library that provides an API for building and manipulating LLZK AST and serializing a LLZK AST to a file in LLZK’s intermediate representation language.
Transformations component of our workflow defines transformation passes such as optimizations, module flattening, constraint rewrites, etc.
Backends components take the resulting IR program and emit a program for a target backend e.g, convert the IR code into constraints in a particular arithmetization format or in another IR needed by a backend tool like a static analyzer or verification engine.
Technical approach and implementation overview
Veridise will develop LLZK using the **MLIR** (Multi-Level Intermediate Representation) framework, a widely adopted compiler infrastructure. MLIR’s structured approach will enable efficient circuit transformations, analysis, and optimizations.
We will first develop the LLZK library, define the core IR structure, and provide utilities for circuit compilation and optimization. Next, we will integrate with existing ZK languages and build frontends to support key circuit DSLs. Finally, we will develop a security analysis backend and translate LLZK into a format compatible with verification tools like Picus, enabling automated security checks.
Open-sourcing LLZK and the road ahead
We are grateful to the Ethereum Foundation for their support in funding the development of LLZK. With their backing, we are excited to accelerate our efforts in making LLZK a foundational tool for ZK circuit developers.
By reducing fragmentation and enabling broader security tooling, LLZK will help strengthen the ZK ecosystem and make zero-knowledge applications more secure and maintainable.
We will be open-sourcing LLZK and actively engaging with the broader ZK and Ethereum communities. We invite developers, researchers, and security analysts to contribute and provide feedback as LLZK takes shape.
Stay tuned for updates on GitHub and follow us for the latest developments!
LLZK presentation
Learn more about LLZK in Jon Stephens’ presentation at ZK Accelerate.
Editor: Mikko Ikola, VP of Marketing
