Skip to main content

Verification Layer

The Verification Layer is the first stage of the LayerEdge proof pipeline. It serves as the entry point for zk-proofs generated by external protocols—ranging from simple application-specific SNARKs to advanced ZKVM-based STARK systems.

This layer ensures:

  • All proofs are normalized to a common format, regardless of their cryptographic origin.
  • Only structurally and cryptographically valid proofs are passed downstream for aggregation.
  • Throughput and flexibility are maintained even as new zk-proof formats emerge.

Purpose and Role​

The Verification Layer performs two core responsibilities:

Proof Intake​

Accepts zk-proofs from a wide variety of proving systems, including but not limited to:

  • SNARKs

    • Groth16 (e.g., used in Tornado Cash, Semaphore)
    • PLONK / TurboPLONK (e.g., zkSync)
    • Halo2, Nova (recursive-friendly)

  • STARKs

    • AirSTARK
    • Fractal
    • ZKVMs such as RISC Zero and SP1

This layer abstracts away the cryptographic specifics and allows LayerEdge to support heterogeneous zk ecosystems.

Proof Normalization​

Each submitted proof is translated into a standard intermediate format that can be consumed by downstream recursive circuits and aggregator logic.

This includes:

  • Consistent field and group encoding
  • Canonical curve representation
  • Unified public input serialization
  • Flattened proof metadata

Technical Breakdown​

Interface Definition​

Proof producers interact with the Verification Layer using standardized APIs (e.g., gRPC or REST). The following data must be submitted:

  • ProofData: Raw binary or serialized proof
  • ProofMetadata: Cryptographic context for interpreting and validating the proof

What ProofMetadata Includes​

  • Curve Identifiers: e.g., BN254, BLS12-377, BLS12-381
  • Proof Length: Byte length of the serialized proof
  • Public Input Count: Number of inputs used in the zk computation
  • Verification Key Reference: Hash or ID referencing an on-chain or off-chain verification key or commitment

Validation & Error Handling​

Before forwarding any proof to the aggregator system, the Verification Layer ensures:

  • Elliptic Curve Group Membership: Each curve point must lie on its intended curve
  • Correct Length: Proof size must match expected values per system
  • Input Bounds: Public input size must not exceed circuit limits
  • Structural Sanity: Valid encoding, byte formatting, compression flags, etc.

Proofs failing any of these checks are rejected immediately to protect downstream logic.

Key Innovations​

Adaptive Normalization Pipelines​

The Verification Layer is modular by design. Each zk-proof system (e.g., Groth16, PLONK, STARK) is handled by a separate normalization sub-module. New formats can be added without requiring rewrites of aggregation logic.

This ensures LayerEdge remains compatible with:

  • Next-gen proof systems (e.g., UltraPLONK, zkWASM, BitSNARK)
  • Rollup-specific zk circuits
  • ZKML and AI-optimized provers

Parallel Queues for Scalability​

Proof normalization is highly parallelizable. The system creates per-system queues, meaning Groth16, STARK, and ZKVM-based proofs are parsed concurrently—maximizing throughput.

Queue isolation also prevents a malformed batch in one system from delaying others.

Future Considerations​

As more zk-proving frameworks emerge, the Verification Layer is expected to support:

  • Multi-proof submissions: For batch uploads from rollup sequencers.
  • Custom verification key schemas: For ZKML, recursive rollups, etc.

Summary​

FeatureDescription
Proof Types SupportedGroth16, PLONK, Halo2, Nova, STARKs (AirSTARK, Fractal), ZKVMs (RISC0, SP1)
Standardization OutputCanonical curve elements, normalized Merkle/FRI claims, unified metadata
APIsREST/gRPC endpoints for submission
ValidationCurve checks, proof length, public input count, format sanity
ScalabilityParallel queues, modular normalization, upgradable schema