Beyond Optimistic Rollups: ZK Rollups and zkVMs

Previous articles in this series:

Gelato's Guide to Avalanche L1s and Native Interoperability

L1 Blockchain Stacks: Avalanche vs Cosmos

Rollup L1s: How ABC Stack's Celestia Sovereign Rollup L1s Compare to Avalanche and Cosmos L1 blockchains

OP Stack vs. Arbitrum Orbit: The Best L2 Rollup Comparison

TL;DR

• ZK Rollups use cryptographic validity proofs to verify transaction batches before finalization, eliminating the 7-day challenge window of optimistic rollups and allowing near-instant withdrawals.

• ZK fraud proofs take a hybrid approach: they assume validity unless challenged, blending optimistic rollup efficiency with ZK-level security—though they still require a challenge window.

• zkEVMs range from Type 1 (fully Ethereum-equivalent but slowest to prove) to Type 4 (fastest proofs but require contract rewrites), reflecting a trade-off between compatibility and efficiency.

• Succinct SP1 and RISC Zero zkVM both support LLVM-compiled languages and use recursive STARK-based proving, but differ in architecture, performance optimizations, and proof formats.

• OP Succinct uses SP1 and a Rust implementation of the OP Stack's state transition function to deliver full ZK rollup functionality, reducing finality from 7 days to minutes.

• OP Kailua integrates RISC Zero for a similar result, offering Validity Mode (~1 hr finality) and Hybrid Mode (~3 hrs), while eliminating traditional fraud dispute games and slashing capital costs.

• Users experience fast soft finality on all L2s, but true L1 settlement finality needed for for L2 -> L1 withdrawals still depends on the challenge windows (7 days for optimistic rollups, ~24h for ZK fraud proofs).

• zkVM performance depends heavily on workload complexity, hardware, and parallelism. SP1 often leads in blockchain-native workloads, while RISC Zero shows strong performance across cloud and consumer-grade setups.

• Both SP1 and RISC Zero support GPU acceleration, multi-machine proving, and SNARK-wrapping for efficient on-chain verification—making ZK more scalable and production-ready.

• Celestia enables ZK verification for Sovereign Rollups without full settlement dependence, allowing decentralized state validation with high throughput and modular security.

Fraud proofs vs. validity proofs

As we’ve mentioned previously, optimistic rollups operate under the assumption that all transactions are valid unless proven otherwise. Instead of verifying every transaction immediately, optimistic rollups rely on a "challenge period" during which anyone can dispute a transaction by submitting a fraud proof. A major drawback with optimistic rollups is the withdrawal time from L2 to L1, which can take up to a week due to the mandatory challenge period that allows time for fraud proofs to be submitted and verified.

ZK-Rollups take a completely different approach where every batch of transactions is accompanied by a validity proof (zk-SNARKs or zk-STARKs), which once verified onchain guarantees correctness and finality. Here, transactions are proven valid before being finalized on L1. Unlike Optimistic Rollups, ZK Rollups do not rely on honest participants to monitor transactions. Previously, ZK rollups were cost prohibitive due to the significant computational resources required for generating ZK proofs. However, costs have fallen dramatically in the last several years due to improvements in zkVM design by companies like Succinct and RISC Zero. While these efficiency gains have made ZK approaches increasingly viable, the computational overhead still represents a consideration for implementers when compared to optimistic approaches, though this gap continues to narrow as the technology matures.

Validity proofs vs. ZK fraud proofs

Validity proofs require every batch of transactions to come with a cryptographic proof that is checked onchain. As we’ve mentioned in the previous article, ZK fraud proofs are a newer approach used by solutions like OP Succinct Lite. Here, transactions are assumed valid unless someone challenges them, similar to optimistic rollups. If a challenge happens, a zero-knowledge proof is used to quickly and efficiently prove whether fraud occurred.

ZK fraud proofs improve cost-efficiency by only generating zero-knowledge proofs during disputes, rather than for every transaction. This approach reduces resource usage compared to full ZK rollups, while offering stronger security than traditional fraud proofs. While ZK fraud proofs can enable soft confirmation of transactions in minutes, the protocol still requires a configurable challenge window, typically 12 to 24 hours, to allow for potential challenges.

As zero-knowledge proving technology advances and becomes cheaper and faster, full ZK rollups with instant finality will become practical. Until then, ZK fraud proofs serve as an effective intermediate solution as many teams who are comfortable with optimistic rollups are using ZK fraud proofs as a stepping stone toward full validity proofs.

On challenge windows and finality

Within L2 applications, users already enjoy “soft finality” via sequencer pre-confirmations—now standard across all rollups, whether they use ZK fraud proofs or optimistic mechanisms. Transactions are typically processed in seconds or even milliseconds, enabling responsive app usage without waiting for the full challenge period.

However, economic finality—when canonical L2 assets can safely be withdrawn to Ethereum L1—still depends on the challenge window. ZK fraud proofs can reduce this window from 7 days to mere minutes, since a single validity proof can replace the complex, multi-step interactive fraud proof game. Despite this, most teams conservatively default to ~24-hour windows to account for liveness and censorship assumptions. (See our article on OP Succinct for more.)

In practice, shorter challenge windows don’t always improve UX for major apps like CEXs, which typically credit L2 deposits once the associated L1 data is finalized—usually within 15 minutes. Here, Ethereum’s DA and consensus finality, not the L2 challenge window, is the limiting factor.

That said, shorter challenge windows unlock major capital efficiency gains for infrastructure like bridges, market makers, and exchanges that rebalance inventory across L2s. These improvements ultimately benefit users by enabling lower fees and deeper liquidity for cross-rollup transfers.

Performance benchmarks of zkVMs

Real-world proving costs and latencies will depend on the specifics of the workload, degree of parallelization, and the hardware environment chosen for deployment. The most important concern for production deployments is the cost and latency of offchain proving infrastructure. While onchain verification costs matter, the economics of proof generation dominate the overall cost structure.

Also, performance varies dramatically by transaction type. Simple ERC-20 transfers prove much faster than complex DeFi operations with multiple contract interactions. Computational requirements scale with transaction complexity, causing significant differences in proving times across different real-world applications.

Source: https://blog.succinct.xyz/sp1-turbo/

Above are single GPU performance benchmarks for SP1 and each benchmark represents increasing complex workloads. The “Fibonacci” benchmark (a simple program calculating Fibonacci numbers) represents basic computation. As shown below, with the largest benchmarked workload, RISC Zero requires more time than both SP1 prover types, indicating lower efficiency.

Source: https://zkbenchmarks.com/

Both SP1 and RISC Zero zkVMs support high-performance precompiles for essential hash functions and cryptographic signature verification. These precompiles enable efficient handling of cryptographic operations directly within the VM, significantly boosting performance. Both systems leverage GPU acceleration and parallel proving to further reduce proving times and costs.

SP1 benchmarks are typically run on powerful cloud and enterprise hardware, emphasizing high CPU and GPU throughput for large, memory-intensive workloads and distributed proving, while RISC Zero demonstrates strong performance across both cloud environments and consumer-grade devices, especially on NVIDIA GPUs and Apple Silicon. Both zkVMs offer tooling for custom benchmarking on user hardware.

Performance Trade-offs

In terms of costs, ZK-Rollups require more computing power to generate cryptographic proofs, which is why transactions are batched— the fixed cost of submitting a batch to the L1 blockchain is shared among all users in that batch. This means that as more transactions are included in a batch, the cost per transaction decreases.

Optimistic rollups, on the other hand, are generally simpler and cheaper for users under normal conditions. However, if a dispute arises, participants must stake bonds and pay gas costs according to the specific fraud proof system's design. Bond requirements vary significantly between protocols, with different economic models for who bears risk and costs. While successful challengers are typically compensated, they must initially risk capital. Regular users remain unaffected by these economics unless they're part of a challenged batch.

The choice between them depends on the specific requirements of the application, such as the need for faster finality or privacy. For instance, Aztec is pioneering a hybrid public-private ZK-Rollup that allows users to choose between public and private execution of smart contracts. This means users can keep transaction details, function calls, and even their identities hidden from the public, while still benefiting from Ethereum’s security and compliance features if needed. As ZK matures and computational costs reduce, we can expect to see an increase in usage of ZK-Rollups.

Core Components of ZK Rollup Stacks

ZK Rollups improve blockchain scalability by splitting tasks between onchain and offchain components.

• Onchain Activity: Smart contracts on the main blockchain (like Ethereum) store batches of transactions, verify zero-knowledge proofs, and manage deposits and withdrawals, ensuring the rollup’s data matches the main chain.

• Offchain Activity: This is where most transaction processing happens. The offchain process follows a specific order:

  1. The sequencer first collects and batches transactions from users.

  2. The sequencer computes the new state root after applying all transactions, then publishes the transaction data to the L1 chain.

  3. The prover then generates zero-knowledge proofs that verify all transactions in the batch are valid and the resulting state transition is correct, without revealing private transaction details.

  4. Finally, the proof is submitted to the on-chain contract, which verifies it and updates the official state.

Together, these parts allow ZK Rollups to process many transactions efficiently and securely, while still relying on the main blockchain for security and final settlement.

Industry trends have shifted toward Type-1 provers for ZK rollups. Polygon has moved away from their CDK approach to focus on AggLayer, while ZK Stack continues development in its own direction.

This article examines Type-1 ZK rollup designs from Succinct and RISC Zero. Type-1 zkEVMs generate cryptographic proofs for Ethereum blocks without modifying Ethereum's core protocol, storage structure, or consensus logic. This approach maintains compatibility with existing Ethereum infrastructure while leveraging zero-knowledge technology's security benefits. These implementations represent an important development in addressing blockchain scalability challenges.

What Makes a Type-1 zkEVM?

A Type-1 zkEVM is a fully Ethereum-equivalent execution environment that generates cryptographic proofs for Ethereum blocks without modifying Ethereum's core protocol, storage structure, or consensus logic. Its prover (Type-1) is the computational component responsible for creating these proofs, which verifiers then check to confirm transaction validity.

It’s important to note that the Type-1 prover is increasingly becoming a modular component that can be used by any EVM-compatible chain-not just zkEVM or zkVM. This makes advanced zero-knowledge proofs accessible to a wider range of EVM chains.

zkEVM classifications from Type 1 to Type 4

zkEVMs are categorized by how closely they match Ethereum’s protocol and the efficiency of their zero-knowledge proof generation as originally outlined by Vitalik Buterin. Each type represents a different balance between compatibility with existing Ethereum applications and the computational effort required to generate proofs.

1. Type 1 (Fully Ethereum-Equivalent): Executes Ethereum blocks exactly as the mainnet does, with no changes to protocol, storage, or cryptography-maximizing compatibility but with slowest proof times.

2. Type 2 (EVM-Equivalent): Preserves EVM bytecode compatibility but tweaks underlying components (like hash functions) for faster proofs, with minimal impact on most smart contracts.

   a. Type 2.5 (Gas-Adjusted EVM): Optimizes proof generation by increasing gas costs for ZK-unfriendly operations, improving efficiency but potentially affecting some gas-sensitive contracts.

3. Type 3 (Near-EVM-Equivalent): Removes or modifies complex EVM features for much faster proofs, requiring minor changes to some contracts and tooling.

4. Type 4 (High-Level Language Equivalent): Compiles high-level languages like Solidity directly to ZK circuits, enabling the fastest proofs but sacrificing EVM bytecode compatibility and requiring contract rewrites.

The classification from Type 1 to Type 4 highlights the trade-off between full Ethereum compatibility and proof efficiency. Type 1 zkEVMs maximize compatibility but are slowest to prove. while Type 4 achieves the fastest proofs at the cost of requiring contract changes and losing bytecode equivalence. This spectrum allows developers to select the approach that best fits their application’s needs.

The difference between zkEVM and zkVM

The main difference between zkEVM and zkVM is their scope and compatibility. zkEVMs, like Polygon zkEVM, are designed specifically to replicate the EVM, allowing existing Ethereum smart contracts to run with zero-knowledge proofs for scalability and privacy

On the other hand, zkVMs, such as those developed by Succinct and RISC Zero, are general-purpose virtual machines that can execute programs written in various languages (Rust, C++, etc.), making them more flexible and applicable beyond just Ethereum. This generality allows zkVMs to support a wider range of applications and blockchains.

What is SP1 ZKVM?

SP1 is a performant, open-source ZKVM that lets you prove the execution of arbitrary Rust (or any LLVM-compiled language) programs. It essentially allows developers to generate ZKPs that verify a program has executed correctly without needing to trust the prover, re-execute the program, or know the inputs. You write normal Rust code, compile it into instructions for a special virtual machine, run your program with specific inputs to produce outputs, and then SP1 creates a compact mathematical proof that your program executed correctly.

This proof can be efficiently verified by anyone without them needing to re-run the entire program, which is especially valuable for blockchain applications where you want to perform complex computations offchain while still providing trustworthy on-chain verification of the results.

How SP1 ZKVM works

At its core, SP1 ZKVM runs programs as RISC-V instructions and creates mathematical proofs that verify the program executed correctly, using a step-by-step verification process. First, it produces STARKs (Scalable Transparent Arguments of Knowledge) for program execution traces. SP1's performant STARK recursion allows developers to prove arbitrarily long programs.. These STARKs can then be optionally wrapped into more compact Groth16 or PLONK SNARKs for efficient on-chain verification. This combined approach offers the best of both worlds: developers can use standard Rust libraries to write complex applications while keeping onchain verification costs affordable for blockchain use cases.

Succinct Prover Network

The Succinct Prover Network functions as a distributed system that accelerates the proof generation process by parallelizing the work across multiple machines. When you submit a proving job to the network, rather than generating the computationally intensive ZKP on a single computer, the network shards the task and distributes it among numerous machines working in parallel.

This distributed approach offers significant advantages in both speed and cost-effectiveness. The network utilizes SP1's multi-GPU prover technology (not yet available for local proving), which further accelerates the process.

For production use, the Succinct Prover Network offers two options: on-demand service for general needs, and reserved capacity for high-volume applications that require guaranteed performance, faster processing, and higher throughput.

OP Succinct

OP Succinct combines SP1 (Succinct's general-purpose zkVM) with Kona (a Rust implementation of the OP Stack state transition function) to create a fully ZK-proven rollup with minimal integration complexity.

The system generates proofs for ranges of blocks in parallel before aggregating them for on-chain submission, reducing finality from 7 days to as little as minutes while keeping proving costs low. OP Succinct supports both validity proofs (for every transaction) and ZK fault proofs via OP Succinct Lite (dispute-triggered), giving rollups configuration flexibility to choose the proof mechanism that best fits their needs.

Unlike traditional zkEVMs that require deep cryptography expertise, OP Succinct maintains full EVM equivalence (Type-1) while allowing easy customization through standard Rust code. Existing OP Stack rollups can upgrade to OP Succinct in just two steps: deploying a verification contract that tracks the latest proven state root and running a lightweight proposer service. This approach requires minimal changes to the rollup's infrastructure while delivering the security benefits of ZK proofs and the developer experience advantages of the OP Stack.

How RISC Zero zkVM works

RISC Zero is a zkVM that lets developers prove arbitrary code execution without revealing sensitive data and works with standard languages like Rust and C++, similar to SP1. It functions as a software emulator that implements the RV32IM instruction set (RISC-V base instruction set with multiplication extension). The system is architected with three primary components:

1. Guest Program: The code being proven, written in Rust/C++ and compiled to an ELF binary, with functions for handling inputs, private outputs, and public journal entries.

2. Executor: Runs the ELF binary in a controlled memory environment and records its execution trace as a "session."

3. Prover: Validates the session to generate a cryptographic proof (receipt) containing public outputs (journal) and verification data (seal).

Source: https://dev.risczero.com/api/zkvm/

RISC Zero zkVM Proving Architecture

The zkVM employs a recursive proving system with three specialized circuits:

• The RISC-V Circuit (a STARK circuit for proving correct RISC-V execution)

• The Recursion Circuit (for efficiently verifying STARK proofs and supporting accelerator circuits)

• The STARK-to-SNARK Circuit (for producing compact, blockchain-friendly proofs)

This layered design allows RISC Zero to prove programs of any size while keeping proof size constant. It works by creating proofs for small chunks of execution, then combining these proofs step-by-step until a single proof represents the entire program. This final proof can be compressed into a compact format that's efficient for blockchain verification.

What makes RISC Zero particularly powerful is its straightforward execution model. The zkVM maintains sequential consistency, meaning instructions execute in order without reordering. This simplified model avoids complexities like caches and coherency protocols while still supporting the cryptographic operations necessary for ZK applications.

OP Kailua

Traditional optimistic rollups rely on interactive fraud proofs with lengthy challenge periods that typically last for seven days. OP Kailua offers the security benefits of ZK proofs while maintaining compatibility with existing OP chains, allowing for a phased transition from optimistic to validity proofs. This dramatically reduces finality times from 7 days to as little as 1 hour in Validity Mode (or configurable down to 3 hours in Hybrid Mode), while significantly lowering capital requirements for sequencers.

The implementation executes Ethereum transactions within RISC Zero's RISC-V-based zkVM environment to generate cryptographic proofs of correct execution. This leverages RISC Zero's scale-out design to handle complex computations efficiently.

OP Kailua's architecture validates state transitions by proving the correct execution of the OP Stack's fault proof program through non-interactive ZK proofs. The resulting proof system aims to eliminate multi-round bisection games in favor of single-proof resolution. This approach is designed to provide stronger security guarantees than traditional fault-proof mechanisms.

It only requires one honest sequencer for safety, eliminates dispute processes entirely in Validity Mode, and provides immunity against economic attacks by covering fault proving costs through the adversary's collateral.

Succinct SP1 vs. RISC Zero

Succinct's SP1 zkVM and RISC Zero's zkVM are similar in that both are general-purpose zkVMs designed to let developers prove the execution of code written in standard languages (like Rust or C++) without revealing sensitive data.

Both RISC Zero and SP1 have support for multi-machine proving, which enables efficient proof generation even for programs with very large cycle counts. SP1 users have access to this feature via the SP1 prover network, while RISC Zero users can use Boundless. Additionally, RISC Zero offers local support for multi-machine proving.

Both SP1 and RISC Zero claim performance leadership in different contexts. Succinct now holds the record for the fastest Ethereum block proof, achieving real-time proving with SP1 Hypercube. While RISC Zero shows strong general-purpose performance, SP1 leads in blockchain-specific workloads. Both RISC Zero and SP1 offer a full suite of performant precompiles for blockchain workloads. Both RISC Zero and SP1 offer advanced precompile systems to accelerate cryptographic operations and performance benchmarks continue to evolve rapidly as both teams enhance their implementations.

OP Succinct vs. OP Kailua

OP Succinct and OP Kailua both enable OP Stack rollups to adopt ZK proofs, but they differ in design and implementation. OP Succinct independently implements a validity proof system similar to OP Kailua's 'Validity Mode' for full ZK rollup functionality, while OP Succinct Lite offers a hybrid approach comparable to Kailua's 'Hybrid Mode,' combining ZK and fraud proofs.

Although they share similar modes, OP Succinct is developed independently from OP Kailua, offering an alternative path to integrating ZK into the OP Stack.

Dispute resolution approaches

OP Succinct Lite uses a challenge model where participants can dispute proposed state transitions by submitting on-chain challenges, without needing to propose alternative states. When challenged, the proposer must supply a valid ZK proof to confirm the proposal’s correctness. This process removes the need for interactive fraud proofs and reduces collateral requirements. By contrast, with “full” OP Succinct, every transaction is accompanied by a ZK proof, eliminating disputes entirely.
OP Kailua provides two dispute resolution options. In Hybrid Mode, disputes are resolved with a single ZK proof, so challengers do not need to submit alternative state proposals. In Validity Mode, every transaction is accompanied by a ZK proof, eliminating disputes entirely. Kailua also uses an adaptive timeout system that adjusts finality periods based on network congestion, further streamlining the process.

Both systems support a gradual transition to fully ZK-enabled rollups, allowing teams to adopt advanced security at their own pace. For rollups considering which system to adopt, the decision may depend on specific requirements around finality times, capital efficiency, and long-term ZK strategy.

ABC with Celestia ZK account

What is the purpose of Celestia ZK accounts? For verification without requiring full execution. This means only verification is needed so the base layer only verifies ZK proofs, not full execution.

Sovereign Rollups can adopt ZK verification through offchain validity proofs via decentralized light-client verification without compromising chain sovereignty. Unlike ZK L2s that require anchoring proofs to a settlement layer for security, Sovereign Rollups maintain independent state validation while optionally generating ZK-SNARKs for their execution history to enhance verification capabilities.

ZK is treated more as a verification enhancement rather than a settlement dependency. Developers can implement zk-SNARK light clients for trust-minimized bridging and user verification while retaining gigagas-level throughput from Celestia's modular architecture.

ABC as an L2

As we’ve explained before, Sovereign Rollup L1s offer two polar opposite approaches as they can run on either fully decentralized Celestia or a centralized Gelato Cloud server.

ABC can shift along the sovereignty spectrum toward being a Celestia L2 by posting ZK validity proofs to Celestia for state verification and finality, rather than only using Celestia for data availability. In this configuration, ABC would rely on Celestia's base layer to verify and finalize its state transitions through ZK proofs, establishing Celestia as the ultimate authority for ABC's state.

This approach not only leverages Celestia’s decentralized security and data availability, but also positions ABC to benefit from Celestia’s growing ecosystem as a liquidity and asset issuance hub. By building on Celestia, ABC can access native interoperability with other rollups via Cosmos IBC and Celestia’s native Hyperlane module that was integrated with the recent Lotus upgrade. Hyperlane is also developing a ZK ISM (Interchain Security Module), bringing trust-minimized cross-chain messaging powered by zero-knowledge proofs on Celestia to ABC rollups.

Conclusion

Optimistic rollups, while effective at scaling Ethereum, require a lengthy seven-day challenge period to allow time for fraud proofs, which delays withdrawals and negatively impacts user experience. This week-long window is a conservative safeguard, but it means users must wait days to access their funds.

ZK rollups, by contrast, use cryptographic validity proofs to verify transaction batches before finalization, enabling near-instant withdrawals. This removes the need for challenge periods entirely, offering both stronger security and faster finality. As zkVM technology matures, ZK rollups are becoming increasingly attractive to developers and users alike.

Much of this momentum is driven by advances in zkVM performance. SP1 excels at blockchain-native workloads (i.e., tasks common in smart contracts), while RISC Zero delivers strong results across diverse hardware setups. Both support critical optimizations such as GPU acceleration, multi-machine proving, and SNARK-wrapping for efficient on-chain verification.

Challenges remain: prover centralization, implementation complexity, bug safety, and the need for broader standardization. However, with projects like OP Succinct and OP Kailua enabling smooth upgrade paths from optimistic to validity proofs, the shift to ZK is no longer theoretical. It will still take time, but ZK rollups are well-positioned to quickly become the dominant scaling solution for Ethereum and beyond.

For developers looking to integrate their applications with Gelato Web3 Services, check out Web3 Functions, Relay, and VRF! Visit our Discord server for developer support and engagement, and stay updated with the latest developments by following us on X.

Definitions

• Fraud Proof: A cryptographic proof submitted to show that a transaction or state transition is invalid. Used in optimistic rollups during challenge periods.

• Validity Proof: A proof (like zk-SNARK or zk-STARK) that demonstrates all transactions in a batch are correct before being finalized on-chain. Core to ZK-rollups.

• ZK-Rollup: A Layer 2 scaling solution that bundles transactions off-chain and posts them on-chain with a cryptographic proof (typically a zk-SNARK or zk-STARK) ensuring their validity.

• zk-SNARK: Zero-Knowledge Succinct Non-Interactive Argument of Knowledge — a compact cryptographic proof verifying that a computation was executed correctly without revealing the inputs.

• zk-STARK: Zero-Knowledge Scalable Transparent Argument of Knowledge — a proof system that is more scalable and transparent than SNARKs, but often produces larger proofs.

• zkEVM: A zero-knowledge virtual machine that replicates Ethereum's EVM execution and generates validity proofs for each block or transaction.

• zkVM: A general-purpose zero-knowledge virtual machine that supports broader programming languages (e.g., Rust, C++) and produces cryptographic execution proofs.

• Sequencer: A component in a rollup that orders transactions into batches before proving or validating them.

• Prover: A system or service that generates a zero-knowledge proof to verify that a batch of transactions or a program execution is valid.

• Verifier: An on-chain or off-chain entity that checks the validity proof to confirm correctness without re-executing the computation.

• STARK-to-SNARK Wrapping: A method of converting large STARK proofs into smaller SNARKs to reduce on-chain verification cost.

• RISC-V: An open standard instruction set architecture (ISA) used by zkVMs like RISC Zero and SP1 to simulate execution of programs in a verifiable way.

• LLVML: Low-Level Virtual Machine which is a compiler framework that allows zkVMs like SP1 to compile various high-level languages into verifiable code.

• Groth16 / PLONK: Popular zk-SNARK proof systems. Groth16 is compact and fast to verify, while PLONK supports universal and updatable trusted setups.