Zircuit
  • Introduction
  • Frequently Asked Questions (FAQ)
  • Tokenomics
    • Zircuit Token (ZRC)
    • Bridging ZRC to Zircuit
  • Build on Zircuit
    • Quick Start
    • Deploy on Zircuit
    • Zircuit LST/LRT Liquidity Hub
  • Architecture and Concepts
    • Architecture
      • Modular Prover Design
      • Template Proofs
      • Versions and Updates
    • Concepts
    • Sequencer Level Security (SLS)
    • Gas Pricing and Transaction Fees
    • Transaction Statuses
    • Supported Transaction Types
  • Research
    • Research
    • Publications and Grants
    • Talks and Panels
  • Dev Tools
    • Block Explorer
    • RPC Endpoints
    • Bridge
    • Verifying Contracts
    • ERC20 Tokens with Zircuit Canonical Bridge
    • Development Frameworks
    • CREATE2 Deployments
    • Oracles
    • Indexing and Subgraph
    • Relayers
    • Unsupported Opcodes
    • Precompiles
    • L1 Data Fee Calculation
  • Smart Contracts
    • L1 Contracts
    • L2 Contracts
    • Contract Addresses
    • Bridged Token Addresses
  • Security
    • Security
    • Privileged Roles
    • Bug Bounty
    • Audit Reports
  • Garfield Testnet
    • Garfield Testnet Quick Start
    • Garfield Testnet Bridging Prerequisites
      • Adding the Sepolia Network To Metamask
      • Adding The Zircuit Garfield Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Zircuit Garfield Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Differences & Limitations
    • Contract Addresses
  • Testnet Legacy
    • Legacy Testnet Quick Start
    • Legacy Testnet Bridging Prerequisites
      • Adding The Sepolia Network To Metamask
      • Adding The Zircuit Legacy Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Legacy Zircuit Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Contract Addresses
  • Bridging Step-by-Step
    • Prequisites
      • Adding The Zircuit Network To Metamask
    • Bridging From Sepolia To Zircuit
    • Bridging From Zircuit To Sepolia
    • Completing Withdrawals From Zircuit
    • Bridging ERC20 Tokens Manually
    • Binance Web3 Wallet Task Tutorial
      • Binance Web3 Wallet Tutorial: Bridging back to Ethereum
    • Exploring Bridging Behaviors with EIP-7702
Powered by GitBook
On this page
  • Motivation
  • Specification
  1. Architecture and Concepts
  2. Architecture

Template Proofs

PreviousModular Prover DesignNextVersions and Updates

Last updated 3 months ago

Template proofs are a concept applicable to the legacy version of Zircuit. Garfield Testnet doesn't use template proofs. Zircuit Mainnet will not use template proofs as of the Garfield update in March 2025.

Motivation

On L2, a block is produced every two seconds. The proof system processes block batches and generates a validity proof, which is then verified on L1 to ensure the off-chain work is done correctly. During this process, the circuits are separated to run in parallel, significantly speeding up the proof generation. On top of proof system optimization, having this concurrent design allows for horizontal scaling in the future. However, proof generation remains resource and time-intensive, having multiple independent machines for each proving service comes with a non-trivial cost.

Due to this cost, Zircuit does not provide a proof for every batch. Zircuit uses a so-called template proof for many blocks in order to keep L1 up-to-date with these L2 outputs. The addition of these template proofs ensures a seamless operation by preventing gaps caused by the proof generation process. In the future, these template proofs will be retired, and every block will be associated with a complete validity proof. The use of these template proofs enables Zircuit to scale up proving capacity on-demand over time.

Specification

Template proofs fill the gap between consecutive blocks which have a validity proof.

This process is illustrated in the following figure.

Consecutive green blocks indicates a batch that will have a template proof.

Consecutive teal blocks indicates a batch that will have a validity proof.

When the block provers are available (i.e., not proving something else), consecutive blocks are batched and processed through the proof system. Then, two things happen:

  1. A template proof is generated for all blocks between the enqueued validity proof batch and the previously generated validity proof batch. This template proof is always the same and is recognized by the verifier on L1.

  2. The validity proof and the template proof are published to the L1 Zircuit contracts. The verifier automatically validates the template proof. The validity proof is verified by the L1 Zircuit contracts.

Validity Proofs and Template Proofs