Papers
Topics
Authors
Recent
Search
2000 character limit reached

Formal verification of the S-two AIR

Published 3 Jun 2026 in cs.CR, cs.LO, and cs.PL | (2606.04311v1)

Abstract: StarkWare's S-two prover provides an efficient means for establishing, on blockchain, that a program written in the Cairo virtual machine language runs to completion. The latter claim is encoded by an algebraic intermediate representation (AIR) that captures the semantics of the Cairo language. The AIR asserts the existence of tables of values from a finite field satisfying certain algebraic constraints. A cryptographic interactive proof system, circle STARK, provides an efficiently-checked certificate that the AIR is satisfied. We describe our verification, using the Lean 4 proof assistant, that the AIR encoding is sound, which is to say, the satisfiability of the AIR implies the computational claim.

Summary

  • The paper demonstrates that formal verification using Lean 4 ensures that AIR satisfaction reliably implies valid Cairo VM execution traces.
  • It employs modular proofs with algebraic constraints and logup protocols to guarantee soundness and prevent issues like register overflow.
  • The work offers a compositional methodology for verifying complex cryptographic proofs, reinforcing on-chain security for blockchain applications.

Authoritative Summary of "Formal verification of the S-two AIR" (2606.04311)

Overview and Motivation

The paper presents a rigorous formal verification of StarkWare's S-two AIR (Algebraic Intermediate Representation), which is the core cryptographic protocol underpinning the S-two STARK-based prover for the Cairo virtual machine. The authors employ the Lean 4 proof assistant to model and verify the soundness of AIR encodings, focusing on the mapping between constraint satisfaction in algebraic tables and the existence of valid execution traces for Cairo programs. The verification aims to establish trust in the cryptographic proof system beyond conventional auditing, ensuring that AIR satisfaction genuinely implies valid program execution, given the underlying constraints, message-passing protocols, and component semantics.

Technical Foundations

Formal Verification Methodology

The use of Lean 4, based on dependent type theory, provides a robust formalization environment. The authors leverage Mathlib for foundational mathematics and develop Lean models not only for individual constraints but also for code-generation infrastructures. The AIR generation in S-two is highly modular and compositional, with components, use/yield tuples, and logup protocols built from reusable code gadgets. Instead of exporting and reasoning about raw polynomial sets, the authors strategically ported key infrastructure logic into Lean, verifying that the code yields AIR constraints with intended semantics.

Cairo Virtual Machine and AIR Encoding

The Cairo VM is modeled as a CPU with three registers (pc, fp, ap), operating over a large prime field (Felt252). Program execution and memory assignment are expressed via tables of values from a smaller prime field (M31), designed for cryptographic efficiency. Each AIR component specifies constraints and message tuples (uses/yields), with memory and range-check components providing lookup values. Execution traces are reconstructed by chain lookups—multiset constraints ensuring that state transitions are consistent and cover the agreed initial and final states.

Logup Protocol and Soundness

A key ingredient is the logup protocol, which enables efficient communication between components using sum-of-pole relations over random field elements, yielding subset or equal-count properties on use/yield multisets. The protocol exploits randomness (Fiat–Shamir heuristic, degree-4 extension fields) to ensure negligible soundness error—only a "small" set of random values can falsely witness constraint satisfaction. This construction is formally captured in Lean, where polynomials, multiplicities, and partitioned sums are verified to transfer desired relations (subset/equal count) from field elements back to tuples.

Soundness Theorem

The central theorem asserts: Given AIR tables and logup constraints satisfied (under specific hypotheses about component correctness, range-check assignment, memory lookup bijectivity, construction bookkeeping, and random value selection), there exists an assignment to Cairo VM memory extended from public data, and an execution trace from the initial to final state, with each step conforming to the VM semantics. The number of steps is strictly bounded (≤229\leq 2^{29}), and register/address values are tightly controlled to prevent overflow. The theorem is formalized in Lean; its statement is compositional, reflecting verification of the modular infrastructure and message-passing rather than monolithic constraint sets.

Technical Details

Encoding Felt252s with M31 Felts

Cairo VM values (Felt252) are encoded as tuples of 28 M31 Felts (each range-checked to 9 bits), with careful attention to multiply-represented values and range constraints. Arithmetic operations, especially multiplication, rely on convolution sums, with optimizations (Karatsuba's algorithm) minimizing constraint counts.

Component Modeling

AIR components (e.g., opcode, range-check, memory) are constructed as pure functions in Lean, threading AIR builders and lookup tables via explicit state arguments. Local soundness of each component is proved, leveraging global assumptions about message-passing and lookup correctness to compose the final soundness result.

Logup Constraints

Constraints are built via cumulative partial sums and modular polynomial evaluations. Lemmas formalize subset and chain properties, bounding soundness error by the cardinality of "bad sets" in random choices (zz, α\alpha), which is statistically negligible given extension field size and partitioning. Mapping tuples to single field elements via random α\alpha allows logup relations to apply, with robust bounds on collision probabilities.

Limitations and Hypothesis Management

Certain infrastructure aspects (e.g., bookkeeping around lookup aggregation, preprocessed column verification) are left as explicit hypotheses. The completeness of AIR generation is not proved: only soundness is formally established, i.e., if the protocol says computation occurred, it indeed did, but not necessarily that all valid computations can be encoded within S-two's bounds.

Numerical Results and Strong Claims

  • Execution trace is guaranteed to exist with length ≤229\leq 2^{29}: this bound is enforced by soundness hypotheses and proved as an invariant.
  • Soundness error is negligible due to extension field randomization in logup protocol and worst-case probability bounds.
  • Range-check and memory assignment correctness are essential hypotheses: proofs assume these are externally validated to model component assumptions.
  • Register overflow is provably avoided under initial state bounds and step count constraints, as formally captured in Lean.

Implications and Future Speculations

Practical Security and Blockchain Verification

This formal verification provides cryptographic assurance for on-chain correctness proofs: if S-two certificates pass, users can rely on the underlying Cairo program's semantics, greatly reducing dependence on informal audits or trust assumptions. The methodology enables aggressive protocol optimization—engineers can deploy new constraint gadgets, memory handling, or message-passing, confident that errors will be caught early by Lean verification.

Theoretical Impact

The work demonstrates that modern, compositional proof assistants can scale to complex, highly optimized algebraic encodings. The integration of modular code verification with cryptographic protocol modeling sets a precedent for formally verified ZKP systems, bridging program semantics and algebraic proof generation.

Future Directions

  • Completeness proofs: extending formal verification to prove completeness (every valid execution can be encoded) for S-two AIR under tighter bounds.
  • Automated hypothesis discharge: integrating automated reasoning for bookkeeping aspects and preprocessed column validation.
  • Cross-platform formalization: combining Lean with other proof assistants (e.g., Coq, Isabelle) for multi-language verification pipelines.
  • Protocol extension: adapting logup methodology for more general message-passing, non-deterministic computation, or higher-order relation encoding in AIR.

Conclusion

The authors provide a formal, compositional verification of the S-two AIR encoding, establishing that AIR satisfiability in the S-two protocol implies the existence of a valid Cairo VM execution trace under stringent algebraic and message-passing constraints. The work pioneers the use of proof assistants for cryptographically-secure, on-chain verification of program execution, offering robust guarantees for protocol soundness and practical blockchain deployment (2606.04311).

Paper to Video (Beta)

No one has generated a video about this paper yet.

Sign Up to Generate All Videos Subscribe on YouTube

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Sign Up to Generate

Explain it Like I'm 14

Explaining “Formal verification of the S-two AIR”

What this paper is about (overview)

This paper is about making sure that a special kind of math “receipt” used on blockchains is trustworthy. StarkWare’s S-two system lets someone prove, very efficiently, that a program (written for the Cairo virtual machine) really ran from start to finish and did what it was supposed to do—without revealing all the details. The proof is built from algebra (polynomials over a finite field) and is checked by a verifier. The authors use a tool called the Lean 4 proof assistant (think: a super-strict math checker) to prove a soundness theorem: if the algebraic proof (called an AIR) says “everything checks out,” then there really is a valid program run that matches it.

What the authors set out to do (key objectives)

In plain terms, they wanted to show:

  • If the S-two proof passes its checks, then a real execution of the Cairo program exists that goes from the agreed-upon start to the agreed-upon finish.
  • The many moving parts (“components”) of the proof system fit together correctly: what one part asks for is supplied by another, and all these exchanges are consistent.
  • A special checking method called “logup” (which uses a bit of randomness) really catches cheating with extremely high probability.
  • Numbers used in the proof (small “Felt” numbers) correctly represent the bigger numbers used by the Cairo machine (“Felt252”), even though they live in different number systems.

How they did it (methods and approach)

To explain the approach, it helps to introduce a few ideas with simple analogies.

What is an AIR?

An AIR (Algebraic Intermediate Representation) is like a big checklist written in algebra. Instead of saying “step 1: do X” in words, it says “these polynomials must equal zero.” If all the polynomials check out, the checklist passes.

What are components and messages?

The AIR is built from components, like Lego blocks. Each component:

  • Provides some data (“yields”)—like posting answers on a bulletin board.
  • Uses some data (“uses”)—like taking needed values off that board. The system checks that whenever a component “uses” a value, some component actually “yielded” that exact value. This is organized in “relations,” which are just categories of tuples (small lists of numbers) that must match up.

There are two kinds of matching:

  • Subset matching: every used tuple must appear among the yielded tuples.
  • Chain matching: for special tuples that represent machine states, the multiset of used states equals the multiset of yielded states, so the states connect in a single chain from the start state to the end state.

This chaining is how the system proves “there is a valid step-by-step execution.”

What is the logup protocol?

Imagine tallying how many times each tuple appears, but you don’t want to list them all. Logup uses a trick: it mixes all tuples together with a secret random number so that if someone changes even one tuple, the final mixed value almost surely changes. If the mixed-value check passes, then with very high probability all the uses are truly included in the yields (or match in chains). The authors prove this reasoning is solid and only fails with a tiny probability.

What is Lean 4 and formal verification?

Lean is like a super-strict math teacher that checks every single step of a proof. The authors re-created the essential parts of StarkWare’s AIR-building code in Lean, then proved theorems about it. They focused on the parts where mistakes would be most subtle (the constraints and the message matching) and stated some reasonable assumptions for the rest (like certain bookkeeping that connects all parts together).

How do small and big numbers fit together?

The S-two proofs use numbers in a field modulo the prime 231−12^{31}-1 (call these Felts), because that’s fast for cryptography. But the Cairo virtual machine runs over a different, much larger field modulo a 252-bit prime (Felt252). To bridge the two:

  • Each big Felt252 number is represented as 28 small chunks, each under 292^9 (9 bits). Think of writing a long number in base 292^9 using 28 digits.
  • Range checks guarantee each chunk is small enough.
  • The authors prove that the way these chunks are used and checked really represents the big numbers correctly in the places that matter.

What specific components did they model and prove correct?

They modeled a fixed set of components in Lean:

  • RangeCheck: enforces that numbers are within certain bounds.
  • MemoryAddrToId and MemoryIdToValue: connect memory addresses to unique IDs, then IDs to values (this speeds up copying values).
  • VerifyInstruction: checks that a memory location contains a properly formed instruction (offsets and flags are valid and in range).
  • Opcode components: each enforces one kind of machine step (like “add” or “jump”), using the verified instruction and memory to produce the next machine state (pc,ap,fp)(pc, ap, fp).

They then used chain matching to connect all the step-by-step states into one complete execution from the agreed start to the agreed finish.

What they found (main results) and why it matters

The main result is a soundness theorem. In friendly terms: if all component tables satisfy their algebraic constraints, the logup checks pass, the random choice avoids a tiny “bad set,” and a few reasonable assumptions hold (like the uniqueness of certain memory mappings and correct public memory entries), then:

  • There exists a full memory assignment extending the public data.
  • There exists a sequence of machine states that starts at the agreed start state, ends at the agreed final state, and each step follows the Cairo rules.
  • The number of steps is bounded (at most about 2292^{29} steps in this setup).

This matters because it upgrades trust. It says: “These efficiently checkable proofs really do correspond to real computations,” and a rigorous computer-checked proof in Lean backs that up. For blockchains and smart contracts—where mistakes are costly—this kind of assurance is a big deal.

Why this is important (implications and impact)

This work strengthens confidence in S-two’s proofs on-chain: verifiers can quickly check a proof and be assured that it corresponds to a genuine run of the program. It also shows a practical way to verify very complex proof systems by:

  • Breaking them into components with clear responsibilities.
  • Using message matching (subset and chain) to link components reliably.
  • Applying randomness (logup) to deter cheating with high probability.
  • Carefully translating large-number reasoning into small-number arithmetic with range checks.

There are limits and next steps. The proof focuses on soundness (no false positives) rather than completeness (always being able to produce a proof). Some parts of the system’s global wiring are assumed correct (and could be verified in future work). Still, this is a strong foundation for safer, faster, and more reliable cryptographic proofs that power modern blockchain applications.

View Paper Prompt  View All Prompts 

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a consolidated list of what remains missing, uncertain, or unexplored in the paper, phrased as actionable items for future work.

  • Unverified AIR-builder bookkeeping: Prove that the production infrastructure correctly aggregates all component lookup terms into the cumulative logup constraints (relation IDs, tuple arities, and chain vs. subset classification), and that these match the Lean-modeled ComponentLookupCall/AirBuilder outputs for each release.
  • Preprocessed columns soundness: Mechanize proofs (or certified checks) that preprocessed columns contain exactly the agreed values and enforce the required uniqueness properties (e.g., distinct addresses in MemoryAddrToId, distinct IDs in MemoryIdToValue), closing the current assumptions IsMemAssign and IsRangeCheckAssign.
  • Primality assumptions: Replace Fact (Nat.Prime Stwo.P) and Fact (Nat.Prime Felt252Prime) with machine-checked primality proofs (or link to verified certificates) to shrink the trusted computing base.
  • Cryptographic randomness and Fiat–Shamir: Formalize the random challenge selection (extension-field sampling, PRNG/Fiat–Shamir) and provide a cryptographic argument that the implemented sampler yields negligible soundness error consistent with the algebraic “small bad set” bounds proved in Lean.
  • Quantified soundness error: Give explicit, tight bounds (in Lean) on the bad-set sizes for all logup relations used in the S-two AIR, and relate them to the concrete security parameters of the deployed circle STARK.
  • Extension-field formalization: Model the specific extension field used for logup challenges and its algebraic properties in Lean, and prove all required independence/non-degeneracy facts instead of assuming them.
  • Completeness (dual to soundness): Prove that (under documented resource bounds) the prover can always produce a satisfying AIR for any terminating Cairo trace intended by S-two, or precisely characterize the conditions under which completeness holds/fails (e.g., address/register ranges, trace length).
  • Step and state bounds: Justify and, if possible, tighten or relax the constraints n ≤ 2^29 and the initial-state bound (initialState inp).strongly_bounded₀ 0; provide a per-instruction worst-case analysis ensuring no wrap-around in M31 for all register and PC updates, or propose alternative encodings if longer traces or larger addresses are required.
  • Bridging M31-to-Felt252 reasoning: Generalize and package the ad hoc boundedness lemmas into reusable theorems that systematically lift equalities and inequalities proved over M31 to equalities over ℕ/Felt252 (including precise preconditions for avoiding modular wrap-around).
  • Felt252 encoding adequacy: Provide a complete, component-by-component proof that the 28×9-bit representation is handled correctly everywhere (including non-uniqueness of encodings, carry/borrow behaviors where relevant), and that all operations that rely on equality or ordering of Felt252 values cannot be subverted by alternative encodings.
  • Specialized range checks: Replace the Lean “single RangeCheck” abstraction with verified models of the actual production variants (rc20, rc9_9, etc.), or formally prove their equivalence to the simplified abstraction used in the soundness proof.
  • Instruction coverage: Deliver a coverage proof that the family of Opcode(o) components collectively implements the full Cairo VM instruction set and all flag combinations, with no missing or dead cases.
  • VerifyInstruction fidelity: Provide an end-to-end, bit-level proof that VerifyInstruction exactly matches the Cairo instruction encoding (correct 16-bit offsets and 15 Boolean flags, no malformed encodings accepted), formally linked to the whitepaper’s specification.
  • Chain lookup sufficiency: Prove that multiset equality plus the external start/end states implies a single linearized execution trace covering all transitions (i.e., rules out disjoint cycles or branching), or add and verify explicit uniqueness constraints (e.g., in-/out-degree ≤ 1 per state) that make the implication hold.
  • Memory function well-definedness (production): Mechanize that the production AIR enforces that address→ID and ID→value maps are total and single-valued (no collisions across components, consistency with public memory), not just assumed in Lean.
  • Equivalence with production AIR: Build a translation checker or extraction pipeline that certifies the bit-for-bit equivalence between the AIR actually emitted by S-two (constraints, lookups, relation IDs, tuple lengths) and the Lean-spec model, across versions.
  • Public memory lookups: Verify the pipeline from InputData.mStar to the on-chain external lookups and their inclusion in the cumulative logup (closing PublicMem.LookupsAgree, RelInLookups assumptions), including commitment verification for preprocessed columns.
  • End-to-end trust chain: Integrate verified compiler correctness from Cairo source to casm, and casm-to-AIR correctness, so that the full path (program → AIR → STARK proof → on-chain verification) is covered formally; currently only VM-semantics-to-AIR soundness is established.
  • On-chain verifier alignment: Create a machine-checkable spec for the deployed verifier and prove that its constraint checks and randomness generation match the formal model (or supply a verified reference checker that replays the verification transcript against the Lean spec).
  • Numeric bound tightness and scalability: Reassess numeric parameters (e.g., 229 trace bound) for real workloads; explore alternative representations or parameterizations (wider range tables, different word sizes) that preserve soundness while scaling completeness.
  • Instruction-as-data interactions: Analyze and formalize corner cases where memory cells used as instructions are also used as data; prove that the AIR prevents inconsistencies or unintended bypasses of VerifyInstruction constraints in such scenarios.
  • Dynamic component composition: Generalize the Lean proof from a fixed component set to the production’s dynamically built component graph, or prove that the fixed set suffices for all supported Cairo programs, including future extensions.
View Paper Prompt  View All Prompts 

Practical Applications

Overview

The paper presents a machine-checked soundness proof (in Lean 4) for StarkWare’s S-two AIR: if the AIR’s polynomial constraints and lookup (logup) relations are satisfied, then there exists a Cairo VM execution trace from the agreed initial state to the final state consistent with a partial memory assignment. The work introduces a compositional component/message architecture, a verified logup protocol for subset and chain relations, and a practical method to reason about computations over a 252-bit field using constraints over a 31-bit field (via range-checked chunking). Below are concrete applications grounded in these findings, methods, and innovations.

Immediate Applications

  • Smart-contract and rollup assurance on Starknet (sector: finance/blockchain)
    • What: Stronger trust in S-two-based proofs that Cairo programs executed correctly on L2, because AIR soundness is machine-checked.
    • Tools/workflows: Integrate the Lean proof artifact into release/audit pipelines for S-two and Cairo contracts; publish proof commitments alongside protocol versions; CI checks for AIR changes.
    • Assumptions/dependencies: Correctness of preprocessed columns and AIR construction plumbing; cryptographic soundness of STARKs and randomness selection; primality of the underlying fields; only soundness (not completeness) is proven.
  • Formal audits of Cairo libraries and system contracts (sector: software/finance)
    • What: Use the formal Cairo VM semantics and the S-two soundness theorem to derive end-to-end guarantees for Cairo libfuncs and critical system contracts (e.g., dict ops, signature checks).
    • Tools/workflows: Lean specs + Cairo code audit; replay existing methodology from earlier Cairo proofs with S-two’s AIR.
    • Assumptions/dependencies: Manual modeling effort; assumed correctness of parts of the AIR infrastructure not modeled in Lean.
  • Regression-safe S-two upgrades (sector: blockchain/software tooling)
    • What: Gate changes to AIR components (e.g., opcodes, range-check widths) on proof preservation; breakages surface immediately via Lean checks.
    • Tools/workflows: Mirror AIR builder logic in Lean; bind CI to rerun proofs when component code changes.
    • Assumptions/dependencies: Ongoing effort to keep the Lean model synchronized with production code; unchanged trust base for cryptographic and SDK code.
  • Independent verifier implementations and consistency checks (sector: cryptography/software)
    • What: Implement third-party verifiers guided by the formal statement of constraints and logup semantics; cross-check S-two verifier outputs.
    • Tools/workflows: Spec-driven test harnesses that generate/verify logup constraints and chain relations as encoded in the formalization.
    • Assumptions/dependencies: Accurate extraction of tuples used by the production AIR builder; alignment on randomness derivation and relation indices.
  • Reusable logup protocol for lookups and chaining (sector: cryptography)
    • What: Adopt the verified subset and chain lookup scheme for other AIRs/circuits to ensure use⊆yield and multiset chaining properties with high probability.
    • Tools/workflows: Port logup construction and “bad set” avoidance logic; apply to lookups (e.g., range tables, permutation arguments) in other STARK/PLONK-like systems.
    • Assumptions/dependencies: Same probabilistic soundness guarantees; proper tuple construction and domain separation for relations.
  • Engineering patterns for large-field values via small-field constraints (sector: cryptography)
    • What: Apply the “28×9-bit” chunking with range checks to represent Felt252 values efficiently over M31 in other protocols.
    • Tools/workflows: Library gadgets for chunking, range-checking, and equality/arithmetics via bounded natural-number reasoning.
    • Assumptions/dependencies: Careful bounds to avoid aliasing; correct handling of multiple valid encodings when working modulo the large prime.
  • Developer education and onboarding (sector: education)
    • What: Use the Lean repository and the component/message model to teach Cairo VM semantics, AIRs, and zero-knowledge soundness.
    • Tools/workflows: Hands-on exercises that modify a component and re-run proofs; in-repo tutorials.
    • Assumptions/dependencies: Basic Lean and Cairo familiarity.
  • Improved debugging of proof failures (sector: software development)
    • What: Map verifier failures back to specific component constraints or lookup relations using the structured semantics in Lean.
    • Tools/workflows: Diagnostic tooling linking constraint indices/relations to Lean definitions and source code.
    • Assumptions/dependencies: Accurate cross-referencing between production AIR builder and Lean model; logging of relation IDs and tuple formats.
  • Policy and compliance narratives for provable computation (sector: policy/finance)
    • What: Provide regulators and auditors with machine-checked claims about soundness under explicit assumptions, bolstering compliance for zk-rollups and on-chain finance.
    • Tools/workflows: Human-readable summaries derived from formal statements; independent expert attestations referencing Lean proofs.
    • Assumptions/dependencies: Clear articulation of probabilistic soundness, randomness requirements, and unverified infrastructure steps.

Long-Term Applications

  • End-to-end formally verified rollup stack (sector: blockchain/software/hardware)
    • What: Extend formal proofs to the Cairo compiler, AIR generator plumbing, cryptographic protocols, and verifier, minimizing the trusted computing base.
    • Tools/products: Verified compiler passes (Cairo→casm), verified AIR builders, certified verifiers; possibly verified hardware accelerators for provers.
    • Assumptions/dependencies: Significant formalization effort; stable specifications; collaboration across compiler, crypto, and hardware teams.
  • Automated AIR synthesis from specs with proof certificates (sector: software tooling)
    • What: Generate AIR components and logup constraints directly from high-level specs and emit Lean proofs alongside the AIR description.
    • Tools/products: Spec-to-AIR compilers integrated with Lean proof generation; proof-carrying AIR artifacts.
    • Assumptions/dependencies: Mature spec languages; automation for proof search; robust CI/CD integration.
  • Cross-VM verification frameworks (EVM/WASM/RISC-V) (sector: blockchain/software)
    • What: Port the component/message and chain-lookup blueprint to other VMs to obtain formal soundness for diverse zkVM stacks.
    • Tools/products: VM-specific VerifyInstruction and opcode components; shared logup libraries; standardized relation schemas.
    • Assumptions/dependencies: VM semantics fixed and modeled in Lean; similar lookup efficiency can be achieved; per-VM range and field constraints.
  • Interoperable proof standards and bridges (sector: blockchain interoperability)
    • What: Standardize message/lookup relations and chain semantics to compose proofs across L2s and bridges with formal guarantees.
    • Tools/products: Relation registries, cross-domain lookup adapters, composite proof verifiers.
    • Assumptions/dependencies: Community consensus on standards; consistent domain separation for relations; sustained governance.
  • Verifiable off-chain compute and data pipelines (sector: cloud/AI/data)
    • What: Use sound AIRs and chain lookups to attest step-by-step data transformations or ML inference pipelines, checked on-chain or by auditors.
    • Tools/products: zk job markets where providers must commit to sound AIRs; pipeline-stage components with chained proofs.
    • Assumptions/dependencies: Efficient encoding of non-VM computations; scalability of proof generation; domain-specific gadgets.
  • RegTech frameworks for zk attestations (sector: policy/finance)
    • What: Regulatory acceptance of machine-checked zk-proofs for compliance (e.g., solvency, transaction constraints) built on sound AIR components.
    • Tools/products: Policy-aligned specs; audit dashboards that link reports to Lean-backed proofs.
    • Assumptions/dependencies: Jurisdictional buy-in; clarity on probabilistic soundness and failure probabilities.
  • Supply-chain and process verification via chain lookups (sector: logistics/manufacturing)
    • What: Model each process step as a component and use chain relations to prove the integrity of end-to-end workflows.
    • Tools/products: Domain-specific AIRs for traceability; on-chain verification for critical checkpoints.
    • Assumptions/dependencies: Feasible representation of processes as algebraic constraints; data availability and integrity.
  • Advanced developer tooling and analyzers for Cairo (sector: software development)
    • What: IDE/static analyzers grounded in the formal semantics to detect soundness-impacting patterns, resource bounds, and unsafe encodings.
    • Tools/products: Lints for range/overflow, opcode misuse; auto-suggested proof obligations for tricky code.
    • Assumptions/dependencies: Stable language semantics and libraries; integration with compiler internals.
  • Verified hardware prover pipelines (sector: hardware/energy)
    • What: Combine verified arithmetic kernels and protocol implementations with hardware accelerators (GPU/ASICs) whose correctness is partially proven.
    • Tools/products: High-assurance kernels; formal models of accelerator micro-ops.
    • Assumptions/dependencies: Hardware design cooperation; practical formal verification for performance-critical code.

Key Assumptions and Dependencies (cross-cutting)

  • Cryptographic: STARK soundness under standard assumptions; the pseudo-random challenge is outside a small bad set (negligible failure probability).
  • Mathematical: Primality of M31 and Felt252 moduli; correct modeling of 252-bit values via 9-bit chunks with range checks and careful bound management.
  • Engineering: Correctness of unmodeled AIR infrastructure (e.g., aggregation of lookups, preprocessed columns with distinctness); alignment between production code and Lean models.
  • Scope: The work proves soundness (if AIR is satisfied then an execution exists); completeness (the prover can always produce such an AIR) is out of scope.
  • Trust base: Reliance on Lean’s kernel and Mathlib; external audits and independent checkers can further reduce trust assumptions.
View Paper Prompt  View All Prompts 

Glossary

  • AIR builder: A global data structure used by the AIR-generation infrastructure to collect constraints and messages for components. "A central data structure, the AIR builder, maintains the list of components, and the polynomial constraints and messages associated to each."
  • algebraic intermediate representation (AIR): A system of algebraic constraints that encodes a computation so it can be checked via cryptographic proofs. "The latter claim is encoded by an algebraic intermediate representation (AIR) that captures the semantics of the Cairo language."
  • Cairo-AIR: The specific AIR encoding of the Cairo virtual machine semantics used in the system. "We refer to this AIR as the Cairo-AIR."
  • Cairo virtual machine: The abstract machine executing Cairo programs, with registers and a field-based memory model. "The program is compiled to instructions for the Cairo virtual machine"
  • CairoZero: A predecessor version of the Cairo language and toolchain. "CairoZero (a predecessor to the current version of Cairo)"
  • casm: Short for Cairo assembly language; a lower-level representation of Cairo VM instructions. "In StarkWare terminology, “casm” is short for “Cairo assembly language,” which provides convenient representations of virtual machine code instructions."
  • casm state: A triple (pc, fp, ap) over the underlying field, representing the VM registers in casm. "Thus, below and in our formalization, a “casm state” refers to a triple (pc, fp, ap) of elements of the underlying field."
  • chain lookups: A special lookup mode requiring multiset equality of uses and yields to enforce chaining of state transitions. "The underlying cryptographic protocol has a special variant of the message-passing protocol, chain lookups, that ensures that the pairs (s, s′) verified by the relevant components chain together in this way."
  • circle STARK: A particular STARK-based interactive proof system used to certify AIR satisfiability. "A cryptographic interactive proof system, circle STARK \cite{habock:levit:papini:24}, provides an efficiently-checked certificate that the AIR is satisfied."
  • cumulative logup constraints: The global set of algebraic constraints produced by the logup protocol to enforce relations between use and yield tuples across components. "The satisfaction by these tuples of the cumulative logup constraints, which are explained in Section~\ref{section:logups}, guarantees, with high probability, that certain relations hold between the use and yield tuples of each relation."
  • dependent type theory: The foundational logical framework underlying Lean, enabling types that depend on values. "Lean is based on a version of dependent type theory whose logical strength is just slightly stronger than Zermelo--Fraenkel set theory"
  • extension field: A larger field containing the base field, used here to sample randomness for the logup argument. "it involves picking a pseudo-random field element from an extension field."
  • Felt: An element of the prime field used by S-two (M31); shorthand for “field element.” "In our verification and below we refer to elements of the first field as Felts, short for “field elements,” and elements of the second field as Felt252s."
  • Felt252: An element of the 252-bit prime field used by the Cairo VM. "In our verification and below we refer to elements of the first field as Felts, short for “field elements,” and elements of the second field as Felt252s."
  • Felt252 prime: The specific 252-bit prime modulus defining the Cairo VM field. "In the Cairo virtual machine, \lstinline{F} is the field of integers modulo the Felt252 prime, defined as follows:"
  • kernel: The small, trusted core of a proof assistant that checks proofs against the axioms and rules. "by carefully-written code that is known as the kernel, or trusted computing base."
  • Lean 4: A programming language and interactive proof assistant used for formal verification in the project. "For this project, we used the Lean 4 programming language and proof assistant"
  • logup protocol: An algebraic lookup argument that enforces subset/chain relations between use and yield tuples with high probability. "Section~\ref{section:logups} breaks out an important ingredient, the logup protocol, which provides a general scheme for sharing information between components in an efficient way."
  • lookup components: Components that only produce (yield) tuples for others to consume, without issuing their own uses. "Some components have only yield values, and are referred to in the S-two whitepaper as lookup components, since their function is to provide values for other components to use."
  • Mathlib: The standard mathematical library for Lean, providing a large base of formalized mathematics. "users can draw on a large library, Mathlib \cite{mathlib}, of formalized mathematics"
  • M31: The prime field Z/(231−1) used by the S-two AIR for efficiency. "The S-two AIR works over the field M31\mathsf{M31} -- the field of integers modulo the prime 231−12^{31} - 1, a value chosen carefully for efficient cryptographic computation."
  • message buffer: The collection where evaluated use and yield tuples are tagged and stored for cross-component matching. "It therefore uses values in the message buffer tagged as coming from these components, and yields tuples consisting of 19 Felts satisfying the corresponding constraints."
  • message channel: The abstraction over which components exchange use and yield tuples in the AIR. "the S-two AIR is best understood in terms of components exchanging messages over a message channel."
  • multiset: A set-like collection where elements have multiplicities, used to enforce chain-equality between uses and yields. "requiring, for these lookups, that the multiset of use values equals the multiset of yield values"
  • next state relation: The formal relation specifying how one VM register state transitions to the next under the Cairo semantics. "culminating in a definition of the next state relation for the virtual machine"
  • opcode components: Per-instruction components that verify the correct state transition for a specific Cairo opcode. "\lstinline{Opcode} components: each of the opcode components takes as input a Cairo register state"
  • preprocessed columns: Agreed, fixed columns embedded in the AIR so the prover and verifier share common data (e.g., ranges). "using a mechanism known as preprocessed columns \cite{habock:levit:papini:24}."
  • proof assistant: Software that helps construct and mechanically check formal proofs within a foundational system. "A proof assistant provides a very strong guarantee that a formally-specified claim has a formal proof according to the axioms and rules of the axiomatic foundation."
  • RangeCheck: A lookup component yielding small-range values so other components can verify bounds via lookups. "For example, a \lstinline{RangeCheck} component yields all values in the range [0,M)[0, M) for a fixed natural number MM."
  • soundness theorem: A result that shows if the AIR is satisfied, then the claimed computation actually exists (up to negligible error from the protocol). "our soundness theorem says that if a given instance of the S-two AIR encoding satisfies the Cairo-AIR with respect to a partial assignment to memory, then there is a full assignment to the memory and an execution trace of the Cairo virtual machine"
  • STARK certificate: The proof artifact produced by a STARK protocol that certifies AIR satisfiability. "and that the STARK certificate warrants the satisfiability of the Cairo-AIR constraints."
  • trusted computing base: The minimal set of components that must be correct for the guarantees to hold (e.g., the kernel). "by carefully-written code that is known as the kernel, or trusted computing base."
  • use-yield correspondences: The matching between a component’s “uses” (inputs) and other components’ “yields” (outputs) enforced by the lookup protocol. "the existence of tables of values satisfying the polynomial constraints and the use-yield correspondences implies the existence of an execution trace of the Cairo machine code."
  • ZMod: Lean’s type of integers modulo n, used to model finite fields. "Here \lstinline{ZMod n} is the Mathlib definition of the integers modulo \lstinline{n}."
View Paper Prompt  View All Prompts 

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Generate Now

Collections

Sign up for free to add this paper to one or more collections.

Sign Up

Tweets

Sign up for free to view the 3 tweets with 55 likes about this paper.

Sign Up for Free