• Network scale. Both networks have reached a genuinely scaled phase for proofs and requests. Boundless has created a high-frequency open marketplace that absorbs substantial compute; Succinct spans many major protocols with steadily rising proof demand. Net-net, supply and demand are expanding in tandem, with activity and throughput trending up.
• Economic models. Boundless uses a reverse Dutch auction: the price starts at a minimum (often 0 ETH), then rises linearly to a cap and stays there until the lock deadline. On beta mainnet today, provers frequently bid 0 on the prove fee and instead compete to lock orders — often using MEV-style tactics to win first inclusion.
  Succinct runs a real-time auction denominated in $PROVE: provers bid a per-unit compute price; the lowest bid wins (ties are randomly selected), and each job includes a fixed base fee. Provers must stake $PROVE to participate; failure to deliver on time is penalized (slashing).
• Miner appeal (current earnings). On Boundless, jobs typically pay near zero in direct fees; rewards primarily come from leaderboard points redeemable for $ZKC. Succinct pays out $PROVE immediately (base fee + metered compute), which is tradable — so near-term economics are clearer.
• Who’s a better fit right now? If you have GPU but limited staking capital, Boundless offers low entry barriers and an open network to bank future token rewards. If you can purchase and stake $PROVE, Succinct offers more immediate per-job rewards in $PROVE and can be more lucrative near-term.

1. Network Snapshot: Scale, Trends, and Centralization

At a glance, Boundless shows broader participation and openness, with many small and mid-sized nodes contributing — implying greater decentralization. Succinct currently has fewer provers; early compute may concentrate among a smaller set of high-reputation, higher-bid nodes.

From a growth-trend perspective, as more blockchains and applications integrate with these networks, proof demand should continue to grow rapidly, and both participation and throughput are likely to rise accordingly.

Boundless’s compute contribution appears long-tailed — work is spread across a wider set of miners, limiting any single node’s share. Succinct’s higher entry bar makes the network more concentrated in the early stage: only nodes with sufficient stake and performance consistently win jobs, favoring “the strong get stronger.” Over time, as more participants acquire and stake $PROVE, the number of active provers may rise.

2. Economic Models: Auction & Incentive Design

The two networks differ fundamentally in pricing and incentives.

Boundless: Reverse Dutch Auction

When a user submits a ZK proof request, Boundless prices the job via a reverse Dutch auction:

• The requester specifies a min/max price and timing parameters.
• The price starts very low (often 0) → rises linearly to an upper bound → if no one locks the job by the lock deadline, it expires.

Early on, with token incentives and abundant supply, competition pushed most jobs to clear at 0 fee — provers did unpaid work to farm token rewards. Boundless has earmarked 5,000,000 $ZKC (0.5% of supply) for test incentives; in Season 1 and Season 2, weekly pools are 0.1%. Each prover earns points based on total compute cycles, success rate, and speed, then shares the pool pro-rata after the event. This “work now, tokens later” model encouraged provers to aggressively take jobs and undercut prices, producing a near-free proof market.

Succinct: Staked Real-Time Auction

Succinct splits job cost into two parts:

• A fixed base fee; and
• A per-PGU (proof gas unit) bid set by real-time auction. The network assigns the job to the lowest qualified bidder (ties randomly broken).

Total fee = Base Fee + Bid Price per PGU×PGUs consumed

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Provers must stake $PROVE to bid. Staking raises the bar and ensures skin in the game: if a winner misses the deadline, part of their stake is slashed. This “pay-for-work” design creates a closed-loop token economy: requesters buy compute in $PROVE, provers earn $PROVE by delivering, and stakers support security and share rewards.

Bottom line: Boundless maximizes openness and competitive pressure — in today’s oversupplied phase, fees compress toward zero and token incentives backfill. Succinct balances incentives and reliability via staking and immediate payment. Boundless is deferred-incentive; Succinct is immediate-incentive.

3. Revenue & Cost Analysis

3.1 Revenue

Boundless. Today, mining on Boundless yields little to no direct ETH revenue. Intense competition plus extra incentives push most auctions to 0 fee — i.e., miners earn almost nothing per job.
The main upside is leaderboard points redeemable for $ZKC later. A total of 5 million $ZKC (0.5%) is allocated for test incentives. Your share depends on your relative points — computed from cycles completed, success rate, and peak throughput. Strategy-wise, miners should take more jobs, do more work, and accumulate cycles — even if a given job pays zero — to maximize their fraction of the final pool. Note the uncertainty: $ZKC’s future value is unknown and distribution comes later, so current work is a strategic investment.

Succinct. Each completed proof immediately pays $PROVE, so there’s direct cash flow.

Revenue per job = Base Fee + Bid Price per PGU×PGUs

Two distinct bidding strategies tend to emerge:

1. High-volume, low-margin. Bid the per-cycle price very low (near zero) to increase win rate and effectively farm base fees across many small jobs.
2. Fewer, high-margin “big jobs.” Quote a higher unit price for large jobs; leverage strong hardware to earn sizable variable fees.

In practice, many provers currently undercut to secure jobs and at least capture the base fee plus small variable fees — behaving like “base-fee farmers.” For urgent or heavy proofs, requesters often pay higher rates to reduce latency, creating upside for high-performance miners. Overall, Succinct miner earnings hinge on $PROVE’s market price and bidding strategy; because $PROVE is liquid, Succinct offers clearer, near-term economics.

3.2 Participation Costs

Boundless. Entry is nearly permissionless: anyone with suitable hardware (primarily GPU) can join — no network-specific token staking required, and thus no stake lockup risk. However, because auction prices are near zero, miners must manage electricity and hardware costs carefully: at 0 fee, you’re effectively mining at a loss unless expected $ZKC value compensates later. The good news: with no eligibility barriers, even modest rigs can win small jobs (win rate depends on bidding and competition). In short, Boundless’s main barrier is hardware capex/Opex; economic and policy barriers are low. (Note: things may change at mainnet.)

Succinct. The bar is higher. You must stake $PROVE to register as an active prover — tying up capital and bearing token price risk. If slashed (e.g., late or failed delivery), you take an immediate loss. Competition is intense: performant nodes often bid very low, so weaker hardware or high latency may lead to few wins. The network is more concentrated early; established operators dominate. Succinct suits professional providers with strong engineering and capital, rather than casual miners.

4. Conclusion

Shared direction. Both Boundless and Succinct aim to turn “producing and verifying ZK proofs” from a heavy, in-house operation into on-demand compute — like power or bandwidth — matched by market mechanisms. Boundless maximizes open access; Succinct embeds staking + price discovery for reliable delivery. Different paths, same goal: let applications pull proof capacity on demand — as easily as calling an API.

Reliability vs. decentralization. Openness invites variance; constraints raise entry costs. Boundless lowers barriers to gain scale and long-tail participation, using market penalties/redistribution to curb bad behavior. Succinct front-loads professionalism and reliability via staking and slashing — more concentrated but controllable in the near term. These designs are not mutually exclusive: as demand grows and tooling matures, open networks will add quality signals and reputation, while staked networks can decentralize via pooling and delegation.

1. Post-Quantum Security: Labrador is a lattice-based zkSNARK system designed to be secure against future quantum computers, offering a robust solution for long-term privacy and scalability in blockchain systems.
2. Efficient Proofs: It produces succinct proofs (~50 KB) for large computations using a recursive compression technique, maintaining efficiency while being quantum-resistant.
3. Modular and Transparent: Unlike traditional SNARKs, Labrador doesn’t require a trusted setup, providing transparency and scalability for future-proof blockchain applications.
4. Future Potential: Labrador strikes a balance between security and efficiency, making it ideal for use cases that prioritize post-quantum safety, with further optimizations expected in upcoming versions.

Introduction

With the rapid advancement of zero-knowledge (ZK) technology, a new project called Labrador has emerged, promising to revolutionize how we think about secure proofs in the post-quantum era. Labrador is more than just a cute name –first practical lattice-based zkSNARK (Zero-Knowledge Succinct Non-interactive Argument of Knowledge).

In simpler terms, it’s a system for proving things without revealing secrets, built on advanced math that even future quantum computers can’t easily break. ZK enthusiasts have been excited about Labrador because it offers compact proof sizes (around 50 KB) while relying solely on post-quantum secure assumptions (specifically, lattice cryptography). This project was introduced by cryptographers in 2023 and has quickly become an important tool in the ZK space, already finding use in areas like post-quantum signature aggregation.

In this article, we will explore Labrador’s design and approach in depth — from its proving system and novel cryptographic techniques to how it might fit into modular blockchain architectures and data availability layers. We’ll also compare Labrador with other ZK ecosystems to understand its unique place in the landscape. Our goal is to explain these complex concepts in plain language, using analogies and clear examples, so that even readers without a formal math or physics background can grasp the big ideas behind Labrador.

Why Post-Quantum ZK Matters

Before diving into Labrador itself, it’s important to understand the context and motivation behind it. Today’s popular ZK proof systems — such as many SNARKs used in blockchain projects — often rely on classical cryptographic assumptions like the hardness of elliptic curve discrete log problems. These assumptions work well against current computers, but a sufficiently powerful quantum computer in the future could break them using algorithms like Shor’s algorithm (which can solve discrete log and factor large numbers efficiently).

In other words, many of our favorite SNARKs that use elliptic curves or similar techniques would be vulnerable in a post-quantum world On the other hand, STARKs and some other proof systems avoid elliptic curves by using only hash functions (treated as “random oracles”), which are believed to resist quantum attacks if their parameters (e.g. hash sizes) are large enough.

However, those “hash-based” proofs tend to have much larger proof sizes and slower performance — a trade-off for being quantum-safe. This is where lattice-based cryptography comes into play. Lattice problems are a class of math problems believed to be hard even for quantum computers, and they’ve become the foundation of many post-quantum cryptographic schemes (you might have heard of post-quantum encryption and signature algorithms standardized by NIST, many of which are lattice-based).

In the zero-knowledge realm, researchers have been working on lattice-based proof systems to combine quantum resistance with efficiency. The Labrador project is a culmination of these efforts, offering a proof system that is not only post-quantum secure but also succinct and efficient. By using lattices, Labrador aims to give us the best of both worlds: the peace of mind that our proofs will hold up against quantum adversaries, and the practicality of small proofs and reasonable verification times. For ZK enthusiasts, this means future-proofing privacy and scalability solutions on blockchains and beyond.

Labrador’s Design at a Glance

At its core, Labrador is a zkSNARK — meaning it produces succinct proofs that a statement is true without revealing why it’s true. What sets Labrador apart is how it produces those proofs. Traditional SNARKs like Groth16 or PLONK rely on elliptic curve pairings and often require a trusted setup ceremony. STARKs, on the other hand, use only hashes and no trusted setup, but their proofs are larger (hundreds of kilobytes or more) due to the Merkle Tree opening proof and FRI.

Labrador introduces a new proving system based on lattice cryptography, specifically the hardness of the Module-SIS problem (we’ll explain this shortly). This allows Labrador to be transparent (no trusted setup) and post-quantum secure, similar to STARKs in those respects, but with proof sizes that are significantly smaller than earlier post-quantum . In fact, for a large arithmetic circuit , a Labrador proof is only on the order of 50–60 KB at 128-bit . That’s roughly an order of magnitude smaller than comparable quantum-safe proofs from previous techniques (like hash-based Aurora or Ligero proofs).

How does Labrador achieve this? The clue lies in its name: LaBRADOR stands for “Lattice-Based Recursively Amortized Demonstration of R1CS.” The protocol is built in two parts — a base proving protocol and a recursive compression step — that together yield a tiny proof regardless of the original computation size. The base protocol generates an initial proof that is somewhat large, but then Labrador repeatedly applies a recursion to this proof, each time “folding” or compressing the proof further. After recursive steps (which in practical terms might be ~7 rounds for typical cases), the proof size becomes essentially constant.

This is a huge deal — it means even very complex computations can have a proof that is small enough to post on a blockchain. However, nothing comes entirely for free: one trade-off is that Labrador’s verifier (the algorithm that checks the proof) has to do linear work in the size of the computation. In other words, verifying a Labrador proof still takes time proportional to the original circuit size, which is slower than the near-instant verification of traditional SNARKs.

Despite this drawback, Labrador’s design is a milestone because it shows a viable path to practical quantum-resistant ZK proofs with succinct sizes. Its design is modular, meaning the core proof construction (the recursive amortization of R1CS constraints) can potentially integrate with other components or improvements (and indeed it inspired follow-up work like Greyhound, which refines the polynomial commitment aspect).

At a glance, here are Labrador’s key features:

• Post-Quantum Security: Built on lattice assumptions (Module-SIS) believed to be secure against quantum attacks.
• Transparency: No trusted setup required; anyone can verify proofs with publicly known parameters (only random lattices needed).
• Succinct Proofs: Near-constant proof size (~50 KB) even for large computations, thanks to recursive proof compression.
• R1CS Compatibility: Can prove arbitrary computations expressed as Rank-1 Constraint Systems (like many SNARKs do), making it broadly applicable.
• Modular Design: Splits into a base protocol and recursive steps, which opens the door to swapping in improvements (e.g., better polynomial commitments) without redesigning from scratch.

This high-level view shows why Labrador is exciting — it promises the level of scalability and efficiency we expect from SNARKs, while also being ready for a post-quantum world and avoiding the pitfalls of trusted setups.

How Does Labrador’s Proving System Work?

Let’s unpack, in plain terms, how Labrador generates a proof. We’ll avoid formal math, instead using an analogy of “proving a large puzzle is solved by breaking it into smaller puzzles.” Imagine you have a massive jigsaw puzzle (this represents the original computation or circuit you want to prove). Proving you solved it directly would be hard to verify due to its sheer size. Instead, Labrador’s approach is: solve the puzzle, then compress the evidence of that solution step by step until it’s tiny. Here’s a step-by-step rundown of Labrador’s proving process:

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Commit to the Witness (Ajtai Commitment): First, the prover hides the solution to the puzzle (the secret witness for the computation) in a kind of cryptographic “safe” known as an Ajtai commitment. This is like mixing your puzzle’s solution pieces with some random noise so that you send only a locked box of mixed pieces to the verifier. The verifier can’t see your actual pieces (so zero-knowledge is preserved), but the commitment “locks in” your solution — you can’t change it later without breaking the box, which is assumed to be computationally infeasible because of the lattice (Module-SIS) hardness. In essence, an Ajtai commitment uses a large random matrix (publicly known) and multiplies it by your secret vector (the witness) to produce a commitment. This commitment has a homomorphic property (meaning operations on the commitment correspond to operations on secret vector that will be very useful later.

Prove Constraint Satisfaction (Base Protocol): Next, the prover needs to convince the verifier that the secret witness vector actually satisfies all the required constraints of the puzzle without revealing secret vector. Labrador’s base protocol does this through an interactive proof (in actual implementation, it will be transformed into a non-commutative form through the Fiat-Shamir transformation.). In simple terms, the prover and verifier engage in a series of steps: the verifier tosses some random challenge sand the prover responds with information that should only make sense if all the constraints hold. One clever trick here is the prover aggregates many constraints into one using the random challenges.

By the end of the base protocol, the prover effectively furnishes a proof (consisting of some committed values and responses) that all constraints are satisfied and the witness has a small “norm” (meaning the solution numbers aren’t huge, which is important for security).

Recursive Proof Compression: Here comes the magic — Labrador uses recursion to shrink the proof further. The insight is that the proof generated by the base protocol has its own internal structure and constraints (the things the verifier would check can themselves be viewed as a kind of smaller puzzle). Labrador literally takes the proof from step 2 and treats that proof’s data as a new “witness” to prove!. In other words, we get a second proof that certifies “the first proof was correctly formed and valid.”

Verification: The verifier checks the final proof by performing a series of lattice-based computations defined by the protocol. Without diving into math, the verifier basically ensures that all the commitments and responses align correctly — akin to checking the solution of that last tiny puzzle which, by construction, guarantees the big puzzle was solved.This is a known limitation: unlike classic SNARKs that might verify in constant time, here we trade some verification speed for the benefit of post-quantum security and no trusted setup. However, linear time for a verifier (which is typically a smart contract or a blockchain node in a ZK-rollup scenario) might be acceptable for moderate N, and research is ongoing to improve this (for instance, newer schemes like Greyhound target sublinear verification).

Throughout this process, zero-knowledge is maintained — the verifier learns nothing about the actual witness (solution) besides the fact that it satisfies the constraints. All the clever random challenges, commitments, and algebra ensure that any deviations from a correct witness would lead to a detectable inconsistency with high probability, but a correct witness produces a perfectly valid proof that the verifier accepts. It’s like compressing a file repeatedly; each time you compress, the file gets smaller, and after enough iterations, you have a tiny archive that still, when opened layer by layer, contains the full original data.

Novel Cryptographic Techniques Behind Labrador

Labrador’s power comes from some ingenious cryptographic building blocks, primarily drawn from lattice-based cryptography. Let’s demystify a few of the novel techniques it uses (without going too deep into math):

• Module-SIS Problem (Lattice Assumption): The security of Labrador is founded on the hardness of the Module Short Integer Solution (Module-SIS) problem. This is a lattice problem. In simpler terms, SIS asks: given a bunch of big numbers (or vectors) that are essentially random, can you find a combination of them with small coefficients that adds up exactly to zero? It’s like having a set of very large puzzle pieces and asking if you can very delicately balance some of them (using small weights) so they cancel out. This is believed to be extremely hard, even for quantum computers. Module-SIS is just a fancier version where those numbers are not plain integers but polynomials on prime filed (imagine each “number” is actually a polynomial, which adds a structured twist to the problem). Because no efficient algorithm is known to solve Module-SIS (unless we crack fundamental lattice problems like SVP, which is considered unlikely), it provides the unbreakable “lock” for Labrador’s commitments and proofs. In contrast to assumptions used in traditional SNARKs (like elliptic curve discrete log), Module-SIS is post-quantum safe and well-studied in academic literature.
• Norm Bounds and “Short” Vectors: A recurring concept in Labrador’s protocol is that the witness vectors must be “short” (have small norm). Intuitively, this means the secret numbers aren’t astronomically large — they’re within a manageable range. Enforcing a norm bound is important because the SIS problem’s hardness relies on finding short solutions. If arbitrarily large coefficients were allowed, trivial solutions exist (just take huge coefficients to cancel things out). In the proof, the prover demonstrates that their witness respects these bounds (often by clever constraint design and random challenges that would blow up if the norm was too high). For a non-math analogy: think of the witness as a path through a dense forest. The norm bound ensures the path doesn’t wander too far off — it stays within a “short” distance. The verifier can be confident that the prover didn’t take some wild detour (which might represent an invalid solution) because that would violate the known bound.
• Quadratic Equations (Rank-1 Constraints): Labrador’s constraint system uses quadratic equations — essentially inner products and constant terms. This is actually similar in spirit to how R1CS works in typical SNARKs (an R1CS constraint is a quadratic equation equating a product of linear combinations to another linear combination). By working with quadratic forms in the lattice setting, Labrador can encode arbitrary arithmetic circuits. The reason quadratic (degree-2) constraints are used is that they are expressive enough to capture complex logic (you can multiply variables) but structured enough to be proven succinctly. The fact that the commitments are linear and the constraints are quadratic is key — it allows recursion because the verification conditions (which involve quadratic checks of committed values) can themselves be turned into similar quadratic constraints at the next layer.

These cryptographic techniques are quite advanced under the hood, but the takeaway is that Labrador blends them to create a synergy: lattice commitments give strong security and linearity, recursive amortization gives succinctness, and conventional techniques like Fiat-Shamir ensure practicality (non-interactivity). The design of Labrador is a testament to how modern ZK research is combining ideas from different domains — here we see number theory, linear algebra (matrices and vectors), and theoretical computer science (interactive proofs) all working together. And notably, everything in Labrador rests on assumptions that are believed to be safe in the quantum age, which is a major selling point as we move towards the future.

Comparing Labrador with Other ZK Ecosystems

The ZK landscape is vibrant, with various proof systems and projects each having their own strengths and trade-offs. Let’s compare Labrador with some of the notable ones to get a sense of where it stands:

• Labrador vs. Classical SNARKs (Groth16/PLONK/etc.): Traditional SNARKs like Groth16 have tiny proofs (around 1–2 KB) and extremely fast verification (a couple of pairings checks). However, they require a trusted setup (which can be complex and carries a security risk if the setup is corrupted) and rely on cryptographic assumptions (elliptic curve pairings) that are not post-quantum secure. Labrador, in contrast, has larger proofs (~50KB) and slower verification (linear time), but no trusted setup and quantum resilience. In a current setting (without quantum computers yet), Groth16 or PLONK might be more practical for on-chain verification due to their speed and size. But Labrador offers a future-proof alternative — you’d trade some performance and convenience now to avoid needing a complete overhaul of your system later when quantum computers arrive. Also, Labrador’s transparency simplifies deployment (no need for multi-party ceremonies to generate keys). A project like Zcash, for instance, famously used Groth16 with a toxic waste ceremony; in a hypothetical Zcash-like application in the future, Labrador could eliminate that ceremony entirely.
• Labrador vs. Other Emerging Post-Quantum ZK Systems: Labrador is not alone — the post-quantum ZK space is hot. For instance, Greyhound (2025) is a newer protocol that actually builds on Labrador’s approach but focuses on the polynomial commitment part of the proof. Greyhound achieved a scheme with sublinear verification and similar proof sizes It’s not a full proof system by itself (more a component), but it indicates the direction: improving on Labrador’s weaknesses (namely verification cost). Dan Boneh even remarked that these developments mark the first time a post-quantum SNARK might outperform a pre-quantum one in some aspects. This is important context for Labrador: it kick-started a “lattice SNARK race,” and within a couple of years, we already see rapid improvements. So, Labrador today should be viewed as the foundation — a proof of concept that practical lattice SNARKs are possible — and not the end of the story. We can expect future versions to be even more efficient.
• Use Case Perspective: Different ZK ecosystems target different use cases. For example, ZK-rollups on Ethereum (like zkSync, Scroll) aim for immediate practical scalability and thus use proven SNARK tech (PLONKish schemes) for speed on existing hardware. Privacy-focused chains (like Aztec or Penumbra) also use existing SNARKs for efficiency and UX. Labrador might not replace those in the short term, because it’s more forward-looking. However, for any application that values long-term security and can tolerate a bit more overhead, Labrador is compelling. Imagine a government or institution wanting a ZK system that will remain secure for decades — a post-quantum proof system is highly attractive for that scenario.

In summary, Labrador distinguishes itself by its post-quantum pedigree and succinct proof size, while it inherits some downsides like heavier verification from its lattice-based nature. Its competitors either sacrifice post-quantum security for speed (classical SNARKs, Halo) or sacrifice proof size for post-quantum security (STARKs). Labrador strikes a middle ground: quantum-safe and relatively efficient in proof size, at the cost of verifier workload. As the technology matures, it’s possible this middle ground will only improve, closing the gap with or even surpassing the older methods. For ZK enthusiasts, it’s an exciting development — it means the ecosystem is preparing for a future where both security and performance can be achieved without compromise.

Conclusion

The advent of Labrador signals a new chapter in the zero-knowledge story — one where post-quantum security and practicality intersect. For years, ZK enthusiasts have seen a trade-off: we had extremely efficient SNARKs that might one day be broken by quantum computers, and we had quantum-proof systems that were too impractical for real use. Labrador’s lattice-based approach shows that this gap can be bridged. It introduces a proving system that, through creative recursive design and lattice cryptography, achieves compact proofs without relying on conjectures that quantum machines could shatter. Writing a Medium-style article about such a technical subject posed the challenge of preserving depth while avoiding formalism. We navigated concepts like Module-SIS, recursive proof amortization, and data availability by using analogies and clear language — describing commitments as locked boxes, proofs as puzzles, and blockchains as layered frameworks. Hopefully, this dual-language exploration has made the Labrador project more accessible to a broader audience.

For ZK enthusiasts, understanding Labrador is more than just learning about one project — it’s about glimpsing the future of the entire ecosystem. Innovations like Labrador will benefit everyone, across borders, as we collectively strive for a world of greater privacy, scalability, and security. And you don’t need a PhD in math or physics to be part of this journey — as we’ve seen, the core ideas can be appreciated with a bit of imagination and open-mindedness.

In closing, the Labrador project stands as a testament to human ingenuity in cryptography: by going back to fundamental hard problems (lattices) and pushing creative techniques (recursive proofs), researchers have unlocked new possibilities. We can look forward to a modular, post-quantum ZK infrastructure where tools like Labrador ensure that our decentralized applications remain trustworthy, even in the face of tomorrow’s technological challenges. The Labrador might be a friendly breed of dog, but in the ZK world, it’s also the name of a guardian ensuring our proofs stay strong and our secrets stay safe.

“Beyond traditional applications like ZK Rollups, emerging use cases in the ZK space now include cross‑chain operations such as The Signal.”

As blockchain researchers, we are witnessing a huge need for cross-chain interoperability, but “cross-chain finality” is still a missing link in the current infrastructure. Although bridging different on-chain assets and data is increasingly common, traditional multi-sig bridges and repeators schemes still rely on human trust, and security incidents are frequent: In 2020–2022, the cumulative loss of cross-chain Bridges due to hacker attacks exceeded $2.5 billion! The consensus nature of blockchain ensures the finality of states within a single chain, but there is no such a trustless finality proof mechanism between chains. In other words, different blockchains cannot directly “mutually identify” each other’s final state, which is a long-standing trust gap in multi-chain ecology.

In recent years, people have adopted multi-sign Oracle or light node relay to transfer state between chains, but these schemes either sacrifice decentralization or are complex and inefficient. Is there a way for one chain to verify the final state of another chain in a purely mathematical way? The Signal protocol from the Boundless team provides an answer: it compreszes the finality of a source chain (currently Ethereum) into a tiny proof of validity that can be quickly verified on any target chain, via an open-source zero-knowledge (ZK) consensus client. In other words, The Signal leverages zero-knowledge proof techniques to build a “finality claim” that any chain can be trusted to verify. This marks the paradigm of blockchain cross-chain interaction from relying on multi-signature trust to trust minimization based on mathematical proof.

Cross-chain Finality: The Missing Link in Blockchain Consensus

The consensus mechanism of blockchain ensures that all nodes on the same chain agree on state changes and provides finality after a certain time, meaning that the block reaches an irreversible, changed state. However, there is no natural consensus connection between different chains: one chain cannot know when a new block on the other chain is finalized. At present, cross-chain transfer usually uses bridge engagement or third-party services to “prove” events (such as token lock) on the source chain. These proofs are often signed by multi-signer verifiers or provided by relay nodes. This introduces new trust assumptions and attack surfaces: if the verifier colludes or the private key is stolen, the cross-chain bridge can fail. For example, Wormhole, Ronin, Nomad and other multi-signature Bridges have been hacked one after another, resulting in huge asset losses.

The root cause is the lack of native mutual trust mechanism between different chains. Ideally, each chain would like to read the state and finality of the other chain directly, as reliably as reading the local state. In the past, technical limitations allowed us to use stopgap solutions — trust intermediaries, expensive light node verification, or optimistic waiting — to transfer state across the chain. Cross-chain finality proof is the solution to this problem: if we could have a small cryptograph that directly proves that “block Y of source chain X is finalized and the Merkle root of state is Z”, any contract or user on the chain could verify it without trusting any other entity, then the security and efficiency of cross-chain interaction would be greatly improved.

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Nowadays, the development of zero-knowledge proof technology has brought a breakthrough opportunity. ZK proofs have evolved from being able to verify only simple computations, to being sufficient to prove entire chains of states and consensus processes. Boundless leverages this fact to transform the finality of the Ethereum beacon chain into portable cryptographic proofs, creating a trusted cornerstone for cross-chain interoperability. The Signal generates the corresponding ZK proof every time Finality occurs in the Ethereum beacon chain and broadcasts it to other chains, so that any chain can verify the final confirmed state of Ethereum “without anyone”. This means that cross-chain bridging no longer needs to rely on multi-signature signatures or messages provided by a centralized oracle — decentralized applications can build their business logic directly on this mathematically guaranteed cross-chain finality. As Boundless put it, the ecosystem would thus gain a shared “finality signal,” where liquidity and logic could flow freely between chains like Internet apis, while still maintaining blockchain-level security.

The principle and architecture of The Signal protocol

Beyond traditional applications like ZK Rollups, emerging use cases in the ZK space now include cross‑chain operations such as The Signal.The Signal is a cross-chain client running on a zero-knowledge proof system. Its core idea is to let the target chain verify the consensus result of the source chain without trust. Its architecture includes offline proof generation, decentralized bidding incentive, proof aggregation, and on-chain verification release modules.

Workflow: Generation and verification of zero-knowledge finality proofs

1. Request initiation and prover: When an application or user needs to prove that a state or event on the source chain (e.g., Ethereum) has been finalized, a Proof Request is submitted to the Boundless proof market contract. The request contains the specific statement to be proved (e.g., “the root of Ethereum state at block height”), the corresponding prover ID, and the amount of money it is willing to pay. This procedure is called every time a new block of the beacon chain is finalized, forming a new proof request. As a result, The Signal broadcasts Ethereum consensus proof requirements to the market in the form of standardized tasks.
2. Auction bidding and Prover locking: Once a request is posted, numerous Prover nodes on the Boundless network begin to compete to undertake the task.(The economic aspects/design will be discussed later in the text).
3. Offline computation and ZK proof generation: The winning Prover node then executes the specified zero-knowledge prover locally. Boundless is based on RISC Zero’s zkVM technology, which enables Prover to run arbitrarily complex programs in an isolated verification environment while generating a complete proof.For The Signal, this step is equivalent to running an Ethereum light client: the Prover fetches the necessary data from the Ethereum network, and then executes the validation algorithm for the beacon chain finality rule in zkVM. The proof is small and unforgeable, proving that “the above Ethereum consensus verifier executes correctly with the given input and outputs a final state value of X”.
4. Aggregate proof and commit: To optimize on-chain verification cost, Prover can package and aggregate the results of multiple proof requests before on-chain submission.
5. On-chain verification and result publication: When the aggregated proof is submitted, Boundless contract executes the verification logic immediately: utilizing the pre-deployed zero-knowledge verification contract, the Groth16 proof is mathematically verified. If the validation passes, the contract confirms that all requests for this batch have been successfully completed. The contract then extracts the output of that task from the Merkle containment evidence for each request, marks the request as fulfilled, and forwards the pre-locked payment to the Prover (the pledge is also unlocked and returned).

Typical Use case: New possibilities for cross-chain verification

The universal “ultimacy Signal” provided by The Signal brings trust minimization solutions for many scenarios in multi-chain ecosystems. Here are some typical applications:

• Cross-chain reserve audit on DeFi platforms: Decentralized financial applications are often deployed across chains. For example, a stable coin is circulated on multiple chains, but its reserve assets are mainly stored on the Ethereum mainnet. Through The Signal, the stable-coin protocol can periodically request proof of reserve balance on Ethereum and send the result to issuance contracts on other chains. As a result, users on each chain can verify the stabcoin’s asset support in real time with minimal trust, without relying on a central audit report. Similarly, a cross-chain decentralized exchange (DEX) can prove whether it has sufficient liquidity on different chains.
• Trust Minimization Bridge and Asset interworking: The ultimate vision of The Signal is to replace existing multi-signature and relay Bridges and become a secure infrastructure for cross-chain message and asset transmission. For example, if A user wants to use an asset in chain B on chain A, he can lock the asset on chain B and generate a proof that the locking event has finally occurred through Boundless. After verifying the proof on chain A, he can coin the corresponding derivative token. The whole process does not need to trust the third party signature, the multi-signer is replaced by mathematical proof, and the security of the bridge directly depends on the security of the underlying chain itself. Once the major blockchains start broadcasting their ultimacy signals, cross-chain interoperation will converge to a single cryptograph “wavelength” — that is, each chain is communicating under the same trust paradigm, and users no longer need to worry about additional trust holes in the bridging process.

The Advantage of Mathematical Trust: The Signal vs. Multi-signature Bridges

Compared with traditional cross-chain Bridges that rely on multi-signature verifiers or relay nodes, zero-knowledge proof Bridges led by The Signal show significant advantages in trust, security and fairness:

• Trust model and security: Multi-signature Bridges usually rely on a few verifiers to sign and confirm. Once more than half of the nodes are compromised or imploded, the security of the bridge is no longer available. The Signal is based on the underlying chain consensus and cryptographical guarantees: as long as the source chain itself is reliable (e.g., Ethereum finality is guaranteed by thousands of verifiers), the ZK proofs it generates are trusted.
• Openness, fairness and decentralization: Multi-signature or consortium Bridges are often operated by specific institutions or nodes, which has potential centralization and monopoly risks. However, Boundless’s proof network is open to any participant with hardware, and free competitive pricing is achieved through on-chain auctions. This means that no single entity can control the validation of cross-chain transactions, all provers compete under the same rule, and the one with the lowest offer (the one that is most beneficial to the user) wins.
• Transparency and auditability: Under zero-knowledge cross-chain schemes, each cross-chain verification is accompanied by publicly verifiable cryptographic evidence, leaving a record on the chain. Anyone can check the proofs and related transactions after the fact and audit the entire process to see if it worked as agreed.
• Efficiency & Performance: Zero-knowledge proof Bridges trade safety for performance. On the contrary, because it does not require a long waiting time or a large number of verifiers to interact, it can speed up the cross-chain confirmation under the premise of ensuring security. As mentioned earlier, with ZK enables, Rollup went from a week of final cross-chain confirmation to hours or less. This efficiency has a huge impact on user experience and cash utilization.

Token Incentives and the Prover Ecosystem

In Boundless design, tokenomics also plays an important role in driving network growth. Boundless’s native token, $ZKC, serves as both an incentive and a governance tool to promote a virtuous cycle of the Prover computing ecosystem.

First, Boundless introduces the innovative concept of “Proof of Verifiable Work” (PoVW), which converts the effort of Prover performing zero-knowledge computation into token reward. Specifically, whenever the Prover successfully completes a proof task and submits a valid result, it not only obtains the commission fee paid by the requestor, but also obtains the corresponding amount of ZKC token reward according to the actual computation cycle consumed by the task. This reward mechanism realizes accurate measurement through the “calculation cycle label” mentioned above, and the reward is directly linked to the useful calculation amount actually completed, which eliminates the speculative behavior of simple “fight speed to grab orders” or brush orders. This is similar to classical PoW mining where work is tied to reward, but PoVW goes a step further and rewards only computations that are useful to the network (i.e., verification requirements), rather than wasting compute power on meaningless hash collisions. Through this model, the Boundless team plans to realize true ZK mining in the near future, where the global GPU computing power provides proof services for each chain, and at the same time, the native benefits of the blockchain are obtained, which motivates more computing power to participate.

Secondly, ZKC token has the function of governance and pledge to maintain the long-term fairness of the market. Community governance can adjust the rhythm of token issuance and fee parameters to ensure that the incentive mechanism is dynamically balanced with the network scale. Prover and users can also pledge ZKC to participate in market activities and voting decisions, so as to have a stronger sense of participation and constraint on the network. This design makes Boundless “owned by the user”, which is in the spirit of decentralized infrastructure. It is worth noting that Boundless allocated 5 million ZKCS (about 0.5% of the total supply) as an incentive pool during the mainnet Beta phase, which was distributed in proportion to the effective work completed by Prover during the first 5 weeks. This led to an early influx of compute power: within a week, many miners around the world had connected to Gpus to compete, and demand and supply of compute power both increased, creating a virtuous cycle. According to statistics, more than 30 projects plan to integrate Boundless as a proof backend when mainnet Beta launches, which also means that Prover will welcome diverse workloads and revenue sources.

Finally, the token model reinforces the fairness and sustainability of the network. Since the reward comes directly from the real computing work, the computing power provider can get a fair reward, avoiding the manipulation of the revenue by the central mining pool. With more participants, competition will drive proof prices closer to actual costs, improving overall efficiency. The ZKC incentive, in turn, ensures that provers have an incentive to remain online even when the demand is insufficient in the early stage of the network, so as to pass through the cold start phase and gradually attract more applications to access the binding demand. Boundless officially concludes that such a model “directly connects rewards to efficient work,” supporting a fair, decentralized marketplace for computing. It is under The dual wheel of economic incentives and technical mechanisms that the cross-chain ZK infrastructure represented by The Signal can continue to grow and move towards a safer and richer multi-chain future.

Conclusion

The emergence of The Signal protocol has brought an unprecedented paradigm shift for blockchain cross-chain interoperability. With zero-knowledge proofs, an inherently reliable tool, we were finally able to allow different blockchains to share consensus results without additional trusted endorsements — like establishing a common “signaling language” for the blockchain world. Starting with Ethereum, more and more chains will join this wavelength, leading to a vision where each chain broadcasts its own proof of finality and all chains become one under mathematical trust.

For developers, this means no more painful trade-offs between security and efficiency when building cross-chain applications; For users, cross-chain asset circulation and information synchronization will be as smooth and safe as single-chain operations. Boundless The Signal has demonstrated the feasibility and value of this model in the mainnet test. As the ecosystem grows and more chains are added, zero-knowledge cross-chain finality is likely to become the norm in the next generation of blockchain infrastructure. It fills in the trust link that has been missing in the multi-chain world for a long time, and makes the blockchain truly move towards the direction of scalability and composability without sacrificing trust. In this process, the technological and economic paradigm innovation initiated by Boundless undoubtedly deserves our continued attention and in-depth research. The cross-chain future is already taking shape, and its boundaries will be broadened by mathematics and innovation. As the name suggests, the way forward is Boundless.

Binius Proof System is ZK proof system based on Binary Tower, which offers small memory footprint and high efficient field computation. We analysis the PCS in the Binius — which is an essential component to any ZK proof system, in an intuitive but strict manner. We introduce the motivations to the PCS used in Binius, then analysis commitment, and ring switch, Multi-variate Sumcheck protocol, FRI which are used to open prove of the commitment.

1. Definition and Motivation

PCS Commit

The polynomial t(X) corresponding to the trace or witness contains sensitive information and is relatively large in size (due to its high degree). To achieve ZKSNARK in the proof process, we cannot directly include the polynomial (e.g., its coefficients) in the proof. Instead, the polynomial’s coefficients are compressed to produce a smaller value (e.g., a 256-bit hash).

This value is called the commitment value, and the process is known as the commit computation.

For example, in RISC0, for a given polynomial ( t ), NTT is performed on the commitment domain to obtain the leaves of a Merkle Tree, which is then constructed, with the tree’s root serving as the commitment value.

PCS Open Proof

During the proof process, it is necessary to evaluate the polynomial t at a specific challenge value r. The prover needs to compute the function value β = t(α) of the polynomial t and prove that this computation is honest (i.e., to avoid using a forged polynomial).

This process is called the PCS open proof. The commit and open proof are the two most critical steps in PCS. Generally, the commit step is straightforward, while the open proof is more complex.

In RISC0 V2, the PCS is based on Merkle Tree (Hash) + FRI (RS code), while in Varuna, the PCS is based on KZK10 MSM. In Binius, the PCS is based on Merkle Tree (Hash) + Sumcheck + FRI (RS code).

Notably, the use of FRI differs significantly between the two. In RISC0, FRI is used for low-degree testing (combined with quotient polynomials) to perform the open proof, whereas in Binius, FRI is used for the open proof of large-domain polynomials (large and small domain polynomials will be discussed later). Additionally, the construction of RS codes is entirely different.

This is Binius’s primary contribution. Its PCS is based on Merkle Tree (Hash: Groestl256), Multi-Variate Sumcheck, and FRI (RS code). Merkle Tree and Hash are relatively straightforward, while the other concepts are more complex, as discussed below.

RS Code

RS code refers to a set of codewords, where a “codeword” is defined as the set of all function values of a polynomial t evaluated on a set S. The process of computing the codeword for a polynomial t is called encoding, with the polynomial t referred to as the message. We assume the t is a polynomial on finite field F.

For example, in RISC0, the codeword of polynomial t consists of all its function values on the commitment domain (that is set S ). Computing these values using multiplicative FFT requires that the commitment domain forms a cyclic multiplicative group with order is a power of 2 (in the complex field, FFT is feasible because there exist cyclic multiplicative groups of any order on the unit circle in the complex plane). Since all computations occur in a finite field F, it is required that F contains such a multiplicative subgroup.

Additionally, for RS codes, the codeword length, i.e., the size of the commitment domain H, must satisfy |H| > deg⁡(t)+1 = trace length , as RS codes are error-correcting codes (errors in the information can be easily detected, corresponding to soundness), which necessitates the introduction of redundancy.

Additive NTT

Defined as follows: given the coefficients of a polynomial t: t_{0}, …, t_{2^l-1}, compute the function values of another univariate polynomial P over the hypercube B_{l+R}.

In which,

• B_l is the additive subgroup (corresponding to the trace domain in RISC0),
• B_{l+R} is the additive subgroup containing B_l, corresponding to the commitment domain in R0, though in practice it is a coset,
• R is the blowup factor, which is 2 in R0 and 1 in Binius,
• X_j(X) is the basis function of the polynomial vector space over F, completely different from the standard basis functions 1, X, X², …, For its strict definition, refer to this.

MLE
Multi-Linear Extension: For a given function t:B_l → F, its multi-linear extension is a polynomial function tilde_t(X_0,…,X_{l−1}) that satisfies:

• tilde_t is linear in each variable X_j, i.e., the degree of tilde_t with respect to any variable X_j is at most 1, making tilde_t multi-linear;
• The function values of tilde_t on the hypercube B_l are equal to the function values of t, tilde_t is an extension of t.

As shown in Equation (Eq. 2) for tilde_t, the polynomial tilde_eq is precisely the Lagrange basis for the multivariate polynomial (where the set formed by the MLE of all l-variables is viewed as a 2^l-dimensional vector space).

Why MLE?
In RISC0, the algebraic proof relies on the divisibility between the constraint polynomial and the vanishing polynomial on the evaluation domain. However, in a binary field, there is no multiplicative subgroup, and the vanishing polynomial lacks a simple or efficient computation method.

To address this, Binius adopts a Zero Check based on multivariate polynomials for the proof. The Zero Check is proven using the multivariate polynomial Sumcheck protocol (which we will introduce later). The trace is treated as the simplest case of a multivariate polynomial, i.e., a multilinear polynomial, obtained through MLE.
(Why not use the univariate polynomial Sumcheck from Varuna for the proof? For the same reason: the absence of a multiplicative subgroup.)

2. Binius PCS Commitment

All computations in Binius are performed in a binary field, such as F2 ~ F2⁷, which offers the advantages of efficient computation and reduced memory usage.

However, to achieve these benefits while adhering to the constraints of Reed-Solomon (RS) codes, conflicts arise. The design of the Polynomial Commitment Scheme (PCS) in Binius is primarily aimed at resolving these conflicts.

• Conflict 1: In a binary field tower, there is no multiplicative subgroup of a power of 2 (due to Lagrange’s theorem), so multiplicative FFT cannot be used. However, additive subgroups exist in the binary field, enabling the use of additive NTT.
• Conflict 2: In the coefficient field (small field) of the polynomial t, there is no sufficiently large subgroup to serve as the commitment domain for RS codes. RS codes require the commitment domain size |H| > deg⁡(t)+1 = trace length, but we want the trace length to be sufficiently large (e.g., segment size), while keeping the memory usage of t minimal, i.e., preferring a small coefficient field F. Additionally, H must be a subset of the finite field F(since all encoding computations occur in F). For example, if the finite field F2⁴ and the segment size or |H| is 2¹⁹, no subset of F2⁴ can serve as H, since |F2⁴| = 2¹⁶ < 2¹⁹.

For Conflict 2, a naive approach would be to directly embed all coefficients of t into a larger field (e.g. F2⁷), but this increases memory usage and computational overhead (i.e., embedding overhead).

Binius addresses this by using a packing technique, where multiple adjacent coefficients of t are packed into a single element in the larger field. For example, if the polynomial t on F2⁴ has coefficients [t0, t1,… ], where each element has a bit width of 16 bits, Binius packs eight adjacent elements into a single element in F2⁷, resulting in a polynomial t′ on F2⁷, as illustrated below:

Subsequently, using RScode to encode t′ which is a polynomial over the larger field, resolving Conflict 2. Then, the Merkle Tree root node of t′ is computed as the commitment value. The PCS in Binius is also referred to as the small-field PCS.

3. Ring-Switch

As previously mentioned, to address the issue of the coefficient field of polynomial t lacking a sufficiently large commitment domain when using RS codes, Binius introduces the packing technique. This involves packing adjacent coefficients of t into a polynomial t′ over a larger field, followed by computing the Merkle Tree root node of t′ as the commitment value.

However, this introduces another challenge: while the Merkle Tree commitment is made using t′, the proof opening requires computing the function values of the small-field polynomial t(failing to address this could lead to security issues).

To resolve this, Binius employs Ring-Switch and Sumcheck to reduce the problem of opening the commitment of t to opening the commitment of t′, where the commitment opening proof for t′ is achieved through FRI folding and Merkle Tree queries.

The PCS in Binius is also referred to as the small-field PCS. The purpose of Ring-Switch is to reduce the opening proof of the small-field PCS to that of the large-field PCS, which is somewhat complex. We attempt to explain as follows:

Suppose the small-field MLE is t(X_0,…,X_{l−1}), and after packing, the resulting polynomial is t′(X_0,…,X_{l−κ}). We need to prove s = t(r_0,…,r_{l−1}), where:

• r_j are random challenge values from the large field (for security reasons, random challenge values are typically drawn from the large field, e.g., F2⁷);
• κ is the packing or extension coefficient. For example, if each coefficient of t is an element of F2⁴(bit width of 16 bits), and each coefficient of t′ is an element of F2⁷(bit width of 128 bits), then κ = log⁡2(128/16) = 3.

For convenience, we denote the coefficient field of t as K, and the coefficient field of t as L, where L is an extension of K of degree 2^κ. Additionally, L is a 2^κ-dimensional vector space over K, with basis β_0,…,β_{2^κ−1}. We also denote l′=l−κl.

Note that our goal is to prove (Statement 1):

3.1 How to Prove (Statement 1)?
Note that by treating r_0,…,r_{κ−1} as variables and based on the definition of MLE, we can deduce:

Thus, we conclude that (Statement 1) holds if and only if (Statement 2) holds:

This is because, in the right-hand side of (Statement 2),

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

v_0,…,v_{κ−1} traverse the hypercube B_κ. After receiving hat_s_v, the verifier can easily compute t(r_0,…,r_{l−1}) according to (Eq.1.1) and then determine whether s equals t(r_0,…,r_{l−1}). Thus, the problem reduces to proving (Statement 2).

3.2 How to Prove (Statement 2)?
We expand all hat_s_v∈L in terms of the basis β_0,…,β_{2^κ−1}, obtaining the following expression:

Additionally, note that by expanding the polynomial t(v_0,…,v_{κ−1}, X_κ,…,X_{l−1}) in terms of the Lagrange basis and evaluating it at r_κ,…,r_{l−1}, we obtain:

We conclude that (Statement 2) holds if and only if (Statement 3) holds:

In fact, we have used two methods to compute hat_s_v:

• On the left-hand side of (Statement 2), the hat_s_v is expanded in terms of the basis for vector space of L over K, according to (Eq. 2.1).
• On the right-hand side of (Statement 2), the polynomial is expanded in terms of the Lagrange basis and then evaluated, according to (Eq. 2.2)

Thus, the problem reduces to proving (Statement 3).

3.3 How to Prove (Statement 3)?
To connect with t′, as we aim to reduce the small-field opening proof to the large-field opening proof, we can attempt to express β_u in terms of β_v Noting that v appears in t in (Statement 3), we expand the function values of the hat_eq polynomial value:

By substituting (Eq. 3.1) into (Statement 3) and simplifying, and leveraging the linear independence of the basis in the vector space, we conclude that (Statement 3) holds if and only if (Statement 4) holds:

Thus, the problem reduces to proving (Statement 4).

3.4 How to Prove (Statement 4)?

By multiplying both sides by β_v and simplifying, we conclude that (Statement 4) holds if and only if (Statement 5) holds:

Where hat_s_u is defined as (Eq. 4.1):

Note that u in (Eq. 4.1) comes from the right-hand side of (Statement 4), which originates from (Eq. 3.1), and u in hat_s_u must match u in A_{w,u}.
Thus, the problem reduces to proving (Statement 5).

3.5 How to Prove (Statement 5)?
Since (Statement 5) is a standard Multi Sumcheck equation, it can be proven using the Multi Sumcheck Protocol. However, we aim to prove (Statement 5) holds for all u∈B_κ, batching them together to reduce the proof size. To this end, we have that (Statement 5) is almost equivalent to (Statement 6):

(Statement 6) can be proven using Multi Sumcheck. (Why? After replacing r′′ with κ variables on both sides of (Statement 6), both sides are MLEs. If (Statement 5) holds, (Statement 6) must hold; and if two MLEs are equal at a randomly chosen point, then (Statement 5) holds with overwhelming probability.)

3.6 Summary:
To prove (Statement 1):

Using fewer challenge values, (Statement 1) is equivalent to (Statement 2):

By computing hat_s_v using two different basis expansion methods, (Statement 1) is equivalent to (Statement 3):

To connect with t′, eliminate β_u, (Statement 3) is equivalent to (Statement 4):

Multiplying by β_v and simplifying, (Statement 4) is equivalent to (Statement 5):

Batching the Sumcheck proof, (Statement 5) is almost equivalent to (Statement 6):

Finally, we define the polynomial ( h ):

where A is given by (Eq. 6.2):

The purpose of Ring-Switch is to compute the polynomial h, the left-hand side of (Statement 6) s0, for subsequent Sumcheck proof and FRI. The specific algorithm flow is shown in the figure below:

4. Sumcheck FRI

Sumcheck Protocol
The purpose of the Sumcheck protocol is to prove the following equation holds:

where h is defined as in (Eq. 6.1). The prover needs to demonstrate that this equation holds without revealing the coefficients of h. From the equation above, it can be seen that the right-hand side is effectively a sum of the function values of the polynomial over all vertices of the “hypercube,” i.e., Sumcheck.

Prover:

There are a total of l’ rounds, and the proof proceeds as follows:
For j=round_1, …, round_l′:
A. The prover computes the coefficients of the univariate polynomial:

B. The prover appends the coefficients of H_j to the current transcript.
C. The prover uses the generated transcript as input to produce a random challenge value r′_j.
D. The prover computes the coefficients of the multivariate polynomial h(r′_1,…,r′_j, X_{j+1},…,X_{l′}).

Verifier:

Upon receiving the transcript, the verifier locates the section corresponding to the Sumcheck and extracts each univariate polynomial H_j.

For j=round 1, …, round_l′:
The verifier checks if H_j(0)+H_j(1) = H_{j−1}(r′_{j−1}).
— If this holds for all j, the verifier accepts the Sumcheck as correct.
— Otherwise, the verifier considers the Sumcheck incorrect.
Additionally, the verifier checks if H_l′(r′_l′) == h(r′_1,…,r′_l′).

Note that in the final step, the verifier needs to check

H_l′(r′_l′) == h(r′_1,…,r′_l′) = A(r’_1, …, r’_l’) * t′(r’_1, …, r’_l’). Here, the verifier can computeH_l′(r′_l′) and A(r′_1, …, r′_l′) independently (why? refer to the definition in Eq. 6.2, which involves the hat_eq polynomial). However, t′(r′_1, …, r′_l′) cannot be computed by the verifier (to ensure zero-knowledge, the verifier does not have access to it).

The prover use FRI to compute and prove t′(r′_1, …, r′_l′). How is this proven? After FRI folding, the RS code of t′ becomes a constant function, and this constant is exactly t′(r′_1,…,r′_l′)(why? refer to the this). Additionally, a Merkle Tree path proof is required to ensure the folding process is correct.

The specific algorithm flow is shown in the figure below:

5. Conclusion

The Binius Proof System’s PCS is a sophisticated and innovative scheme that optimizes for binary fields, offering a balance of efficiency, security, and practicality. By addressing the limitations of binary fields through techniques like additive NTT, MLE, and Ring-Switch, Binius provides a robust framework for zero-knowledge proofs, particularly in scenarios where computational resources are limited. Its design not only enhances performance but also sets a new standard for ZK proof systems in constrained environments. Especially, it’s friendly to hardware such as FPGA or ASIC, thus it might be further accelerated.

Recently, Aleo released their roadmap for 2025. We analyze the possible algorithms Varuna will use to achieve this goal.

Varuna is the current proof system for snarkVM in Aleo, used to prove the correctness of program execution (written in the Leo language). It reduces the problem of proving the correctness of one or more program executions to proving an R1CS problem, with the underlying proof leveraging the sum-check protocol for univariate polynomials.

1. Roadmap 2025

Aleo officially released the 2025 roadmap, as shown in the figure below. The goal for 2025 is to support circuits of size 2²², with plans to support circuits of size 2²⁸ in the future, which poses significant challenges for memory and computational power.
To achieve this goal, we estimate that Aleo VM may evolve in the following directions:
A. Support for recursion functionality, i.e., splitting the program or circuit to be proven into multiple parts, generating proofs for each part individually, and then aggregating these proofs into a final proof.
B. Development of a more efficient polynomial commitment scheme.
C. Currently, Varuna uses the base field of BN254, where each element occupies significant memory, and arithmetic operations in this field require substantial computation. Switching to a smaller field could significantly reduce memory usage and computational requirements.

See also our previous articles, The Journey Toward Aleo’s Universal ZKVM and Advanced ZK Hardware Acceleration: The Technology Behind Aleo ASIC Miner.

2. Introduction

The Varuna algorithm primarily consists of three components: circuit synthesis, algebraic holographic proof, and polynomial commitment scheme. We will provide a detailed introduction and analysis of the algebraic holographic proof part of the Varuna ZKP algorithm (i.e., how constraints are proven through polynomial representation and computation), which is the most challenging part of Varuna.
This article will analyze and introduce the algorithm’s principles from a theoretical perspective, provide a simple mathematical reasoning process, and discuss the future evolution of Varuna in the context of the Aleo 2025 Roadmap.

As shown in the figure below, this article will focus on the left part of the diagram, namely the algebraic holographic proof (where “holographic” refers to the small number of queries required in the proof process). The circuit synthesis and polynomial commitment scheme, while logically somewhat complex, are similar to those in other proof systems.

The following text will explain the problem that Varuna proves, providing rigorous definitions of the terms used, and then analyzing in detail the five rounds introduced to address this problem (with Rounds 3 and 4 being more complex, while the other rounds are simpler). Due to space constraints, for the mathematical foundations involved, we will only briefly explain the concepts and theorems, without providing detailed descriptions or proofs, and encourage readers to refer to any abstract algebra textbook they find interesting.

3. R1CS Problem and Definitions

The purpose of the Varuna algorithm is to prove that the execution of a program (written in the Leo language, assuming a single program for now; the process for proving multiple programs will be discussed later) is correct. To achieve this, Varuna first executes the program and, based on the types of computations and intermediate results during execution, constructs three matrices A, B, C, and a vector z. This reduces the problem of proving the correctness of program execution to proving that these three matrices and the vector z satisfy certain constraints. We provide the following definition:

Definition 3.1: R1CS Problem
For given matrices A, B, C, and vector z, the R1CS (Rank-1 Constraint System) refers to proving that the following equation holds:

• matrix A: An (m, n) dimension matrix over a finite field F (i.e., the elements of the matrix belong to F, not the real numbers). A finite field is a set in which the four basic arithmetic operations (addition, subtraction, multiplication, and division) can be performed, and the number of elements in the set is finite (for a rigorous definition, refer to textbooks).
• matrix B, C: Defined similarly to A, but as distinct matrices, with all three matrices having the same dimensions.
• z: An n-dimensional column vector in the finite field, where z includes the public inputs of the program and the witness (i.e., public inputs and intermediate results of program execution), such as z = (x, w).
• Az: Denotes standard matrix-vector multiplication, resulting in a column vector a_z. Similarly, b_z and c_z are defined.
• The product of Az and Bz: Represents the Hadamard product between column vectors, i.e., element-wise multiplication of corresponding elements in the two vectors.

As shown in the simple example in the figure below, this illustrates how arithmetic operations of instructions are converted into an R1CS problem. Note that each row of the matrix corresponds to a constraint, and the constraint holds if and only if the corresponding instruction’s computation is correct.

Lemma 3.2: Sum-check

For a given polynomial f(Y) over a finite field F (i.e., the coefficients of the polynomial belong to F), the sum of f over a cyclic group C (a non-zero multiplicative subgroup, slightly abuse notation with C in R1CS, but easy to get the difference) in F equals σ, if and only if there exist polynomials h(Y) and g(Y) over F such that the following equation holds:

• σ: An element in F.
• C: A subgroup of the multiplicative group formed by all non-zero elements in F under multiplication. Group, a set with a defined “multiplication” operation. Notably, any multiplicative subgroup in a finite field is a cyclic group, meaning every element in the group is an integer power of some element. This is crucial because many algorithms in zero-knowledge proofs (especially Varuna) rely on the simple structure of cyclic groups.
• |C|: The number of elements in the cyclic group C. Since F is finite, C is necessarily finite.
• vC(Y): The vanishing polynomial over the cyclic group C, i.e., a polynomial that evaluates to zero at every element of C. Other vanishing polynomials over cyclic groups can be defined similarly.

For ease of discussion in the following sections, we assume that the row indices of the three matrices in R1CS, such as those in A, are treated as a function from a cyclic subgroup R of F to F. We call this cyclic subgroup R the constraint domain (i.e., constraint_domain in the code). The cyclic subgroup C corresponding to the column indices is called the variable domain (i.e., variable_domain in the code). Based on the context, it is easy to distinguish whether C refers to the matrix in R1CS or the variable domain, avoiding symbol confusion.
Clearly, z should be treated as a function from R to F , and the public inputs of the program to be proven (i.e., public_input in the code) are treated as a function on a subgroup H0 of R, which we call the input domain (i.e., input_domain in the code).
Additionally, as seen in the R1CS example above, many elements in the three matrices are zero. To save memory and computation, all non-zero elements in each matrix are sorted in the order of their appearance, and the subgroup K corresponding to the indices of this sorting is called the non-zero parameter domain (i.e., nonzero_domain in the code).

4. Round 1: Generating the Witness Shift Polynomial and Random Polynomial

4.1. Computing the Witness Shift Polynomial
The following polynomial is computed:

• x: The public input of the program to be proven.
• H0: The input domain, with its number of elements being the smallest power of 2 greater than or equal to the number of elements in the public input.
• vH0(X): The vanishing polynomial over H0。
• hat_x(X): The low-degree extension polynomial of the public input x, obtained using the function values of x on H0 via IFFT.
• z’(X): The low-degree extension polynomial of the function z’, where z’ represents the public input and witness.

4.2. Generating the Random Mask Polynomial
The generation process is relatively simple, as shown in the following equation:

• R3(X), R4(X): Polynomials with coefficients that are random elements in F, with R3(X) of degree 3 and R4(X) of degree 4.
• vC(X): The vanishing polynomial over C (in the code, this corresponds to the maximum variable domain).

Why is the mask polynomial needed?
It is used in Round 3 to achieve zero-knowledge properties.

4.3. Prove process

The figure below illustrates the computation process for Round 1. Note that the figure involves iterating over circuits and multiple instances of each circuit. This is because Varuna supports what is known as batch proving, where multiple circuits and their respective multiple executions are proven together, generating only a single proof.

5. Round 2, row check

5.1 Prove Principle
The goal is to prove the following:

• a_z = Az, the product of matrix A and column vector z = (x, w), with similar definitions for b_z and c_z
• The multiplication on the left-hand side is element-wise multiplication, not a vector inner product.
• the equation being proven consists of m equations, corresponding to m constraints. If the program is executed correctly, these m equations hold.

How to prove it? It’s straightforward.

1. Use IFFT to compute the low-degree extension polynomials of a_z, b_z and c_z, obtaining hat_az(X), hat_bz(X) and hat_cz(X).

2. (Eq. 5) holds, meaning every constraint in the R1CS is satisfied, if and only if for any element x in R, x is a root for the equation: hat_az(X)·hat_bz(X) — hat_cz(X) = 0.

3. The statement in step 2 holds if and only if the vanishing polynomial v_R(V) over ( R ) divides hat_az(X)·hat_bz(X) — hat_cz(X). That is, there exists a polynomial h0(X) on F such that:

4. (Eq. 6) holding is almost equivalent to the following equation holding, in which α∈F\R is a random challenge value from:

5. The purpose of Round 2 is to compute h0(X), calculate its commitment value, and submit it.

6. When the verifier receives the proof for verification, they need to check that (Eq. 7) holds.

5.2 Prove process

The specific proof process for Round 2 is illustrated in the figure below:

Note that in Round 2, the process iterates over multiple circuits and multiple instances of each circuit, computing the row_check_witness.

The most important feature of Varuna is its support for batch proving, which involves proving multiple circuits and their multiple instances together, generating a single proof.

Since there are multiple circuits, each potentially with multiple instances, a naive implementation would require computing the h0(X) polynomial for each instance of each circuit, calculating its commitment value, and submitting it. However, this approach would result in many commitment values being submitted, leading to a large proof size.

Instead, we aim to combine all quotient polynomials from multiple circuits and instances into a single polynomial and submit its commitment value. This is achieved by computing the following expression, derived through easy mathematical reasoning.

• R: The largest constraint domain.
• Ri: The constraint domain of the i-th circuit.
• vRi(X): The vanishing polynomial over.

6. Round 3, linear check

6.1 prove principle
Linear check is to compute and prove that the matrix-vector multiplication is correct, i.e., compute and prove that the following equation holds:

• M ∈ {A, B, C}, with a_z denoting the product of matrix A and vector z = (x, w), and similarly for b_z and c_z.

Why is this necessary?

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

1. The R1CS itself requires proving this equation.

2. During verification in Round 2, the verifier needs to compute:

However, the verifier cannot directly compute this because they do not have M (which may be very large) or z. Thus, they rely on the prover.
Note that (Eq. 11) holding is almost equivalent to (Eq. 10) holding, so we only need to compute and prove (Eq. 11).

How to prove it?
For ease of explanation, we first assume there is only one circuit. The intuitive understanding of the proof process is as follows:

1. Leverage the sum-check protocol for a univariate polynomial over the cyclic group ( C ). Sum-check Lemma: As stated in Definition 3.2, for a polynomial ( f(Y) ), the sum over the cyclic group C equals σ, if and only if there exist polynomials h(Y) and g(Y) such that:

2. Note that the matrix-vector multiplication is essentially a summation.

3. The key to the proof is computing f(Y) = hatM(α, Y) · z(Y), where hatM(α, Y) is the low-degree extension of M as a bivariate polynomial.

4. To compute f(Y), consider the Lagrange basis expansion of hatM(X, Y):

• R: The constraint domain, i.e., the domain of the row indices of M.
• C: The variable domain, i.e., the domain of the column indices of M.
• K : The cyclic subgroup corresponding to the indices obtained by sorting all non-zero elements of matrix Min their order of appearance, i.e., the non-zero domain in the code.
• valM(κ): The function that treats all non-zero elements of M as a function over K, with hat_valM(Z) as its low-degree extension polynomial.
• rowM(κ): The function that treats the row indices of all non-zero elements of M as a function over K, with hat_rowM(Z) as its low-degree extension polynomial.
• colM(κ): Defined similarly to rowM(κ).
• L_rowM(κ)_R(X): The Lagrange basis function corresponding to the rowM(κ)-th element over R, and similarly for L_colM(κ)_C(Y)

5. Using the low-degree extension of M(Eq.13), we can easily construct f(Y).

6. Then, applying the sum-check lemma, (Eq. 11) holding is almost equivalent to the following equation holding, where β is a random challenge value in F\C:

7. The purpose of Round 3 is to compute h(Y) and g(Y), submit them, and ensure zero-knowledge properties.

8. The verifier, during verification, needs to check that (Eq. 14) holds.

6.2 Prove process

Additionally, note that in Round 3, the process iterates over multiple circuits and multiple instances of each circuit. Similar to the prove process in Round 2, for multiple circuits and instances, we aim to combine all quotient polynomials h(Y) and remainder polynomials r(Y) into a single polynomial, i.e., compute h1(Y) and r1(Y) in the following equations and submit their commitment values:

• C : The largest variable domain.
• Ci: The variable domain of the i-th circuit.
• vC(Y): The vanishing polynomial over C.
• h’_ijk(Y) and r’_ijk(Y) must satisfy the following equation:

7. Round 4, rational check

7.1 Prove principle

Compute and prove the evaluation of the bivariate matrix polynomial

• M ∈ {A, B, C}.
• hatM(X, Y): The low-degree extension polynomial of M, as noted in (Eq. 13).
• α: A random challenge value from F\R.
• β: A random challenge value from F\C.

Why is this necessary?

1. In Round 3, the verifier needs to compute hatM(α, β) for the final check, but cannot do so directly (due to high computational cost). Thus, the prover must compute and prove it.

2. Directly using the bivariate polynomial obtained from the Lagrange expansion of the matrix for the proof would be computationally expensive. Therefore, a derivative polynomial basis is introduced. Below are the Lagrange basis function expansion and the derivative polynomial basis function expansion:

• dR(X, Y) = [vR(X) — vR(Y)] / (X — Y).
• R: The constraint domain.
• C: The variable domain.
• K: The non-zero parameter domain.

How to prove (Eq. 17)?
For ease of explanation, we first assume there is only one circuit.

1. Using the definition of the quotient polynomial, simplify (Eq. 18), obtain the following expression:

2. Define the following polynomial r(Z):

Then, (Eq. 17) holds if and only if the sum of the rational polynomial r(Z) over K equals ω.

3. The statement in step 2 holds if and only if there exist polynomials h4(Z) and gM(Z) such that the following equation holds:

4. The purpose of Round 4 is to compute ω, hM(Z), gM(Z), a(Z), b(Z) from the above equation, and submit them (for polynomials, compute their commitments).

7.2 prove process

Based on the above description, we can obtain the proof process for Round 4 as shown in the figure below:

Similar to the approaches in Round 2 and Round 3, all hM_i(Z) polynomials are combined (using random selection, but the combiner is obtained later and accumulated in Round 5).

8. Round 5

The process for Round 5 is relatively simple, only requiring the completion of the following computations:

9. Summary

In summary, the proof process for the algebraic holographic part of Varuna primarily consists of the following five rounds:

Round 1: Preparation for the proof, generating the witness_shift polynomial and the random polynomial mask(X), used to achieve zero-knowledge ZK.

Round 2: Row check, proving that each row constraint in the R1CS holds.

Round 3: Linear check, computing and proving that the matrix-vector multiplication is correct, while also supporting Round 2.

Round 4: Rational check, supporting Round 3, computing and proving the evaluation of the low-degree extension polynomial of matrix M at (α, β): ω = hatM(α, β).

Round 5: Randomly combining the quotient polynomials from Round 4 and computing their commitment values, supporting Round 4.

The finite field arithmetic operations are essential in ZKP proof systems, we introduce some simple novel field computation algorithms, result in at least 20% performance improvement of multiplication in extension field K, and 30% improvement of Montgomery transformation from integer to Montgomery representation in the base field F.

1. Goal

In many zero-knowledge proof systems (such as SP1 and RISC0), the majority of computations occur within finite fields, including finite field addition, multiplication, and division. Therefore, efficient finite field arithmetic operations are crucial for the performance of zero-knowledge proof systems. We will introduce some novel finite field computation algorithms and provide performance comparison data.

2. Finite Fields​​

A ​​field​​ is a set F equipped with two operations, referred to as “addition” and “multiplication”, denoted as + and ⋅ respectively, that satisfy the following conditions:

​​A.​​ F forms an ​​Abelian group​​ under addition:

• There exists an additive identity element 0∈F.
• Every element in F has an additive inverse.
• Addition is associative and commutative.

​​B.​​ F∖{0} forms an ​​Abelian group​​ under multiplication:

• There exists a multiplicative identity element 1∈F∖{0}.
• Every non-zero element in F has a multiplicative inverse.
• Multiplication is associative and commutative.

For example, the set of real numbers R, under standard addition and multiplication, forms the real number field R. A field F is called a ​​finite field​​ if it contains a finite number of elements.

A ​​prime field​​ Fp​ is defined as the set Fp​={0,1,2,…,p−1}, where p is a prime number. Its operations are:

• ​​Addition​​: a+b=(a+b) mod p (where the second “+” denotes integer addition, and mod is the modulo operation).
• ​​Multiplication​​: a⋅b=(a×b) mod p (where × denotes integer multiplication).

A ​​field extension​​ K of a field F is a field such that F is a subfield of K (i.e., F⊆K, and the operations of K, when restricted to F, satisfy the field axioms). For example, the complex numbers C form an extension field of the real numbers R.

Since prime fields Fp​ are widely used in zero-knowledge proof systems, we focus on computations in Fp​ and their extension field K. Without loss of generality, we assume that:

​​Easy to know that polynomial X4+11 is irreducible in F[X], then the quotient ring F[X]/(X^4+11) forms a field and is an extension of F.

3. Operations in the Field F and Its Extension Field K

Operations in the field F typically include addition, subtraction, multiplication, and finding inverses, where addition and multiplication are the basic operations defined in the field F, while subtraction and inversion can be constructed from these basic operations. Similarly, operations in the extension field K can be derived from those in F, so we first focus on addition and multiplication in F.

Based on the definition of the prime field, addition in F is defined as a+b = (a+b) mod p. Note that 0≤a≤p−1, 0≤b≤p−1. When a+b is computed as integer addition, the result c=a+b satisfies 0≤c≤2p−2. Thus c mod p can be computed as: c mod p = if c<p then c ; otherwise c−p. This means that addition in F can be easily calculated using 1~2 integer addition/subtraction operations and one logical comparison.

Multiplication in F is defined as a⋅b=(a⋅b) mod p. Note that 0≤a⋅b≤(p−1)^2. When a⋅b is large, numerous subtraction operations are required to reduce a⋅b to an element in the field F. Alternatively, one division can be used, such as q = ⌊(a⋅b)/p⌋, and (a⋅b) mod p = (a⋅b)−(p⋅q). However, division operations require a significant number of cycles in hardware or GPU implementations. To address this issue, we introduce Montgomery reduction.

4. Montgomery Reduction

To reduce a given large integer to the range [0, p) without using division, Montgomery reduction bases on the following equation:

This equation clearly holds because, by considering the operations in the expression z + ((z⋅p′ mod R)⋅p) as multiplication and addition in the ring Z/RZ, there exists an integer k such that the following relationship is satisfied:

That is, the numerator in Equation (1) is a multiple of ( R ).

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Additionally, note that Rc = R(z⋅R_inv mod p). By treating the multiplication as an operation in the field F, we have:

For x∈[0,p), suppose tilde_x = xR mod p, with y and tilde_y defined similarly. According to the definition of the field F, the following equation holds:

From Equation (2), it can be seen that we can compute the product of tilde_x and tilde_y using Equation (1), i.e., Montgomery reduction and this equation. However, this requires first transforming x to tilde_x = xR mod p, which is computationally expensive. This transformation can be achieved, for example, via Mont(x,R2), where R2=(R⋅R) mod p, and R2 can be precomputed. In many proof systems, such a transformation typically needs to be performed only once, followed by numerous multiplication or division operations. Thus, Montgomery multiplication is an efficient method for multiplying elements.

Hereafter, we refer to this transformation as the Montgomery transformation, and tilde_x as its Montgomery representation.

5. Optimized Barrett Reduction

In many proof systems (such as SP1 and RISC0), when generating a trace, it is necessary to transform numerous integers in the range [0, 0xffffffff) into their Montgomery representation using the Montgomery transformation. However, the computational cost of the Montgomery transformation is relatively high. To address this, Barrett reduction can be introduced, as shown in the following equation:

The correctness of Equation (5) or the proof of correctness for Barrett reduction can be found in Note 2.15 of Reference [1]. It suffices to note that, from this proof, it can be shown that: 0≤(z−hat_q⋅p) < 3p.

However, note that since μ>(1≪32), requires a u64 to represent μ. Additionally, since 0≤⌊z / b^(k−1)⌋< (1≪34), it also requires a u64 to represent. This results in one u64-u64 multiplication and one u64-u32 multiplication, which is computationally expensive. To address this, we can leverage the properties of μ and p to simplify the computation.

Additionally, Montgomery transformation is tilde_x = xR mod p, then let

Use Equation6 ~ Equation 8, we can change Equation 3 and Equation 4 to the following form:

Then the Optimized Barrett reduction just need one u32 multiplication, and other shift, add and subtraction, which are more efficient than multiplication operations.

6. Multiplication in the Extension Field K

We know that the elements in the extension field K are essentially a set of polynomials { r(X)+q(X)p(X) | q(X)∈F[X] }, where p(X) is an irreducible polynomial, such as p(X)=X^4 + 11 as defined above, with r(X)∈F[X] and its degree less than 4.

Thus, elements in K can be represented by their corresponding polynomial r(X), which can be expressed using 4 elements from the field F as the coefficients of the polynomial.

The multiplication operation in the extension field K consists of polynomial multiplication followed by a polynomial reduction with respect to p(X):

Then h(X) = (f(X) ⋅ g(X)) mod r(X) with coefficients:

From Equation (10), it can be seen that multiplication in the extension field K is implemented through the multiplication and addition of elements in the field F. Notably, this primarily involves the inner product of vectors, such as computing inn3=a0⋅b2+a1⋅b1+a2⋅b2. If computed naively using the multiplication and addition operations in the field F, multiple Montgomery reductions would be required (e.g., inn3 requires 3 reductions), with each reduction involving a significant computational cost:

Suppose we have already performed the Montgomery transformation on a0 using Optimized Barrett reduction, i.e., tilde_a0 = a0⋅R mod p, and similarly for tilde_a1, tilde_a2, tilde_b0, tilde_b1, tilde_b2. Then tilde_inn3 is:

From Equation (12), it can be seen that we only need to perform a single Montgomery reduction, which significantly improves the computational performance of the inner product. Consequently, the multiplication operation in the extension field K can be optimized.

7. Performance Comparison

We implemented the following three simple algorithms in Python and collected performance data:

1. Optimized Barrett reduction for Montgomery transformation;
2. Merged Montgomery reduction in the computation of the inner product of two vectors.
3. Merged Montgomery reduction for multiplication in the extension field K;

Test Platform: Mac M3, 16GB RAM, Python implementation.

8. Reference

1. Menezes, A. J., Vanstone, S. A., & Oorschot, P. C. V. (2004). Guide to elliptic curve cryptography. Springer.

1. SP1 is a zkVM proof system based on the RISC-V instruction set and STARK. It supports Recursion proofs , enabling the generation of proofs of the same size for the execution process of any program.
2. 2. SP1 can convert the STARK proof obtained through Recursion into a SNARK proof using Groth16 or Plonk.
3. We make a detail comparison with RISC0 and evaluate the performance of SP1 zkVM on the generation proof for a Taiko block.

1. Purpose

SP1 is a zkVM (zero-knowledge Virtual Machine) proof system based on the RISC-V instruction set and STARK (Scalable Transparent Argument of Knowledge). It supports Recursion proofs , enabling the generation of proofs of the same size for the execution process of any program. Additionally, SP1 can convert the STARK proof obtained through Recursion into a SNARK proof using Groth16 or Plonk, further compressing the proof size.

Since SP1’s proof process is similar to that of RISC0, and we have previously analyzed RISC0’s proof process ( https://medium.com/p/0666216b654b/edit ), we will briefly introduce SP1’s proof process and key steps. Following this, we will compare it with RISC0 and finally discuss the performance, CPU, and memory usage when proving a Taiko block.

2. SP1’s Proof Process

As shown in the figure above, for a program to be proven (composed of numerous RISC-V instructions, compiled from a high-level language such as Rust) and its given input, the SP1 zkVM executes the program and generates a proof file to verify that the program was executed correctly. This proof file must not contain any sensitive information, such as data generated during execution or private inputs.

To achieve this, the SP1 zkVM performs the following steps:

A. Execute the program, split it into multiple Shards/Checkpoints , and record all memory data required for executing each Shard.

B. Generate proofs for each Shard individually using the STARK protocol .

C. Merge the proofs from the previous step into a single proof via Recursion Proving , ensuring that proofs for programs of varying sizes result in a proof file of identical length.

D. Convert the Recursion Proving-generated proof into a SNARK proof using Groth16 or Plonk , further reducing the proof size. Since generating Shard Proofs consumes the most memory and computational resources, the following section will briefly explain the Shard Proof generation process.

3. Generating Shard Proof

As shown in the figure above, when generating a Shard Proof for a program, SP1 employs three independent threads : Checkpoint Generation , Trace Generation , and Shard Proof Generation . This enables parallel processing of multiple tasks, significantly improving performance.

The details are as follows:

A. Checkpoint Generation Thread. This thread executes the program to be proven, splits it into multiple Shards based on a predefined Shard size, and records the instructions within each Shard along with the memory data required to execute them.

B. Trace Generation Thread. For each Shard generated by the Checkpoint thread, this thread sequentially executes the instructions in the Shard, logs the register states and memory access patterns, and ultimately produces a normal execution trace . Notably, all Shards are processed independently, allowing hardware acceleration (e.g., GPU or multi-CPU parallelism) to achieve high performance.

C. Shard Proof Generation Thread. Using the STARK protocol , this thread generates commitments and opening proofs for the traces obtained from the Trace thread, resulting in the final Shard Proof .

4. Generating Recursion Proof

The size of the final proof is roughly proportional to the length of the execution trace of the program being proven. In other words, longer programs result in more Shards (and corresponding Shard proofs), and proof size is a critical metric for proof systems (since proofs must be transmitted from the prover to the verifier).

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

To minimize the final proof size, SP1 supports compressing pairs of adjacent Shard Proofs into Reduce Proofs using the STARK protocol. These Reduce Proofs are then recursively compressed further until a single root proof is generated. This ensures that, regardless of the program size, the final proof size will be fixed-length.

Finally, the root proof at the base of the recursion tree is wrapped into a Groth16-compatible proof for efficient on-chain verification. Figure 3 illustrates this process.

5. SP1 vs. RISC0: Similarities and Differences

5.1. Similarities

Fundamental Principles There is no fundamental difference in their underlying principles. As shown in Figures 1 and 4, both proof processes follow these steps:

A. Split the program into multiple parts ( Segments in RISC0, Shards in SP1).

B. Generate proofs for each part using STARK .

C. Merge the proofs recursively via STARK-based recursion proving .

D. Convert the final recursive proof into a Groth16-compatible proof for verification.

Finite fields which both proof systems operate on are the same finite field structure: base field: BabyBear, extension field: 4-degree extension.

5.2. Differences

Implementation Transparency SP1: Fully open-source CPU implementation (GPU implementation is closed-source). Code is modular and easier to audit. RISC0: Critical components (e.g., trace generation, polynomial checks) are auto-generated via Zirgen , making the code harder to understand or modify.

Hardware Acceleration SP1: Optimized for AVX256/512 and CUDA (closed-source GPU code). RISC0: No SIMD support but supports Metal (Apple GPUs) and CUDA.

Precompile Support SP1: Allows custom precompiles (e.g., elliptic curve operations) by manually designing trace tables and constraints, reducing trace length and improving performance. RISC0: Precompiles are auto-generated via Zirgen, limiting user flexibility to add custom circuits. Proof Generation

Dependencies. SP1: Relies on the Plonky3 library (open-source) for commitments, FRI, and other proof components. RISC0: Implements all components in-house.

6. Proving Taiko Block Performance

To evaluate SP1’s performance in proof generation, we tested a real-world use case: generating a proof for a Taiko block using SP1 and verifying its correctness locally.

We measured the runtime, CPU usage, and memory consumption. The results are as follows.

Test Configuration: Hardware: AMD Ryzen 9 9950X 16-Core Processor, 96 GB RAM. Block Details: Gas limit of 5,944,801 (5.9 million), total cycles counted during proof generation: 488,808,529 (488 million).

Results: Total Proof Generation Time: ~1.5 hours. Shard Proofs Phase: ~1 hour, with memory peaking at 50 GB during the final Shard Proof generation. Recursion Proof Phase: ~0.5 hours, primarily spent merging proofs. CPU and Memory Usage: The figure below shows the CPU and memory utilization during the proof generation process.

A high-performance ASIC mining machine for the Aleo project has recently entered the market — the GoldShell AE BOX small mining machine. GoldShell is a brand from Intchains Group. As a technology partner of Intchains, we have witnessed their long-standing support for technological innovation in privacy computing and AI. Zero-knowledge Proof (ZKP) technology has attracted widespread attention, requiring ongoing breakthroughs in both hardware and software — especially in performance acceleration.

This article explores the technology behind this ZK ASIC miner and the technology roadmap for future ZKVM + ASIC solutions.

2. Technical Innovation in Aleo Mainnet

As we introduced in this article: https://medium.com/@CFrontier_Labs/the-journey-toward-aleos-universal-zkvm-1df9114fbd86, the prover of Aleo mainnet is a kind of POW prover, which is to compute the puzzle of circuit Synthesis.

Synthesis is a crucial part of ZKP proving. Hardware acceleration of computations like MSM was already achieved in Aleo’s previous testnets. The Aleo team designed the mainnet this way specifically to encourage the community to accelerate the synthesis component.

According to the design, the prover needs to finish a lot of rounds of the R1CS circuit synthesis for a group of instruction sets of Aleo Varuna proving system. The witness will be used to construct a merkle tee, which can be converted to a proof target to compare with the difficulty target. The faster of the computation of circuit synthesis, the higher probability the prover can get the reward of a block.

3. Advanced Performance and ASIC Architecture of AE Box

Based on the AE BOX’s public specifications, here is its performance compared to the RTX 4090.

The ASIC miner demonstrates 20x higher performance than a single RTX 4090, and more significantly, achieves 26x better energy efficiency compared to the RTX 4090 GPU.

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

The AE Box ASIC achieves its exceptional performance and energy efficiency through a hardware architecture comprising these key modules:

1. CHU: Curve hash unit
2. Decoder: Instruction decoder for processing Aleo operations
3. EXU: The instruction execution unit
4. Post processor: To generate the Merkle tree and get the proof target

The ASIC implementation provides substantial improvements over general-purpose computing solutions:

• Significantly reduced power consumption per proof generation
• Higher throughput for puzzle-proof generation
• Specialized architecture optimized for Aleo’s the puzzle computation

4. Technical Evolution and Value Proposition

The development of ASIC technology for ZKP marks a crucial step in the blockchain industry. For Aleo specifically, hardware acceleration through ASICs delivers several key benefits:

• Enhanced network security through increased proving capacity
• Improved energy efficiency compared to general-purpose hardware like GPUs
• Wider community recognition and decentralization as more individual provers join the ecosystem, thanks to the compact system design

Notably, according to Aleo’s proposal **ARC-0043: Extending the Puzzle to a Full SNARK,** the prover will finally support full SNARK proof generation. Furthermore, the prover will also be able to generate Aleo’s client-side proving-AVM prover.

The existing ASIC miner’s technology will serve as a solid foundation for Aleo’s future evolution. Additionally, through continuous iteration of Aleo’s ZK algorithms, ASIC companies like Intchains have accumulated valuable intellectual property (IP) in:

• MSM (Multi-Scalar Multiplication) operations
• NTT (Number Theoretic Transform) computations
• Various Elliptic curve-based hash operators
• ……

Looking ahead, ASIC miner vendors are expected to continue supporting Aleo’s infrastructure through technological upgrades.

Most significantly, the adoption of ASIC technology in the Aleo project will benefit the entire ZK industry, including projects like Ethereum beam chain that require real-time ZK proving.

5. Future Vision

It’s encouraging to see continuous progress in ZKP acceleration, particularly the ASIC adoption in the Aleo project. CF Labs is proud to have built a partnership with Intchains on ZK ASIC design. CF Labs stands at the forefront of hardware acceleration research in ZKP technology. We look forward to advancing the adoption of ZKVM + ASIC solutions to benefit the entire industry.

RISC0 is a zkVM (zero knowledge Virtual Machine) based on the RISCV instruction set and STARK (Scalable Transparency Argument of Knowledge). RISC0 proof system consists with segment prove, recursion and STARK to SNARK proof. As segment prove occupies the largest amount of memory and computation, we focus on the analysis of segment prove process, including RAP, DEEP-ALI and FRI.

1. Purpose
RISC0 is a zkVM (zero knowledge Virtual Machine) based on the RISCV instruction set and STARK (Scalable Transparency Argument of Knowledge). We will introduce the overall proof process in RISC0 and focus on analyzing the segment prove, including its principle and the detailed proof process of the segment. Finally, we will compare the similarities, differences and advantages of RISC0 and other zkVMs.

2. RISC0 proof process

As shown in the figure above, for a program to be proved (composed of countless RISCV instructions, compiled by a high-level language such as rust) and its given input, RISC0 zkVM will execute the program and generate a proof file to prove that the program is executed correctly. At the same time, the proof file cannot contain any sensitive information, such as data generated during the execution process and private input. To this end, RISC0 zkVM will:
A. Execute the program, divide the program into multiple segments, and record the input and output of each segment;
B. Prove each segment and obtain the Receipt of each segment. This step is proved by the STARK/FRI protocol;
C. The Receipts obtained in the above steps are merged into one Receipt using recursive proving, so that proof files of the same length can be generated when proving programs of different sizes;
D. Convert the Receipt obtained by recursive proving into a snark proof through Groth16 to further reduce the proof size.
Segment prove occupies the largest amount of memory and computation. The following will analyze the detailed proof process of segment in detail.

3. Algebraic structure
Segment prove is a proof system based on the STARK protocol. To facilitate the description and understanding of segment prove, we need to introduce the algebraic structure required for the proof process, as shown in the figure below.

Among them,
F, is the finite prime field Fp, that is, F = Fp, p = 2³¹ — 2¹⁷ + 1, Fp is the Baby Bear prime field;
K, is the finite extension field of F, K = F[X]/(X⁴ + 11), that is, the quotient ring of the polynomial ring F[X] about the ideal (X⁴+11). It is easy to know that X⁴+11 is an irreducible polynomial on F, then the extension number of K relative to F is 4, and 1 element in K generally requires 4 elements in F to represent;
Why do we need the extension field K? To ensure security, the sample space where the challenge value is located must be large enough. The number of elements in F is only about 2³¹, while the number of elements in K is about 2¹²⁴.

D0, the cyclic subgroup of the multiplication group F/{0}, whose number of elements |D0|, such as 2²⁰;
H, the subgroup of D0, whose number of elements |H|, such as 2¹⁸, the trace domain; Why do we need the cyclic subgroup H? Because when interpolating and calculating a univariate high-order polynomial f(x), NTT/iNTT is used for efficient calculation, and the premise of NTT/iNTT is that x must be an element in the cyclic subgroup.
H is called the trace domain, which is important in STARK because most of the calculations and representations of all polynomials are performed on H.

wD0, the left coset of D0, w is the element in F that does not belong to D0, such as wD0 = {3*d | d∈D0}, called the commitment domain or evaluation domain. Why is the left coset wD0 needed? w is introduced to achieve zero knowledge. At the same time, polynomial calculations on the coset of the cyclic group only require simple transformation of the polynomial coefficients, and NTT/iNTT can also be used;
When performing segment proofs, it is often necessary to calculate or represent polynomials on the trace domain H and make polynomial commitments on the commitment domain wD0.

4 segment prove
The purpose of segment prove is to prove that the execution process of the sequential instruction stream is correct. This problem is converted into proving that the intermediate process (trace) of the execution satisfies the constraints of the polynomial equation group, and then converted into proving that the degree of a certain polynomial is relatively low (i.e., low-degree test problem). Finally, the FRI protocol is used to prove that the degree of the polynomial is relatively low. Segment prove mainly consists of set-up phase, RAP, DEEP-ALI, and FRI, as shown in the following figure:

The set-up phase configures some proof parameters, such as the number of queries in the query phase of the FRI (Fast Reed-Solomon Interactive oracle proof of proximity) protocol, the maximum length of the trace, etc. At the same time, it will also generate the constraint polynomial between the traces (given in the form of source code, this part of the source code generates the function value of the constraint polynomial on the trace). It is worth noting that for a proven program, the set-up phase only needs to be executed once, and this process will not be discussed later.

RAP (Randomized Algebraic intermediate representation with Preprocessing) will execute the segment and record the intermediate data during the execution process (such as register values, memory access, etc.), with the purpose of calculating the trace polys, including ctrl & data & accumulate polys and commitments, which will be described in detail later.

DEEP-ALI (Domain Extending for Eliminating Pretenders — Algebraic Linking IOP) will calculate the check polynomial and fri polynomial. Check polynomial refers to the result obtained by substituting trace polynomials into the corresponding constraint polynomials and dividing them by the vanish polynomial. This is a key step in STARK, because proving that the execution process of a program is correct is equivalent to proving that the check polynomial is a polynomial and the degree of the polynomial is relatively low. In order to ensure that the calculation process of the check poly is correct, deep polynomials need to be calculated, and finally all deep polynomials are merged into one fri polynomial.

FRI (Fast Reed-Solomon Interactive oracle proof of proximity) aims to prove that the degree of the fri polynomial is less than or equal to the trace domain size. Below, we will introduce its process in detail.

5 RAP
The purpose of RAP is to calculate the control and data polynomial groups, which represent the values ​​of the data register and control register during the segment execution process. In addition, in order to prove the correctness and range check of memory access behavior, a new set of polynomials needs to be generated: the accumulate polynomial group, which is used for permutation argument and lookup argument.
In addition, the merkle tree needs to be used to calculate the polynomial commitment values ​​of the control & data & accumulate polynomial groups respectively.

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

As shown in Figure 4, RAP consists of the following steps:
5.1 preflight/execute, sequentially execute the instructions in the segment, record the register address and value accessed by each instruction as raw_trace, and note that the data type is uint32;
5.2 generate_witness, convert the data in raw_trace into elements in F, calculate the values ​​of all registers in each cycle according to raw_trace, and thus obtain a 2D matrix. Any row represents all register values ​​in a certain cycle, and any column represents the value of a control or data register in all cycles. At the same time, the column is regarded as a function value of a control or data polynomial in the trace domain H, so the number of cycles must be less than or equal to the number of elements in H |H|. If the number of cycles is less than |H|, fill the missing rows of the matrix with 0.

5.3 For the control & data polynomial group (each polynomial is represented by a function value on H), calculate the commitment value of the polynomial:
5.3.1 iNNT calculates the coefficient of each polynomial, noting that the coefficient length of each polynomial is |H|;
5.3.2 Multiply the coefficient of each polynomial by 3^i, such as the coefficient of the nth polynomial is cn_0, ​​…, cn_i, …, then cn_i = cn_i*3^i;
5.3.3 NTT calculates the function value of each polynomial on the commitment domain 3*D0;
5.3.4 Calculate the merkle tree for the function value of the control and data polynomial groups on the commitment domain,
then we will get 2 merkle trees, and the root node of the merkle tree is the commitment value.

5.4 For control & data polynomials (expressed by function values ​​on H), in order to ensure the legality and range check of memory access, it is necessary to introduce the polynomials required by permutation constraints and lookup constraints, namely accumulation polynomials. To this end, it is necessary to:
5.4.1 Generate a random challenge value in the extended domain K for each permutation constraint and lookup constraint based on the commitment value of the existing control and data polynomial groups;
5.4.2 Calculate the polynomial corresponding to each permutation and lookup constraint (expressed by function values ​​on H), which are collectively called accumulation polynomial groups;
5.4.3 Similar to the operation in 5.3, for the accumulation polynomial group, calculate its commitment value.

6. DEEP-ALI
For the convenience of description, we call all polynomials in the control polynomial group, data polynomial group, and accumulation polynomial group trace polynomials, and all function values ​​of all trace polynomials on the trace domain H are called traces.
Our goal is to prove the correctness of the execution of instructions in the segment. This problem is reduced to a set of constraints (expressed as a set of multivariate polynomial equations) that must be satisfied between certain elements in the trace, and the establishment of this problem is equivalent to the constraint polynomial being able to divide the vanish polynomial on the trace domain H. DEEP-ALI will take the quotient of the constraint polynomial and the vanish polynomial to obtain the check polynomial and calculate its commitment value. In addition, to ensure that the check polynomial is calculated correctly, the DEEP polynomial will be calculated, and finally all the DEEP polynomials will be combined to obtain the FRI polynomial.

The definition of the check polynomial is as follows:

Among them,
α_constriants, is a random challenge value, belonging to the extended domain K;
Ci, is a constrained multivariate polynomial;
P0(X), …, is a trace polynomial;
Z(X), is a vanish polynomial on the trace domain, Z(X) = X^|H| — 1, |H| is the number of elements in the trace domain H;
Note that f_validity is check_poly in the RISC0 code, so in this article, we call it check polynomial.

As shown in Figure 5, DEEP-ALI consists of the following steps:
6.1 eval_check, that is, calculating the function value of the check polynomial on the evaluation domain wD0. Because the highest degree of the check polynomial is 4*|H|, the function value needs to be calculated on the evaluation domain wD0 instead of the trace domain H;
6.2 batch iNTT obtains the coefficient of the check polynomial, because the check polynomial is regarded as a polynomial of degree 4*|H| on K, it can be regarded as 16 polynomials of degree |H| on F, thus obtaining a check polynomial polynomial group consisting of 16 polynomials;
6.3 Calculate the function value of each polynomial in the check polynomial group on the commitment domain, and use these function values ​​to construct a merkle tree to obtain the commitment value of the polynomial group;
6.4 Calculate deep polynomials, which is defined as:

The purpose of deep polys is to ensure that the above check polys are calculated honestly.
We believe that check polys are are calculated honestly if a random value z is taken in the extended domain K, and both sides of the equation in eval_check are equal (there is a soundness error);
If check polys are calculated honestly if and only if the rational function is a polynomial function.
Where Pi is trace poly or check poly;
__Pi is the polynomial obtained by interpolating the function value of Pi at different points required to calculate the “constrained multivariate polynomial function value”, such as xi = ωz, ω is the generator of trace domain H.

6.5 Combine all deep polynomial to get fri polynomials.

7. FRI
The purpose of FRI is to prove that the degree of the fri polynomial is less than or equal to the size of the trace domain H. If deg(fri(X)) ≤ |H|, then the check polynomial is a polynomial whose degree ≤ 4*|H|, and the check polynomial is calculated honestly. Then the elements in the trace satisfy the constrained multivariate polynomial equation system, and the instructions in the segment are executed honestly.

FRI includes commit phase and query phase, as shown in Figure 6, which consists of the following steps:
7.1 commit phase, the degree of fri poly is reduced to 256 in multiples of 16, then there are log(16, deg(fri)) rounds, and the polynomial generated by each round is committed. The following calculations are performed for each round:
7.1.1 fri poly is a polynomial of degree |H| on the extended domain K, which can be regarded as an element of degree |H| on four domains F. The function values ​​of the four polynomials on the commitment domain are calculated through batched NTT;
7.1.2 Using the function value of the fri polynomial on the commitment domain, a merkle tree is constructed to obtain the commitment value;
7.1.3 Split the fri polynomial into 16 parts to obtain 16 sub-polynomials, and then use random linear combine to obtain the fri polynomial of the next round.

7.2 Query phase, for all committed polynomials, including control polynomial, data polynomial, accumulate polynomial, check polynomial, log(16, deg(fri)) round fri polynomial, open proof of these polynomials.
7.2.1 Select a random challenge value g0 in the commitment domain;
7.2.2 Construct the elements in the evaluation set, i.e. g0, g0*16, …, g0^(16*round_n);
7.2.3 Open proof of control polynomial, data polynomial, check polynomial at g0, and open proof of the fri polynomial of round i at g0^(16*round_i).

8. Comparison with other zkVMs

Aleo is a Layer-1 blockchain focused on enabling privacy-preserving, scalable decentralized applications using zero-knowledge proofs (ZKP). Since 2019, Aleo has been building a customized ZKVM solution with a unique programming language, Leo, powered by the Aleo Virtual Machine (AVM). Its consensus leverages Proof-of-Work to promote decentralization. In its early testnet, Aleo combined POW with zero-knowledge proofs to construct a puzzle for miners. In its mainnet, it encourages acceleration of trace generation for Leo instructions.

Recently, Aleo published a proposal titled ARC-0043: Extending the Puzzle to a Full SNARK. This proposal aims to have miners generate useful SNARK proofs while reducing the burden on validators to verify the puzzle.

Let’s dive into more detail.

1. Architecture of Aleo

As shown in the picture below, there are two types of provers in the solution:

1. AVM prover. It uses the Varuna proving system, based on AHP R1CS and univariate sumcheck protocol (the “Third Party Prover” part in the left side of the picture).
2. POW prover. It uses a POW mechanism to incentivize provers to compute a puzzle (the “ Prover” part in the right side of the picture).

These two provers are currently distinct.

• The AVM prover is used on the user side to generate a zkSNARK proof, ensuring user and application privacy.
• The POW prover in the existing mainnet stage doesn’t generate a useful SNARK or zkSNARK proof. Instead, it performs computations involving circuit generation for a set of instructions and some Merkle tree hash computations. As a form of POW, randomness is included to have miners demonstrate proof of work.

2. History of Aleo’s POW prover

Here’s a picture illustrating how Aleo has incentivized provers throughout its history.

At each stage, Aleo has been constructing various algorithmic challenges for POW provers to accelerate, including KZG (Testnet 3) and synthesis (Current Mainnet) operations. Aleo also hosts multiple rounds of ZPrize to reward the community for accelerating ZK proving.

As described in the ARC-0043 proposal, it’s time for POW provers to generate a full SNARK.

3. The journey toward universal ZKVM

In the ARC-0043 proposal, Aleo plans to use POW provers to generate SNARK proofs, which are then verified by validators. This approach could eliminate the performance bottleneck in validator verification, as SNARK verification is considerably faster.

If this becomes reality, the community’s POW provers will have the capacity to generate useful SNARK proofs. Note that these don’t necessarily have to be zkSNARK proofs, but SNARK proofs. This development could make Aleo the first project to leverage both major uses of zero-knowledge proofs: privacy preservation (via AVM prover) and computation scaling (via POW prover).

What’s next? Universal AVM prover.

As mentioned by Aleo in a previous article, “Aleo’s innovative approach allows users to outsource proof generation to third-party proving services equipped with advanced computational resources” It would be advantageous if POW prover machines could run the AVM prover, helping users generate ZK proofs or outsource the proving work. This means the AVM prover and the POW prover can be unified at the machine level, creating a universal AVM prover. This development would provide Aleo’s application side or user side with low-cost, high-performance ZKP proving, further advancing the Aleo project and realizing the vision to “build cryptographically secure dApps at scale”.

Get Computation Frontier’s stories in your inbox

Join Medium for free to get updates from this writer.Subscribe

Further potential? Universal ZKVM prover.

As Aleo potentially gains a dominant position with thousands of miners generating AVM ZK proofs at lightning-fast speeds, could it evolve to support various ZKVM proof generations? This evolution could lead to a universal ZKVM prover — not just for Aleo itself, but for other ZKP projects as well. Such a prover could encompass both privacy preservation and computation scaling use cases.

It will be challenging for Aleo to upgrade its algorithms to support different instruction sets and backends. Additionally, continuation technology and proof recursion technology may need to be added. However, if successful, Aleo will create immense value for the mass adoption of zero-knowledge proof technology.

First, by supporting various frontends — not just Leo — the developers’ user experience will improve significantly.

Second, a universal ZKVM prover can benefit the entire ZKP community by providing common ZKP computational power for all ZKP projects.

Moreover, developing an ASIC ZKP machine is costly. A universal ZKVM prover can save substantial development expenses.

At the hardware level, we can consider designing a system compatible with various ZKVM protocols. Alternatively, the hardware could support or be upgraded with minimal changes to accommodate new ZKVMs. It’s worth noting that not only Aleo but other ZKVM projects also have the potential to build such universal platforms.

Regardless, the first step will be to realize ARC-0043. Now, let’s delve into more details about AVM.

4. Introduction to Aleo’s Varuna-based AVM

The zkSNARK proof system in Aleo is Varuna, primarily based on AHP (Algebraic Holographic Proofs) and PCS (Polynomial Commitment Scheme), as shown in the following diagram:

The time-consuming parts are mainly NTT, MSM, and Synthesis, which have already achieved good hardware acceleration (such as ASIC, GPU, etc.). The purpose of Aleo ARC-0043 is to transform the Puzzle in the diagram into a SNARK system, significantly reducing the validation time for validators and thereby increasing block generation speed.

To turn the Puzzle into a SNARK, it’s estimated that the POW Prover would need to perform both synthesis operations and SNARK proof generation. Therefore, the Puzzle prover would need to:

1. Support more Aleo instruction types;
2. Implement AHP and PCS to generate SNARK proofs;
3. Implement modules such as NTT and MSM, simplified from algorithms in the AVM prover.

5. Comparisons of ZKVMs

Aleo’s AVM was introduced several years ago and has now reached mainnet. Since then, other new ZKVMs have emerged. Let’s compare Varuna with some other ZKVMs:

Through this comparison, we can see that Aleo’s Varuna has reached production and mainnet, though it doesn’t use a more general ISA and hasn’t yet supported recursion technology.

It’s possible that Aleo will continue to upgrade to further promote the mass adoption of zero-knowledge proof technology.

6. Summary

We’ve analyzed the history of Aleo provers and its latest ARC-0043, and compared Aleo’s Varuna-based AVM with other ZKVMs. We observe that Aleo is on track to become a platform with abundant, high-performance, and decentralized ZKP provers.