Longfellow ZK

Longfellow ZK Google

matteof@google.com

Google

shelat@google.com

Internet Network Working Group This document defines an algorithm for generating and verifying a succinct non-interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0.

Introduction A zero-knowledge (ZK) scheme allows a Prover who holds an arithmetic circuit C defined over a finite field F and two inputs (x,w) to convince a Verifier who holds only (C,x) that the Prover knows w such that C(x,w) = 0 without revealing any extra information to the Verifier. The concept of a zero-knowledge scheme was introduced by Goldwasser, Micali, and Rackoff , and has since been rigourously explored and optimized in the academic literature. There are several models and efficiency goals that different ZK schemes aim to achieve, such as reducing prover time, reducing verifier time, or reducing proof size. Some ZK schemes also impose other requirements to achieve their efficienc goals. This document considers the scenario in which there are no common reference strings, or trusted parameter setups that are available to the parties. This immediately rules out several succinct ZK scheme from the literature. In addition, this document also focuses on schemes that can be instantiated from a collision-resistant hash function and require no other complexity theoretic assumption. Again, this rules out several schemes in the literature. All of the ZK schemes from the literature that remain can be defined in the Interactive Oracle Proof (IOP) model, and this document specifies a family of them that enjoys both efficiency and simplicity.

The Longfellow system This document specifies the Longfellow ZK scheme described in the paper . The scheme is constructed from two components: the first is the Ligero scheme, which provides a cryptographic commitment scheme that supports an efficient ZK argument system that enables proving linear and quadratic constraints on the committed witness, and the second is a public-coin interactive protocol (IP) for producing an argument that C(x,w)=0 where C is such a circuit, x is a public input, and w is a private witness. The overall scheme works by having the Prover commit to the witness w as well as a pad used to commit the transcript of the IP, then to run the IP with the verifier in a way that produces a commitment to the transcript of the IP, and finally, by running the Ligero proof system to prove that the transcript in the commitment induces the IP verifier to accept. A companion document specifies how the circuit C is specified.

Basic Operations and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 6919 . Except if said otherwise, random choices in this specification refer to drawing with uniform distribution from a given set (i.e., "random" is short for "uniformly random"). Random choices can be replaced with fresh outputs from a cryptographically strong pseudorandom generator, according to the requirements in , or pseudorandom function.

Array primitives The notation A[0..N] refers to the array of size N that contains A[0],A[1],...,A[N-1], i.e., the right-boundary in the notation X..Y is an exclusive index bound. The following functions are used throughout the document:

copy(n, Dst, Src): copies n elements from Src to Dst with different strides
axpy(n, Y, A, X): sets Y[i] += A*X[i] for 0 <= i < n.
sum(n, A): computes the sum of the first n elements in array A
dot(n, A, Y): computes the dot product of length n between arrays A and Y.
add(n, A, Y): returns the array [A[0]+Y[0], A[1]+Y[1], ..., A[n-1]+Y[n-1]].
prod(n, A, Y): returns the array [A[0]*Y[0], A[1]*Y[1], ..., A[n-1]*Y[n-1]].
equal(n, A, Y): true if A[i]==Y[i] for 0 <= i < n and false otherwise.
gather(n, A, I): returns the array [A[I[0]], A[I[1]], ..., A[I[n-1]].
A[n][m] = [0]: initializes the 2-dimensional n x m array A to all zeroes.
A[0..NREQ] = X : array assignment, this operation copies the first NREQ elements of X into the corresponding indicies of the A array.

Polynomial operations This section describes operations on and associated with polynomials that are used in the main protocol.

Extend method in Field F_p The extend(f, n, m) method interprets the array f[0..n] as the evaluations of a polynomial P of degree less than n at the points 0,...,n-1, and returns the evaluations of the same P at the points 0,...,m-1. For sufficiently large fields |F_p| = p >= m, polynomial P is uniquely determined by the input, and thus extend is well defined. As there are several algorithms for efficiently performing the extend operation, the implementor can choose a suitable one. In some cases, the brute force method of using Lagrange interpolation formulas to compute each output point independently may suffice. One can employ a convolution to implement the extend operation, and in some cases, either the Number Theoretic Transform or Nussbaumer's algorithm can be used to efficiently compute a convolution.

Extend method in Field GF 2^k The previous section described an extend method that applies to odd prime-order finite fields which contain the elements 0,1,2...,m. In the special case of GF(2^k), the extend operator is defined in an opinionated way inspired by the Additive FFT algorithm by Lin et al . Lin et al. define a novel polynomial basis for polynomials as an alternative to the usual monomial basis xⁱ, and give an algorithm for evaluating a degree-(d-1) polynomial at all d points in a subspace, for d=2^ell, and for polynomials expressed in the novel basis. Specifically, this document implements GF(2¹²⁸) as GF{2}[x] / (Q(x)) where With this choice of Q(x), x is a generator of the multiplicative group of the field. Next, choose GF(2¹⁶) as the subfield of GF(2¹²⁸) with g=x^{(2^{128}-1) / (2^{16}-1)} as its generator, and beta_i=g^i^ for 0 <= i < 16 as the basis of the subfield. For relevant problem sizes, this allows encoding elements in a commitment scheme with 16-bits instead of 128. Writing j_i for the i-th bit of the binary representation of j, that is, inject integer j into a field element inj(j) by interpreting the bits of j as coordinates in terms of the basis: In this setting, define the extend operator to interpret the array f[0..n] to consist of the evaluations of a polynomial p(x) of degree at most n-1 at the n points x \in { inj(i) : 0 <= i < n } and to return the set { p(inj(i)) : 0 <= i < m} which consist of the evaluations of the same polynomial p(x) at the injected points 0,...,m-1. This convention allows this operation to be completed efficiently using various forms of the additive FFT as described in .

Fiat-Shamir primitives A ZK protocol may in general instruct the Prover and Verifier to engage in multiple rounds of communication. However, it is often more convenient to deploy a non-interactive or single-message protocol that only requires a single message from Prover to Verifier. It is possible to apply the Fiat-Shamir heuristic to transform an Interactive Oracle Protocol (IOP) into a single-message protocol. In this variant of the protocol, the Verifier does not explicitly send challenges to the Prover; instead, the Verifier computes the challenges by hashing the transcript of the conversation so far. While the base Fiat-Shamir framework is described in , Interactive Oracle Proofs require more structured multi-round transcripts and multi-challenge extractions (such as combinations without replacement for column queries). The subsections below define a complete, self-contained specification of the Hash-and-Expand transcript instantiation and Universal ZK TLV Codec aligning with the IOP extensions proposed for the CFRG Fiat-Shamir draft. The Fiat-Shamir transform is a method for generating a verifier's public-coin challenges by processing the concatenation of all preceding prover messages. The transform is proven to be sound when applied to an interactive protocol that is round-by-round sound and when the oracle is implemented with a hash function satisfying correlation-intractability with respect to the relation's verification state function (see ). While standard Sigma protocols operate in a single round with scalar challenges, Interactive Oracle Proofs (IOPs) such as Longfellow require structured, multi-round transcripts with typed messages (byte strings, field elements, arrays of field elements) and multi-challenge extractions (such as combinations without replacement for column queries and subfield elements).

The Hash-and-Expand Duplex Sponge Instantiation The transcript is modeled as a stateful object maintaining an internal string tr (or incrementally updated hash state) and a pseudorandom stream generator. In the SHA256-AES256CTR ciphersuite:

Absorb: Prover messages are appended to tr using the Universal ZK TLV Codec.
Squeeze: When a verifier challenge is requested, the transcript derives a 32-byte key \text{SEED} = H(\text{tr}) using SHA-256. This seed initializes a Fiat-Shamir Pseudorandom Function (FsPrf) running AES-256 in counter mode.

The FSPRF Keystream Generator The FsPrf object generates an infinite sequence of pseudorandom bytes organized into 16-byte blocks. Block i (for i \ge 0) is computed as: where SEED is the 32-byte hash digest H(\text{tr}), and ID(i) is the 16-byte little-endian encoding of integer i. Self { let key_arr = GenericArray::from(key); let cipher = Aes256::new(&key_arr); Self { _key: key, cipher, block_counter: 0, read_pointer: 16, // Force refill on first read output_buffer: [0u8; 16], } } fn refill(&mut self) { assert!(self.block_counter < 0x10000000000); let mut inp = [0u8; 16]; for i in 0..8 { inp[i] = ((self.block_counter >> (8 * i)) & 0xff) as u8; } let mut block = GenericArray::from(inp); self.cipher.encrypt_block(&mut block); self.output_buffer.copy_from_slice(&block); self.block_counter += 1; self.read_pointer = 0; } pub fn get_bytes(&mut self, len: usize) -> Vec { let mut buf = Vec::with_capacity(len); for _ in 0..len { if self.read_pointer >= 16 { self.refill(); } buf.push(self.output_buffer[self.read_pointer]); self.read_pointer += 1; } buf } } ]]>

Universal ZK TLV Codec To ensure prefix-free and unambiguous parsing of multi-round interactive oracle proofs, all prover messages absorbed by the transcript are framed with explicit type tags:

Byte Array (TAG_BSTR = 0x00): Serialized as the 1-byte tag 0x00, followed by an 8-byte little-endian length prefix, followed by the raw bytes:
Field Element (TAG_FIELD_ELEM = 0x01): Serialized as the 1-byte tag 0x01, followed directly by the canonical byte serialization of the field element (length is fixed by the field definition):
Field Element Array (TAG_ARRAY = 0x02): Serialized as the 1-byte tag 0x02, followed by an 8-byte little-endian count prefix, followed by the concatenated canonical byte serializations of all field elements:

, } impl Transcript { pub fn new(init: &[u8]) -> Self { let mut t = Self { hash_accumulator: Sha256::new(), pseudorandom_generator: None, }; t.write_bytes(init); t } pub fn get_hash(&self) -> [u8; 32] { let h = self.hash_accumulator.clone(); let digest = h.finalize(); let mut res = [0u8; 32]; res.copy_from_slice(&digest); res } pub fn write_untyped(&mut self, data: &[u8]) { self.pseudorandom_generator = None; self.hash_accumulator.update(data); } pub fn tag(&mut self, tg: u8) { self.write_untyped(&[tg]); } pub fn write_length(&mut self, x: usize) { let x_u64 = x as u64; let mut len_bytes = [0u8; 8]; for i in 0..8 { len_bytes[i] = ((x_u64 >> (8 * i)) & 0xff) as u8; } self.write_untyped(&len_bytes); } pub fn write_bytes(&mut self, data: &[u8]) { self.tag(TAG_BSTR); self.write_length(data.len()); self.write_untyped(data); } pub fn write0(&mut self, n: usize) { self.tag(TAG_BSTR); self.write_length(n); let data = vec![0x00; n]; self.write_untyped(&data); } pub fn write_untyped_elt(&mut self, e: F) { let b = e.to_bytes(); self.write_untyped(&b); } pub fn write_elt_field(&mut self, e: F) { self.tag(TAG_FIELD_ELEM); self.write_untyped_elt(e); } pub fn write_elt_field_slice(&mut self, e: &[F]) { self.tag(TAG_ARRAY); self.write_length(e.len()); for elt in e { self.write_untyped_elt(*elt); } } pub fn get_random_bytes(&mut self, len: usize) -> Vec { if self.pseudorandom_generator.is_none() { let key = self.get_hash(); self.pseudorandom_generator = Some(FsPrf::new(key)); } self.pseudorandom_generator.as_mut().unwrap().get_bytes(len) } } ]]>

Correlation-Intractability and Computational Depth The security of the Fiat-Shamir transformation relies on correlation intractability. When proving arbitrary circuit satisfiability or recursive statements, a malicious prover might attempt self-referential attacks if the circuit's complexity exceeds the depth required to compute the random oracle. To prevent self-referential attacks (see ), the first prover message in Longfellow enforces that the oracle's computational depth exceeds the verification logic of circuit C:

Absorb the initial prover commitment (session_id and initial matrix commitment root).
Absorb the statement encoding: circuit identifier id, public inputs, and outputs.
Absorb 0^{|C|} via write0(|C|) (a byte array of |C| zero bytes, where |C| is the gate count of the circuit).

Challenge Extraction Methods In the CFRG Fiat-Shamir framework (), challenge extraction is formalized as the decoding component of a codec. While the codec's prover_message procedure serializes and absorbs prover messages into the sponge state, its verifier_challenge procedure squeezes uniformly distributed pseudorandom bytes and decodes them into the verifier's target challenge domain. For Interactive Oracle Proofs, the codec defines four decoding procedures that translate the raw byte stream into structured verifier challenges:

Bounded Natural Numbers (generate_nat / nat) Samples a uniformly distributed integer in [0, m - 1] via minimal bitmask rejection sampling: usize { assert!(n > 0, "nat(0) is undefined"); let mut nn = n; let mut l = 0; while nn != 0 { nn >>= 8; l += 1; } let mut msk = 0; while (n & msk) != n { msk = (msk << 1) | 1; } loop { let b = self.bytes(l); let mut r = 0usize; for i in (0..l).rev() { r = (r << 8) | (b[i] as usize); } r &= msk; if r < n { return r; } } } } ]]>

Combinations Without Replacement (generate_nats_wo_replacement / choose) Samples k distinct natural numbers uniformly from [0, n - 1] without replacement (used for Ligero column query indices) using an in-place Fisher-Yates shuffle: Vec { if n == 0 || k == 0 { return Vec::new(); } assert!(n >= k); let mut a: Vec = (0..n).collect(); let mut res = vec![0; k]; for i in 0..k { let val = self.nat(n - i); let j = i + val; a.swap(i, j); res[i] = a[i]; } res } } ]]>

Field Elements and Vectors (generate_field / generate_challenge)

Prime Fields (e.g. NIST P-256 scalar field \mathbb{F}_p): Samples 32 bytes from bytes(32) and rejects if the integer value \ge p.
Binary Extension Fields (e.g. \text{GF}(2^{128})): Samples 16 bytes directly from bytes(16) and interprets them as the polynomial coefficients in \text{GF}(2)[X]/(X^{128} + X^7 + X^2 + X + 1). Subfield elements in \text{GF}(2^{16}) sample 2 bytes from bytes(2) and map to the subfield basis.

(&mut self) -> F { F::sample(self) } pub fn generate_challenge(&mut self, n: usize) -> Vec { (0..n).map(|_| self.get_elt_field::()).collect() } } impl Rng for Transcript { fn bytes(&mut self, len: usize) -> Vec { self.get_random_bytes(len) } } ]]>

Ligero ZK Proof This section specifies the construction and verification method for a Ligero commitment and zero-knowledge argument. The Ligero system as described by Ames, Hazay, Ishai, and Venkitasubramaniam , consists of a commitment scheme, and a method for proving linear and quadratic constraints on the committed values in zero-knowledge. The latter interface is sufficient to prove arbitrary circuits, but in the Longfellow scheme, it suffices to describe how to use such constraints to directly verify an IP transcript.

Merkle trees This section describes how to construct a Merkle tree from a sequence of n strings, and how to verify that a given string x was placed at leaf i in a Merkle tree. These methods do not assume that n is a power of two. This construction is parameterized by the cryptographic hash function SHA-256 . In this application, a leaf in a tree is a message digest instead of an arbitrary string; for example, when the hash function is SHA-256, then the leaf is a 32-byte string. A tree that contains n leaves is represented by an array of 2 * n message digests in which the input digests are written at indicies n..2*n. The tree is constructed by iteratively hashing the concatenation of the values at indicies 2*j and 2*j+1, starting at j=n-1, and continuing until j=1. The root is at index 1. In this specification, the prover and verifier will already know the value of n when they produce or verify a Merkle tree.

Blinding the leaves with nonces As per folklore, a Merkle commitment does not hash a leaf's data directly, but instead includes a fresh random nonce of 32 bytes for every leaf. The leaf digest is the hash of that nonce followed by the leaf's data. ( num_leaves: usize, update_leaf_hash_fn: F, rng: &mut R, ) -> (MerkleHeap, Vec>) where R: Rng, F: Fn(usize) -> Vec, { let mut nonces = Vec::with_capacity(num_leaves); for _ in 0..num_leaves { nonces.push(rng.bytes(32)); } let mut leaves_digests = Vec::with_capacity(num_leaves); for i in 0..num_leaves { let mut data = Vec::new(); data.extend_from_slice(&nonces[i]); data.extend_from_slice(&update_leaf_hash_fn(i)); leaves_digests.push(sha256_bytes(&data)); } let heap = MerkleHeap::new(&leaves_digests); (heap, nonces) } ]]> The nonces are retained by the prover. One nonce is generated per leaf, but only the NREQ nonces belonging to the opened columns are revealed, and those are sent as part of the proof; the nonces of the unopened columns are never disclosed. A verifier recomputes the digest of an opened leaf in the same order, nonce first, as shown in the verify_merkle function of the Ligero verification procedure below. Because the nonces are secret and uniformly random, the unopened leaves are computationally hidden. The functions in the remainder of this section operate on the leaf digests produced above, and are therefore stated without reference to the nonces.

Constructing a Merkle tree from n digests Vec { let mut hasher = Sha256::new(); hasher.update(data); hasher.finalize().to_vec() } #[derive(Clone, Debug)] pub struct MerkleHeap { pub num_leaves: usize, pub layers: Vec>, pub root: Vec, } impl MerkleHeap { pub fn new(leaves: &[Vec]) -> Self { let n = leaves.len(); let mut layers = vec![Vec::new(); 2 * n]; layers[n..(n + n)].clone_from_slice(&leaves[..n]); for i in (1..n).rev() { let mut data = Vec::new(); data.extend_from_slice(&layers[2 * i]); data.extend_from_slice(&layers[2 * i + 1]); layers[i] = sha256_bytes(&data); } let root = layers[1].clone(); Self { num_leaves: n, layers, root, } } } ]]>

Constructing a proof of inclusion This section describes how to construct a Merkle proof that k input digests at indicies i[0],...,i[k-1] belong to the tree. The simplest way to generate such a proof is to produce independent proofs for each of the k leaves. However, this turns out to be wasteful in that internal nodes may be included multiple times along different paths, and some nodes may not need to be included at all because they are implied by nodes that have already been included. To address these inefficiencies, this section explains how to produce a batch proof of inclusion for k leaves. The main idea is to start from the requested set of leaves and build all of the implied internal nodes given the leaves. For example, if sibling leaves are included, then their parent is implied, and the parent need not be included in the compressed proof. Then it suffices to revisit the same tree and include the necessary siblings along all of the Merkle paths. It is assumed that the verifier already has the leaf digests that are at the indicies, and thus the proof only contains the necessary internal nodes of the Merkle tree that are used to verify the claim. It is important in this formulation to treat the input digests as a sequence, i.e. with a given order. Both the prover and verifier of this batch proof must use the same order of the requested_leaves array. Result>, &'static str> { let n = mh.num_leaves; let mut seen = vec![false; n]; let mut is_on_path = vec![false; 2 * n]; for &idx in leaf_indices { if idx >= n { return Err("Leaf index out of bounds in Merkle opening"); } if seen[idx] { return Err("Duplicate leaf index in Merkle opening"); } seen[idx] = true; is_on_path[n + idx] = true; } for i in (1..n).rev() { is_on_path[i] = is_on_path[2 * i] || is_on_path[2 * i + 1]; } let mut path = Vec::new(); for i in (1..n).rev() { if is_on_path[i] { if is_on_path[2 * i] && !is_on_path[2 * i + 1] { path.push(mh.layers[2 * i + 1].clone()); } else if !is_on_path[2 * i] && is_on_path[2 * i + 1] { path.push(mh.layers[2 * i].clone()); } } } Ok(path) } ]]>

Verifying a proof of inclusion This section describes how to verify a compressed Merkle proof. The claim to verify is that "the commitment root defines an n-leaf Merkle tree that contains k digests s[0], ..., s[k-1] at corresponding indices i[0], ..., i[k-1]." The strategy of this verification procedure is to deduce which nodes are needed along the k verification paths from index to root, then read these values from the purported proof, and then recompute the Merkle tree and the consistency of the root digest. As an optimization, the defined[] array avoids recomputing internal portions of the Merkle tree that are not relevant to the verification. By convention, a proof for the degenerate case of k=0 digests is defined to fail. It is assumed that the indices[] array does not contain duplicates. ( n: usize, root: &[u8], leaf_indices: &[usize], path: &[Vec], mut leaf_hash_fn: F, ) -> Result<(), &'static str> where F: FnMut(usize) -> Vec, { let mut seen = vec![false; n]; let mut is_on_path = vec![false; 2 * n]; for &idx in leaf_indices { if idx >= n { return Err("Leaf index out of bounds in Merkle proof verification"); } if seen[idx] { return Err("Duplicate leaf index in Merkle proof verification"); } seen[idx] = true; is_on_path[n + idx] = true; } for i in (1..n).rev() { is_on_path[i] = is_on_path[2 * i] || is_on_path[2 * i + 1]; } let mut layers: Vec>> = vec![None; 2 * n]; for &idx in leaf_indices { layers[n + idx] = Some(leaf_hash_fn(idx)); } let mut path_idx = 0; for i in (1..n).rev() { if is_on_path[i] { let left_val = if is_on_path[2 * i] { layers[2 * i].clone() } else { let val = path.get(path_idx).cloned(); path_idx += 1; val }; let right_val = if is_on_path[2 * i + 1] { layers[2 * i + 1].clone() } else { let val = path.get(path_idx).cloned(); path_idx += 1; val }; if let (Some(left_val), Some(right_val)) = (left_val, right_val) { let mut data = Vec::with_capacity(left_val.len() + right_val.len()); data.extend_from_slice(&left_val); data.extend_from_slice(&right_val); layers[i] = Some(sha256_bytes(&data)); } else { return Err("Missing path value in Merkle proof verification"); } } } if path_idx != path.len() { return Err("Not all Merkle path elements were consumed"); } if let Some(computed_root) = &layers[1] { if computed_root == root { Ok(()) } else { Err("Merkle root mismatch") } } else { Err("Merkle root was not computed") } } ]]>

Common parameters The Prover and Verifier in Ligero must agree on the following parameters. These parameters can be agreed upon out of band.

F: The finite field over which the commit is produced.
NREQ: The number of columns of the commitment matrix that the Verifier requests to be revealed by the Prover.
rate: The inverse rate of the error correcting code. This parameter, along with NREQ and Field size, determines the soundness of the scheme.
BLOCK: the size of each row, in terms of number of field elements
DBLOCK: 2 * BLOCK - 1
WR: the number of witness values included in each row.
IW: Row index at which the witness values start, usually IW = 3.
IQ: Row index at which the quadratic constraints begin, it is the first row after all of the witnesses have been encoded.
NL: Number of linear constraints.
NQ: Number of quadratic constraints.
NWROW: Number of rows used to encode witnesses.
NQT: Number of row triples needed to encode the quadratic constraints.
NQW: NWROW + 3 * NQT, rows needed to encode witnesses and quadratic constraints. Each triple of quadratic constraints occupies three rows (Qx, Qy, Qz).
NROW: Total number of rows in the tableau matrix, 3 + NQW (the three additional rows are the random rows ILDT, IDOT, and IQD).
NCOL: Total number of columns in the tableau matrix.

Constraints on parameters

NCOL < |F| The block size must be smaller than the field size.
NCOL >= DBLOCK + NREQ
BLOCK > NREQ The block size must be larger than the number of columns requested.
BLOCK = NREQ + WR
WR >= NREQ
BLOCK = (NCOL + 1) / (2 + rate)

Ligero commitment The first step of the proof procedure requires the Prover to commit to a witness vector W of length NW. The length NW need not be a multiple of WR; the witness occupies NWROW = ceil(NW / WR) rows, and any unused entries of the last such row are set to zero by the commitment procedure itself. The commitment is the root of a Merkle tree. The leaves of the Merkle tree are a sequence of columns of the tableau matrix T[][]. This tableau matrix is constructed row-by-row by applying the extend procedure to arrays that are formed from random field elements and elements copied from the witness vector. Matrix T[][] has size NROW x NCOL and has the following structure:

The first ILDT row is defined as by selecting BLOCK random field elements and applying extend.
The second IDOT row is defined as by first selecting DBLOCK random field elements such that the subarray [NREQ .. NREQ + WR] sums to 0 and then applying extend. The first step can be performed by selecting DBLOCK-1 random field elements, and then setting Z[NREQ] to be the additive inverse of the sum of the elements with NREQ < i < NREQ + WR.
The third IQD row is defined as ZQ = RANDOM[DBLOCK] ZQ[NREQ .. NREQ + WR] = 0 extend(ZQ, DBLOCK, NCOL) by first selecting DBLOCK random field elements, and then setting the portion coresponding to the witness values to 0 and then applying extend.
The next rows from IW=3,...,IQ are padded witness rows that contain random elements and portions of the witness vector. Specifically, row i is formed by applying extend to an array that consists of NREQ random elements and then WR elements from the vector W: When the finite field contains a subfield, and if all of the witness elements in a given row are elements from this subfield, then the randomness for that row can also be chosen from the subfield. Consequently, the extend method for that row produces polynomial evaluations that are elements of the subfield. When these elements are serialized, they will require less space. The simplest way to apply this optimization is for the commiting process to maintain an index SF such that witnesses at indices 0..SF belong to the subfield, and the rest do not. This value SF can be conveyed to the verifier as part of the proof, or part of the circuit.
The final portion of the witness matrix consists of padded quadratic rows that consists of NREQ random elements and WR quadratic constraint elements: The specific elements in the QX, QY, QZ array are determined by the quadratic constraints on the witness values that are verified by the proof.

The second step of the procedure is to compute a Merkle tree on columns of the tableau matrix. Only the columns DBLOCK..NCOL are committed, so the tree has NCOL - DBLOCK leaves. Specifically, the i-th leaf of the tree is the entire column DBLOCK + i of the tableau T, that is, the NROW elements T[0][DBLOCK + i], ..., T[NROW - 1][DBLOCK + i] serialized in row order, prefixed by that column's nonce and hashed as described in the Merkle trees Section. Input:

The witness vector W.
Array of quadratic constraints lqc[], which consists of triples (x,y,z) that represent the constraint that W[x] * W[y] = W[z].

Output:

A digest; root of a Merkle tree formed from columns of the tableau.

{ pub geometry: LigeroGeometry, pub tableau: Vec>, pub merkle: MerkleHeap, pub nonces: Vec>, } impl LigeroProver { pub fn commit( &self, witness: &[F], lqc: &[LqcTriple], rng: &mut R, subfield_boundary: usize, ) -> LigeroCommitResult { let tableau = self.layout_tableau(witness, lqc, subfield_boundary, rng); let geom = self.geometry; let dblock = geom.dblock_len; let block_enc = geom.encoded_len; let num_committed_cols = block_enc - dblock; let update_leaf_hash = |j: usize| { let col_idx = j + dblock; let mut data = Vec::new(); for row in 0..tableau.len() { data.extend_from_slice(&tableau[row][col_idx].to_bytes()); } data }; let (heap, nonces) = commit_merkle_heap(num_committed_cols, update_leaf_hash, rng); LigeroCommitResult { geometry: geom, tableau, merkle: heap, nonces, } } fn layout_tableau( &self, witness: &[F], lqc: &[LqcTriple], subfield_boundary: usize, rng: &mut R, ) -> Vec> { let mut tableau = Vec::new(); tableau.push(self.layout_ildt_row(rng)); tableau.push(self.layout_idot_row(rng)); tableau.push(self.layout_iquad_row(rng)); tableau.extend(self.layout_witness_rows(witness, subfield_boundary, rng)); tableau.extend(self.layout_quadratic_constraint_rows(witness, lqc, rng)); tableau } fn layout_ildt_row(&self, rng: &mut R) -> Vec { let row = (0..self.geometry.block_len) .map(|_| F::sample(rng)) .collect::>(); self.rs_block.encode_row()(&row) } fn layout_idot_row(&self, rng: &mut R) -> Vec { let geom = self.geometry; let mut row = (0..geom.dblock_len) .map(|_| F::sample(rng)) .collect::>(); let sum_w1 = dot1(&row[geom.num_queries..(geom.num_queries + geom.witnesses_per_row)]); row[geom.num_queries] -= sum_w1; self.rs_dblock.encode_row()(&row) } fn layout_iquad_row(&self, rng: &mut R) -> Vec { let geom = self.geometry; let mut row = (0..geom.dblock_len) .map(|_| F::sample(rng)) .collect::>(); for j in 0..geom.witnesses_per_row { row[geom.num_queries + j] = F::zero(); } self.rs_dblock.encode_row()(&row) } fn layout_witness_rows( &self, witness: &[F], subfield_boundary: usize, rng: &mut R, ) -> Vec> { let geom = self.geometry; let nw = witness.len(); let mut witness_rows = Vec::new(); for i in 0..geom.num_witness_rows { let subfield_only = (i + 1) * geom.witnesses_per_row <= subfield_boundary; let mut row_raw = vec![F::zero(); geom.block_len]; for k in 0..geom.num_queries { row_raw[k] = if subfield_only { self.subfield.sample(rng) } else { F::sample(rng) }; } let start = i * geom.witnesses_per_row; if start < nw { let max_col = std::cmp::min(geom.witnesses_per_row, nw - start); row_raw[geom.num_queries..(geom.num_queries + max_col)] .copy_from_slice(&witness[start..(start + max_col)]); } witness_rows.push(self.rs_block.encode_row()(&row_raw)); } witness_rows } fn layout_quadratic_constraint_rows( &self, witness: &[F], lqc: &[LqcTriple], rng: &mut R, ) -> Vec> { let geom = self.geometry; let nq = lqc.len(); let mut tableau = Vec::new(); let mut x_rows = Vec::new(); let mut y_rows = Vec::new(); let mut z_rows = Vec::new(); for i in 0..geom.num_quad_rows { let mut row_x = self.sample_random_prefix_row(rng); let mut row_y = self.sample_random_prefix_row(rng); let mut row_z = self.sample_random_prefix_row(rng); let start = i * geom.witnesses_per_row; if start < nq { let max_j = std::cmp::min(geom.witnesses_per_row, nq - start); for j in 0..max_j { let c = lqc[start + j]; row_x[geom.num_queries + j] = witness[c.x]; row_y[geom.num_queries + j] = witness[c.y]; row_z[geom.num_queries + j] = witness[c.z]; } } x_rows.push(self.rs_block.encode_row()(&row_x)); y_rows.push(self.rs_block.encode_row()(&row_y)); z_rows.push(self.rs_block.encode_row()(&row_z)); } tableau.extend(x_rows); tableau.extend(y_rows); tableau.extend(z_rows); tableau } } ]]>

Ligero Prove This section specifies how a Ligero proof for a given sequence of linear constraints and quadratic constraints on the committed witness vector W is constructed. The proof consists of a low-degree test on the tableau, a linearity test, and a quadratic constraint test.

Low-degree test In the low-degree test, the verifier sends a challenge vector consisting of NQW field elements, u_ldt[0..NQW]. This challenge is generated via the Fiat-Shamir transform. The prover computes the linear combination: and returns the BLOCK elements of y_ldt. Notice that the random blinding row ILDT (row 0) is included with implicit coefficient 1, while rows 1 (IDOT) and 2 (IQD) are excluded because their polynomial degree is DBLOCK (2 \cdot \text{BLOCK} - 1) rather than BLOCK. The verifier applies the extend method to this response, and verifies consistency with the opened columns of the tableau requested at the challenge indices.

Linear and Quadratic constraints The linear test is represented by a matrix A, and a vector b, and aims to verify that A * W + b = 0. The constraint matrix A is given as input in a sparse form: it is an array of LigeroTerm triples (c,j,k) in which c indicates the constraint index, j represents the witness index, and k represents the linear coefficient. For example, if the first constraint (at index 0) is W[2] + 2*W[3] - 3 = 0, then the linear constraints array contains the terms (0,2,1), (0,3,2) and the b vector has b[0]=-3. The quadratic constraints are given as input in an array lqc[] that contains triples (x,y,z); one such triple represents the constraint that W[x] * W[y] = W[z]. To process quadratic constraints, tableau T is augmented with 3 extra rows per triple, called Qx, Qy, and Qz which hold copied witnesses and their products. If the i-th quadratic constraint is (x,y,z), then the prover sets Qx[i] = W[x], Qy[i] = W[y] and Qz[i] = W[x] * W[y]. Next, the prover adds a linear constraint that Qx[i] - W[x] = 0, Qy[i] - W[y] = 0 and Qz[i] - W[z] = 0 to ensure that the copied witness is consistent. In this sense, the quadratic constraints are reduced to linear constraints, and the additional requirement for the verifier to check that each index of the Qz row is the product of its counterpart in the Qx and Qy row. The prover computes the quadratic test polynomial y_quad across degree DBLOCK. The middle WR witness values of y_quad are identically zero by construction and are omitted from the proof. The proof contains only the non-zero segments: quad_poly_low of length NREQ (elements 0..NREQ) and quad_poly_high of length DBLOCK - BLOCK (elements BLOCK..DBLOCK).

Selection of challenge indicies The last step of the prove method is for the verifier to select a subset of NREQ unique indices (sampled without replacement) from the range 0..(NCOL - DBLOCK) and request that the prover open these columns of tableau T (at column offsets DBLOCK + idx). These opened columns, along with their column blinding nonces and Merkle authentication paths, are then used to verify consistency with the polynomial responses sent by the prover.

Ligero Prover procedure The statement_hash argument is application-dependent and commits to the circuit or statement being proven. LigeroProver { pub fn prove( &self, commit: &LigeroCommitResult, lqc: &[LqcTriple], a: &[LigeroTerm], b: &[F], statement_hash: &[u8], ts: &mut Transcript, ) -> LigeroProof { ts.write_bytes(statement_hash); let geom = self.geometry; let nqw = geom.total_rows - 3; let nq = lqc.len(); let u_ldt = gen_uldt(ts, nqw); let alphal = gen_alphal(ts, b.len()); let alphaq = gen_alphaq(ts, nq); let u_quad = gen_uquad(ts, geom.num_quad_rows); let y_ldt = self.prove_compute_y_ldt(commit, &u_ldt); let a_full = self.prove_compute_a_full(lqc, a, &alphal, &alphaq); let y_dot = self.prove_compute_y_dot(commit, &a_full); let y_quad = self.prove_compute_y_quad(commit, &u_quad); let y_quad_0 = y_quad[0..geom.num_queries].to_vec(); let y_quad_2 = y_quad[geom.block_len..geom.dblock_len].to_vec(); ts.write_elt_field_slice(&y_ldt); ts.write_elt_field_slice(&y_dot); ts.write_elt_field_slice(&y_quad_0); ts.write_elt_field_slice(&y_quad_2); let idx = ts.choose(geom.encoded_len - geom.dblock_len, geom.num_queries); let mut query_nonces = Vec::with_capacity(geom.num_queries); for &col in &idx { query_nonces.push(commit.nonces[col].clone()); } let merkle_paths = open_merkle_heap(&commit.merkle, &idx).expect("Failed to open Merkle heap"); let mut req = Vec::new(); for row in 0..commit.tableau.len() { for &col in &idx { let col_idx = col + geom.dblock_len; req.push(commit.tableau[row][col_idx]); } } LigeroProof { ldt_poly: y_ldt, linear_poly: y_dot, quad_poly_low: y_quad_0, quad_poly_high: y_quad_2, column_nonces: query_nonces, queried_columns: req, merkle_paths, } } fn prove_compute_y_ldt(&self, commit: &LigeroCommitResult, u_ldt: &[F]) -> Vec { let geom = self.geometry; let nqw = geom.total_rows - 3; let mut y_ldt = commit.tableau[geom.ldt_row_idx()][0..geom.block_len].to_vec(); for i in 0..nqw { axpy( &mut y_ldt, &commit.tableau[geom.witness_row_start() + i][0..geom.block_len], u_ldt[i], ); } y_ldt } fn prove_compute_a_full( &self, lqc: &[LqcTriple], a: &[LigeroTerm], alphal: &[F], alphaq: &[Vec], ) -> Vec { let geom = self.geometry; let nqw = geom.total_rows - 3; let nq = lqc.len(); let mut a_full = vec![F::zero(); nqw * geom.witnesses_per_row]; for term in a { a_full[term.witness_idx] += term.coeff * alphal[term.constraint_idx]; } let nqtriples_w = geom.num_quad_rows * geom.witnesses_per_row; let ax_offset = (nqw - 3 * geom.num_quad_rows) * geom.witnesses_per_row; let ay_offset = ax_offset + nqtriples_w; let az_offset = ay_offset + nqtriples_w; for i in 0..geom.num_quad_rows { let mut j = 0; while j < geom.witnesses_per_row && j + i * geom.witnesses_per_row < nq { let idx = j + i * geom.witnesses_per_row; let l = lqc[idx]; a_full[ax_offset + idx] += alphaq[idx][0]; a_full[l.x] -= alphaq[idx][0]; a_full[ay_offset + idx] += alphaq[idx][1]; a_full[l.y] -= alphaq[idx][1]; a_full[az_offset + idx] += alphaq[idx][2]; a_full[l.z] -= alphaq[idx][2]; j += 1; } } a_full } fn prove_compute_y_dot(&self, commit: &LigeroCommitResult, a_full: &[F]) -> Vec { let geom = self.geometry; let nwqrow = geom.total_rows - 3; let mut y_dot = commit.tableau[geom.linear_row_idx()][0..geom.dblock_len].to_vec(); for i in 0..nwqrow { let mut a_ext = vec![F::zero(); geom.block_len]; let start = i * geom.witnesses_per_row; a_ext[geom.num_queries..(geom.num_queries + geom.witnesses_per_row)] .copy_from_slice(&a_full[start..(start + geom.witnesses_per_row)]); let a_evals = self.rs_block.encode_row()(&a_ext); vaxpy( &mut y_dot, &commit.tableau[geom.witness_row_start() + i][0..geom.dblock_len], &a_evals[0..geom.dblock_len], ); } y_dot } fn prove_compute_y_quad(&self, commit: &LigeroCommitResult, u_quad: &[F]) -> Vec { let geom = self.geometry; let mut y_quad = commit.tableau[geom.quad_row_idx()][0..geom.dblock_len].to_vec(); for i in 0..geom.num_quad_rows { let mut tmp = commit.tableau[geom.quad_z_row_start() + i][0..geom.dblock_len].to_vec(); for j in 0..geom.dblock_len { tmp[j] -= commit.tableau[geom.quad_x_row_start() + i][j] * commit.tableau[geom.quad_y_row_start() + i][j]; } axpy(&mut y_quad, &tmp, u_quad[i]); } y_quad } } ]]>

Ligero verification procedure This section specifies how to verify a Ligero proof with respect to a commitment root, statement hash, linear constraints A \cdot W + b = 0, and quadratic constraints lqc[]. The verification procedure checks:

Merkle Proof Consistency (verify_merkle): Verifies the authentication paths for the opened columns against the committed Merkle root.
Low-Degree Test (verify_ldt): Verifies that the linear combination of queried column entries equals the Reed-Solomon encoding of ldt_poly evaluated at the query column indices.
Linear Constraint Test (verify_dot): Verifies that the inner product combination matches linear_poly evaluations at the query columns, and that \sum \text{linear\_poly}[j] + \langle b, \alpha_l \rangle = 0.
Quadratic Constraint Test (verify_quad): Verifies that z[i] - x[i] \cdot y[i] across the quadratic triple rows matches y_quad (reconstructed from quad_poly_low and quad_poly_high) at the query column indices.

LigeroVerifier { pub fn verify( &self, nw: usize, b: &[F], root: &[u8; 32], proof: &LigeroProof, a: &[LigeroTerm], statement_hash: &[u8], lqc: &[LqcTriple], ts: &mut Transcript, ) -> Result<(), VerificationError> { ts.write_bytes(statement_hash); let geom = LigeroGeometry::new(&self.config, nw, lqc.len()); let expected_req_len = geom.total_rows * geom.num_queries; if proof.queried_columns.len() != expected_req_len { return Err(VerificationError::InvalidQueriedColumnsLength { expected: expected_req_len, actual: proof.queried_columns.len(), }); } if proof.ldt_poly.len() != geom.block_len || proof.linear_poly.len() != geom.dblock_len || proof.quad_poly_low.len() != geom.num_queries || proof.quad_poly_high.len() != geom.dblock_len - geom.block_len || proof.column_nonces.len() != geom.num_queries { return Err(VerificationError::InvalidProofPolynomialsLength); } let nwqrow = geom.total_rows - 3; let u_ldt = gen_uldt(ts, nwqrow); let alphal = gen_alphal(ts, b.len()); let alphaq = gen_alphaq(ts, lqc.len()); let u_quad = gen_uquad(ts, geom.num_quad_rows); ts.write_elt_field_slice(&proof.ldt_poly); ts.write_elt_field_slice(&proof.linear_poly); ts.write_elt_field_slice(&proof.quad_poly_low); ts.write_elt_field_slice(&proof.quad_poly_high); let idx = ts.choose(geom.encoded_len - geom.dblock_len, geom.num_queries); self.verify_merkle(&geom, root, proof, &idx)?; self.verify_ldt(&geom, proof, &u_ldt, &idx)?; self.verify_dot(&geom, b, proof, a, lqc, &alphal, &alphaq, &idx)?; self.verify_quad(&geom, proof, &u_quad, &idx)?; Ok(()) } fn verify_merkle( &self, geom: &LigeroGeometry, root: &[u8; 32], proof: &LigeroProof, idx: &[usize], ) -> Result<(), VerificationError> { let leaf_hash_fn = |col: usize| { let mut r_idx = 0; for i in 0..idx.len() { if idx[i] == col { r_idx = i; break; } } let mut data = Vec::new(); data.extend_from_slice(&proof.column_nonces[r_idx]); for row in 0..geom.total_rows { data.extend_from_slice( &proof.queried_columns[row * geom.num_queries + r_idx].to_bytes(), ); } sha256_bytes(&data) }; verify_merkle_proof( geom.encoded_len - geom.dblock_len, root, idx, &proof.merkle_paths, leaf_hash_fn, ) .map_err(|_| VerificationError::MerkleProofInvalid) } fn verify_ldt( &self, geom: &LigeroGeometry, proof: &LigeroProof, u_ldt: &[F], idx: &[usize], ) -> Result<(), VerificationError> { let nwqrow = geom.total_rows - 3; let ildt = geom.ldt_row_idx(); let iw = geom.witness_row_start(); let mut yc_ldt = proof.queried_columns[ildt * geom.num_queries..(ildt + 1) * geom.num_queries].to_vec(); for i in 0..nwqrow { let row_req = &proof.queried_columns [(iw + i) * geom.num_queries..(iw + i + 1) * geom.num_queries]; axpy(&mut yc_ldt, row_req, u_ldt[i]); } let yp_ldt = self.interpolate_req_columns(geom, geom.block_len, &proof.ldt_poly, idx); if yc_ldt == yp_ldt { Ok(()) } else { Err(VerificationError::LowDegreeTestFailed) } } fn verify_dot( &self, geom: &LigeroGeometry, b: &[F], proof: &LigeroProof, a: &[LigeroTerm], lqc: &[LqcTriple], alphal: &[F], alphaq: &[Vec], idx: &[usize], ) -> Result<(), VerificationError> { let nwqrow = geom.total_rows - 3; let idot = geom.linear_row_idx(); let iw = geom.witness_row_start(); let mut a_full = vec![F::zero(); nwqrow * geom.witnesses_per_row]; for term in a { a_full[term.witness_idx] += term.coeff * alphal[term.constraint_idx]; } let nqtriples_w = geom.num_quad_rows * geom.witnesses_per_row; let ax_offset = (nwqrow - 3 * geom.num_quad_rows) * geom.witnesses_per_row; let ay_offset = ax_offset + nqtriples_w; let az_offset = ay_offset + nqtriples_w; for i in 0..geom.num_quad_rows { let mut j = 0; while j < geom.witnesses_per_row && j + i * geom.witnesses_per_row < lqc.len() { let idx_lqc = j + i * geom.witnesses_per_row; let l = lqc[idx_lqc]; a_full[ax_offset + idx_lqc] += alphaq[idx_lqc][0]; a_full[l.x] -= alphaq[idx_lqc][0]; a_full[ay_offset + idx_lqc] += alphaq[idx_lqc][1]; a_full[l.y] -= alphaq[idx_lqc][1]; a_full[az_offset + idx_lqc] += alphaq[idx_lqc][2]; a_full[l.z] -= alphaq[idx_lqc][2]; j += 1; } } let mut yc_dot = proof.queried_columns[idot * geom.num_queries..(idot + 1) * geom.num_queries].to_vec(); let a_interp = ReedSolomonCode::new(geom.block_len, geom.encoded_len, &self.subfield); for i in 0..nwqrow { let mut a_ext = vec![F::zero(); geom.block_len]; let start = i * geom.witnesses_per_row; a_ext[geom.num_queries..geom.block_len] .copy_from_slice(&a_full[start..(start + geom.witnesses_per_row)]); let a_evals = a_interp.encode_row()(&a_ext); let mut a_queried = Vec::with_capacity(geom.num_queries); for &col in idx { a_queried.push(a_evals[geom.dblock_len + col]); } let row_req = &proof.queried_columns [(iw + i) * geom.num_queries..(iw + i + 1) * geom.num_queries]; vaxpy(&mut yc_dot, row_req, &a_queried); } let yp_dot = self.interpolate_req_columns(geom, geom.dblock_len, &proof.linear_poly, idx); if yc_dot != yp_dot { return Err(VerificationError::LinearConstraintFailed); } let want_dot = dot(b, alphal); let proof_dot = dot1(&proof.linear_poly[geom.num_queries..(geom.num_queries + geom.witnesses_per_row)]); if proof_dot + want_dot != F::zero() { return Err(VerificationError::LinearConstraintSumMismatch); } Ok(()) } fn verify_quad( &self, geom: &LigeroGeometry, proof: &LigeroProof, u_quad: &[F], idx: &[usize], ) -> Result<(), VerificationError> { let iquad = geom.quad_row_idx(); let iqx = geom.quad_x_row_start(); let iqy = geom.quad_y_row_start(); let iqz = geom.quad_z_row_start(); let mut yc_quad = proof.queried_columns [iquad * geom.num_queries..(iquad + 1) * geom.num_queries] .to_vec(); for i in 0..geom.num_quad_rows { let u = u_quad[i]; let mut tmp = vec![F::zero(); geom.num_queries]; for j in 0..geom.num_queries { let x_val = proof.queried_columns[(iqx + i) * geom.num_queries + j]; let y_val = proof.queried_columns[(iqy + i) * geom.num_queries + j]; let z_val = proof.queried_columns[(iqz + i) * geom.num_queries + j]; tmp[j] = z_val - x_val * y_val; } axpy(&mut yc_quad, &tmp, u); } let mut y_quad = proof.quad_poly_low.clone(); y_quad.resize(geom.block_len, F::zero()); y_quad.extend_from_slice(&proof.quad_poly_high); let yp_quad = self.interpolate_req_columns(geom, geom.dblock_len, &y_quad, idx); if yc_quad != yp_quad { return Err(VerificationError::QuadraticConstraintFailed); } Ok(()) } } ]]>

Overview of the Longfellow protocol The Longfellow ZK protocol uses two protocol components. The first is a variant of the sumcheck protocol, modified to support zero knowledge. Informally, the standard sumcheck prover takes the description of a circuit and the concrete values of all the wires in the circuit, and produces a proof that all wires have been computed correctly. The proof itself is a sequence of field elements. Longfellow uses an encrypted-variant of the sumcheck prover that also takes as input a random and secret one-time pad and outputs an "encrypted" proof such that each element in this proof is the difference of the element in the standard sumcheck proof and its corresponding element in the pad. (The choice of "difference" instead of "sum" is a matter of convention.) In this encrypted sumcheck variant, the verifier cannot check the proof directly because it cannot access the one-time pad. Instead of running the sumcheck verifier directly, a commitment scheme is used to hide the one-time pad, and the sumcheck verifier is translated into a sequence of linear and quadratic constraints on the inputs and the one-time pad. A secondary proof system is then used to produce a proof with respect to the commitment that the constraints are satisfied. The protocol requires both parties to agree on a circuit as part of the theorem statement. The wire format of a circuit is defined in a separate document. Some of the wires of the circuit are inputs, i.e., set outside the circuit and not computed by the circuit itself. Some of the inputs are public, i.e., known to both parties, and some are private, i.e., known only to the prover. Sumcheck does not use the distinction between public and private inputs. This document distinguishes private inputs from the one-time pad. The commitment scheme does not use public inputs at all, but it does treat private inputs and the one-time pad elements equally. These constraints motivate the following terminology.

public inputs: inputs to the circuit known to both parties.
private inputs: inputs to the circuit known to the prover but not to the verifier.
inputs: both public and private inputs. When forming an array of all inputs, the public inputs come first, followed by the private inputs.
witnesses: the private inputs and the elements in the one-time pad. When forming an array of all witnesses, the private inputs come first, followed by the one-time pad.

Thus, at a high level, the sequence of operations in the ZK protocol is the following:

The prover commits to all witness values.
The prover runs the encrypted sumcheck prover on the witness values to producing an encrypted proof, all-the-while sending the encrypted proof to the verifier.
Both the prover and the verifier take the public inputs and the encrypted proof and produce a sequence of constraints.
Using the commitment scheme and the witnesses, the prover generates a proof that the constraints from step 3 are satisfied.
The verifier uses the proof from step 4 and the constraints from step 3 to check the constraints.

Steps 2 and 3 are referred to as "sumcheck", and the rest as "commitment scheme". While the classification of step 3 as "sumcheck" is arbitrary, there are situations where one might want to use a commitment scheme other than the Ligero protocol specified in this document. In this case, the "commitment scheme" can change while the "sumcheck" remains unaffected.

Parameters needed to define Longfellow Longfellow is parameterized by a sumcheck protocol, a commitment protocol, and a Fiat-Shamir instantiation. A selection of all three defines a Longfellow profile. This document introduces one opinionated profile that uses (a) The longfellow sumcheck described below, (b) the Ligero commitment described above, (c) the Fiat-Shamir instantiation defined above and using SHA-256 as the function H. In addition to the component profile, the following security parameters described in the Ligero Zero-Knowledge Proof Section must also be selected:

NREQ: The number of columns of the commitment matrix in the Ligero commitment scheme that the Verifier requests to be revealed by the Prover.
rate: The inverse rate of the error correcting code used by Ligero.

These two parameters are chosen to balance the size of the proof against the soundness of the protocol. In principle, these parameters can differ based on the Field size. Based on the latest analysis, we support the following profiles which have been analyzed to provide at least 115 bits of security.

(p256, 132, 7)
(GF(2¹²⁸), 132, 7)

Sumcheck

Special conventions for sumcheck arrays The square brackets A[j] denote generic array indexing. For the arrays of field elements used in the sumcheck protocol, however, it is convenient to use the conventions that follow. The sumcheck array A[i] is implicitly assumed to be defined for all nonnegative integers i, padding with zeroes as necessary. Here, "zero" is well defined because A[] is an array of field elements. Arrays can be multi-dimensional, as in the three-dimensional array Q[g, l, r]. It is understood that the array is padded with infinitely many zeroes in each dimension. Depending on the context, some arrays may consist of almost all non-zero values, while other arrays may be sparse, containing very few non-zero values (ignoring the zero-padding convention above). Implementations should use dense or sparse representations of arrays as appropriate. Given array A[] and field element x, the function bind(A, x) returns the array B such that In case of multiple dimensions such as Q[g, l, r], always bind across the first dimension. For example, This bind can be generalized to an array of field elements as follows: Two-dimentional arrays can be transposed in the usual way:

The EQ[] array EQ_{n}[i, j] is a special 2D array defined as The sumcheck literature usually assumes that n is a power of 2, but this document allows n to be an arbitrary integer. When n is clear from context or unimportant, the subscript is omitted like EQ[i, j]. EQ[] is important because the general expansion commutes with binding, yielding That is, one way to compute bindv(V, X) is via dot product of V with bindv(EQ, X). This strategy may or may not be advantageous in practice, but it becomes mandatory when bindv(V, X) must be computed via a commitment scheme that supports linear constraints but not binding. This document only uses bindings of EQ and never EQ itself, and therefore the whole array never needs to be stored explicitly. For n = 2^l and X of size l, bindv(EQ_{n}, X) can be computed recursively in linear time as follows. (challenges: &[F]) -> Vec { let log_n = challenges.len(); if log_n == 0 { return vec![F::one()]; } let n = 1 << log_n; let mut b = vec![F::zero(); n]; let a = bindeq(&challenges[1..]); for i in 0..(n / 2) { b[2 * i] = (F::one() - challenges[0]) * a[i]; b[2 * i + 1] = challenges[0] * a[i]; } b } /// Evaluates the equality polynomial EQ(r, x) at integer point `x_int` of length `nbits`. pub fn eq(r: &[F], x_int: usize, nbits: usize) -> F { let mut product = F::one(); for b in 0..nbits { if ((x_int >> b) & 1) == 1 { product *= r[b]; } else { product *= F::one() - r[b]; } } product } /// Evaluates a linear combination of equality polynomials across two challenge vectors: /// `eq2(x, logn, g0, g1, alpha) = eq(g0, x, logn) + alpha * eq(g1, x, logn)` pub fn eq2(x: usize, logn: usize, g0: &[F], g1: &[F], alpha: F) -> F { eq(g0, x, logn) + alpha * eq(g1, x, logn) } ]]> For m <= n, bindv(EQ_{n}, X)[i] and bindv(EQ_{m}, X)[i] agree for 0 <= i < m, and thus bindv(EQ_{m}, X)[i] can be computed by padding m to the next power of 2 and ignoring the extra elements. With some care, it is possible to compute bindeq() in-place on a single array of arbitrary size m and eliminate the recursion completely.

Remark Let m <= n, A = bindv(EQ_{m}, X) and B = bindv(EQ_{n}, X). It is true that A[i] = B[i] for i < m. However, it is also true that A[i] = 0 for i >= m, whereas B[i] is in general nonzero. Thus, care must be taken when computing a further binding bindv(A, Y), which is in general not the same as bindv(B, Y). A second binding is not needed in this document, but certain closed-form expressions for the binding found in the literature agree with these definitions only when m is a power of 2.

Circuits

Layered circuits A circuit consists of NL layers. By convention, layer j computes wires V[j] given wires V[j + 1], where each V[j] is an array of field elements. A wire is an element V[j][w] for some j and w. Thus, V[0] denotes the output wires of the entire circuit, and V[NL] denotes the input wires. A circuit is intended to check that some property of the input holds, and by convention, the check is considered successful if all output wires are 0, that is, if V[0][w] = 0 for all w.

Quad representation The computation of circuit is defined by a set of quads Q[j], one per layer. Given the output of layer j + 1, the output of of layer j is given by the following equation: The quad Q[j][] is thus a three-dimensional array in the indices g, l, and r where 0 <= g < NW[j] and 0 <= l, r < NW[j + 1]. In practice, Q[j][] is sparse. The specification of the circuit contains an auxiliary vector of quantities LV[j] with the property that V[j][w] = 0 for all w >= 2^{LV[j]}. Informally, LV[j] is the number of bits needed to name a wire at layer j, but LV[j] may be larger than the minimum required value.

In-circuit assertions In the libzk system, a theorem is represented by a circuit such that the theorem is true if and only if all outputs of the circuit are zero. It happens in practice that many output wires are computed early in the circuit (i.e., in a layer closer to the input), but because of layering, they need to be copied all the way to output layer in order to be compared against zero. This copy seems to introduce large overheads in practice. A special convention can mitigate this problem. Abstractly, a layer is represented by two quads Q and Z, and the operation of the layer is described by the two equations Thus, the Z quad asserts that, for given layer j and output wire g, a certain quadratic combination of the input wires is zero. The actual protocol verifies a random linear combination of those two equations, effectively operating on a combined quad QZ = Q + beta * Z for some random beta. To allow for a compact representation of the two quads without losing any real generality, the following conditions are imposed:

The two quads Q and Z are disjoint: for all layers j and output wire g, if any Q[j][g, ., .] are nonzero, then all Z[j][g, ., .] are zero, and vice versa.
Z is binary: Z[j][g, l, r] \in {0, 1}

With these choices, the two quads allow a compact sparse representation as a single list of 4-tuples (g, l, r, v) with the following conventions:

If v = 0, the 4-tuple represents an element of Z, and Z[j][g, l, r] = 1.
If v != 0, the 4-tuple represents an element of Q, and Q[j][g, l, r] = v.
All other elements of Q and Z not specified by the list are zero.

Moreover, this compact representation can be transformed into a representation of QZ = Q + beta * Z by replacing all v = 0 with v = beta.

Representation of polynomials In a generic sumcheck protocol, the prover sends to the verifier polynomials of a degree specified in advance. In the present document, the polynomials are always of degree two, and are represented by their evaluations at three points P0 = 0, P1 = 1, and P2, where 0 and 1 are the additive and multiplicative identities in the field. The choice of P2 depends upon the field. For fields of characteristic greater than 2, set P2 = 2 (= 1 + 1 in the field). For GF(2^128) expressed as GF(2)[X] / (X^128 + X^7 + X^2 + X + 1), set P2 = inj(2) as defined in . This document does not prescribe a choice of P2 for binary fields other than GF(2^128). At the start of each round of communication in a sumcheck protocol, both the prover and the (virtual) sumcheck verifier agree on a claim value, which represents the sum of the evaluation of some function at all inputs {0,1}^*. The polynomials computed by the prover represent the sum of the evaluations of the multilinear extension of that same function, with one argument fixed to P0, P1, or P2, and all other arguments chosen from {0,1}. Therefore, the sum of p(P0) + p(P1) is equal to the claim from the start of the sumcheck round, and the prover only needs to send two field elements in order for the parties to agree on the entire degree two polynomial. Here, p(P0) and p(P2) are sent to the (virtual) sumcheck verifier, and p(P1) is reconstructed from p(P0) and the claim.

Transcript encryption and deferred verification The sumcheck protocol produces a series of polynomials and claim values, computed from the circuit input values, to prove that the circuit was evaluated correctly. As described in , these polynomials and claims are not directly revealed to the verifier. Rather, the field elements that make up these values are encrypted with a one-time pad by subtracting a randomly chosen pad value from each field element, and the difference is sent to the verifier. When the verifier executes the sumcheck protocol, it does not have direct access to all the circuit inputs, and it is only given the one-time pad encrypted forms of the sumcheck polynomials and per-layer claims, not the corresponding plaintext values. Therefore, the prover and verifier defer part of the verification by producing a series of linear and quadratic constraints, relating the private input values and the one-time pad values, so that those constraints can be checked with the Ligero zero-knowledge system (see ). The variables used in these constraints are assigned sequentially, first to the private circuit inputs, then to elements of the one-time pad. Variables for one-time pad values are assigned to values for circuit layers in order, starting with the output layer (layer 0). Within each layer, variables are first assigned to one-time pad values for sumcheck polynomials, then to the per-layer claim values. The number of sumcheck polynomials for each layer is equal to double the value of logw for that layer of the circuit (two hands for each round). The polynomials are represented by two field elements each, one for the evaluation at P0 = 0, and one for the evaluation at P2. At the end of the variables for each layer, three variables are assigned for claim-related values. Two variables c0 and c1 are used for the one-time pad values for the claims vl and vr. Then, a variable cr is used for the product of those two one-time pad values (cr = c0 * c1). { pub hp: [[T; 2]; 2], // hp[hand] = [p0_mask, p2_mask] } /// Padding for final layer claim masks. #[derive(Clone, Debug, PartialEq, Eq)] pub struct LayerClaimsPad { pub c0: T, pub c1: T, pub cr: T, // Product c0 * c1 } /// Padding for a single circuit layer. #[derive(Clone, Debug, PartialEq, Eq)] pub struct LayerPad { pub rounds: Vec>, pub claims: LayerClaimsPad, } /// Padding for the entire circuit. #[derive(Clone, Debug, PartialEq, Eq)] pub struct CircuitPad { pub layers: Vec>, } impl LayerPad { /// Samples concrete random field element masks for a single circuit layer. pub fn sample(logw: usize, rng: &mut R) -> Self { let mut rounds = Vec::with_capacity(logw); for _ in 0..logw { rounds.push(RoundPad { hp: [ [F::sample(rng), F::sample(rng)], [F::sample(rng), F::sample(rng)], ], }); } let c0 = F::sample(rng); let c1 = F::sample(rng); let cr = c0 * c1; LayerPad { rounds, claims: LayerClaimsPad { c0, c1, cr }, } } /// Appends all pad elements in order to a witness vector. pub fn flatten_into(&self, out: &mut Vec) { for r in &self.rounds { out.extend_from_slice(&r.hp[0]); out.extend_from_slice(&r.hp[1]); } out.push(self.claims.c0); out.push(self.claims.c1); out.push(self.claims.cr); } } impl LayerPad { /// Generates the symbolic witness indices for a single circuit layer pad starting at `pad_base`. pub fn generate_indices(logw: usize, pad_base: &mut usize) -> Self { let mut rounds = Vec::with_capacity(logw); for _ in 0..logw { let hand0 = [*pad_base, *pad_base + 1]; let hand1 = [*pad_base + 2, *pad_base + 3]; *pad_base += 4; rounds.push(RoundPad { hp: [hand0, hand1] }); } let c0 = *pad_base; let c1 = *pad_base + 1; let cr = *pad_base + 2; *pad_base += 3; LayerPad { rounds, claims: LayerClaimsPad { c0, c1, cr }, } } } impl CircuitPad { /// Samples random field element padding for all layers in the circuit and flattens them into witness padding. pub fn sample(circuit_data: &Circuit, rng: &mut R) -> (Self, Vec) { let mut pad_witness = Vec::new(); let mut layers = Vec::with_capacity(circuit_data.layers.len()); for layer in &circuit_data.layers { let layer_pad = LayerPad::sample(layer.logw, rng); layer_pad.flatten_into(&mut pad_witness); layers.push(layer_pad); } (CircuitPad { layers }, pad_witness) } } impl CircuitPad { /// Generates symbolic witness indices for all layers in the circuit starting at `pad_base`. pub fn generate_indices(circuit_data: &Circuit, pad_base: &mut usize) -> Self { let mut layers = Vec::with_capacity(circuit_data.layers.len()); for layer in &circuit_data.layers { layers.push(LayerPad::generate_indices(layer.logw, pad_base)); } CircuitPad { layers } } } ]]>

Transform circuit and wires into a padded proof The prover constructs a padded proof by executing the sumcheck protocol in order to certify that the wires at each layer of the circuit are correctly calculated from the wires at the preceding layer. The goal is to prove that, for some layer index j, and every output wire index g in that layer, the following all hold with high probability. These equations are combined into one equation after multiplying them by random verifier challenges. This equation is of the form If we reinterpret the wire indices l and r as binary numbers, replacing them both with log_num_input_wires many variables having value 0 or 1, then this equation has the form needed to apply the sumcheck protocol. At each layer, both parties start with two claims that each represent a linear combination of the layer's output wire values. Concretely, the claims for the layer's outputs are bind(V[j], G[0]) and bind(V[j], G[1]) where G[0] and G[1] are arrays of verifier challenges. These two claim values get combined into one using a random challenge value. In each successive round of communication, the function inside the summation is replaced with a new function having one fewer parameter, one of the output wire arrays is halved in size by binding it with a random challenge, and the claim value is replaced with a newly computed claim value. The prover proves that the new claim values and the new function at each round are consistent with those in the previous round by evaluating the multilinear extension of the function at multiple points, including points with a random challenge coordinate. The prover computes a degree two polynomial by summing this multilinear extension at many points, with the polynomial's parameter determining the last parameter of the multilinear extension. Two evaluations of this polynomial are sent to the verifier, though as noted above these evaluations get encrypted with a one-time pad. After several rounds of communication, the function being summed is replaced with a constant, and both output wire arrays are replaced with two new claim values. Concretely, the new claims will be bind(V[j + 1], G'[0]) and bind(V[j + 1], G'[1]), where V[j + 1] is the input wires of layer j, and G'[0] and G'[1] are a fresh set of verifier challenges, chosen at each round of the sumcheck protocol. These two claim values are encrypted with a one-time pad and sent to the verifier. Before the first round, a fixed number of verifier challenges are generated and discarded (begin_circuit). These are reserved for possible future extensions to the protocol. Additionally, a fixed number of challenges are generated for binding the output wires before the first round, with the remainder of the challenges being discarded. In both of these cases, MAX_LOGW = 40 challenges are generated. For all subsequent layers, challenges used for binding output wires are generated one at a time, with no extra unused challenges. { pub evals: [F; 2], } #[derive(Clone, Debug)] pub struct SumcheckLayerProof { pub hp: [Vec>; 2], pub claims: [F; 2], } /// Returns the element at `index`, treating the slice as infinitely padded with zeroes. pub fn vector_ref(w: &[F], index: usize) -> F { if index < w.len() { w[index] } else { F::zero() } } /// Evaluates a single round polynomial for the sumcheck protocol. /// Returns evaluations at 0, 1, and x2. fn eval_round_poly( quad_terms: &[Term], active_hand: &[F], other_hand: &[F], hand: usize, eval_point_x2: F, ) -> [F; 3] { let one_minus_x2 = F::one() - eval_point_x2; let mut ev0 = F::zero(); let mut ev1 = F::zero(); let mut ev2 = F::zero(); let other_hand_idx = 1 - hand; for term in quad_terms { let is_even = term.h[hand] % 2 == 0; let pair_base_idx = term.h[hand] & !1; let w0 = vector_ref(active_hand, pair_base_idx); let w1 = vector_ref(active_hand, pair_base_idx | 1); let other_val = vector_ref(other_hand, term.h[other_hand_idx]); let coef = term.k * other_val; let wx2 = w0 + eval_point_x2 * (w1 - w0); if is_even { ev0 += coef * w0; ev2 += coef * one_minus_x2 * wx2; } else { ev1 += coef * w1; ev2 += coef * eval_point_x2 * wx2; } } [ev0, ev1, ev2] } /// Binds active wires to a challenge point: /// wires[i] = (1 - challenge) * wires[2*i] + challenge * wires[2*i + 1] pub fn bind(wires: &mut Vec, challenge: F) { let n = wires.len().div_ceil(2); let one_minus_c = F::one() - challenge; for i in 0..n { let w0 = vector_ref(wires, 2 * i); let w1 = vector_ref(wires, 2 * i + 1); wires[i] = w0 * one_minus_c + w1 * challenge; } wires.truncate(n); } pub fn sumcheck_prove_layer( transcript: &mut Transcript, layer_pad: &LayerPad, wires: &[F], mut quad_terms: Vec>, logw: usize, ) -> (SumcheckLayerProof, [Vec; 2], [F; 2]) { let mut challenges = [Vec::new(), Vec::new()]; let mut hp = [Vec::with_capacity(logw), Vec::with_capacity(logw)]; let x2 = F::sumcheck_eval_points()[2]; let mut active_wires = [wires.to_vec(), wires.to_vec()]; for round in 0..logw { for hand in 0..2 { let other_hand = 1 - hand; let evaluations = eval_round_poly( &quad_terms, &active_wires[hand], &active_wires[other_hand], hand, x2, ); // Pad the polynomial evaluations let round_pad = &layer_pad.rounds[round].hp[hand]; let padded_sumcheck_poly = [evaluations[0] - round_pad[0], evaluations[2] - round_pad[1]]; // Get challenge from transcript let challenge = round_poly(transcript, &padded_sumcheck_poly); challenges[hand].push(challenge); hp[hand].push(SumcheckRoundEvals { evals: padded_sumcheck_poly, }); // Fold the active wires with the challenge bind(&mut active_wires[hand], challenge); // Update quadratic terms for the next round let one_minus_c = F::one() - challenge; for term in quad_terms.iter_mut() { if term.h[hand] % 2 == 0 { term.k *= one_minus_c; } else { term.k *= challenge; } term.h[hand] /= 2; } } } let next_claims = [ vector_ref(&active_wires[0], 0), vector_ref(&active_wires[1], 0), ]; let proof_claims = [ next_claims[0] - layer_pad.claims.c0, next_claims[1] - layer_pad.claims.c1, ]; end_layer(transcript, &proof_claims); let proof = SumcheckLayerProof { hp, claims: proof_claims, }; (proof, challenges, next_claims) } pub fn sumcheck_prove( transcript: &mut Transcript, in_layers: &[Vec], circuit_data: &Circuit, circuit_pad: &CircuitPad, ) -> (Vec>, [F; 2]) { let (_copy_challenges, global_challenges) = begin_circuit::(transcript); let initial_logv = ceil_lg2(circuit_data.noutput); let mut current_logv = initial_logv; let mut current_challenges = [ global_challenges[0..initial_logv].to_vec(), global_challenges[0..initial_logv].to_vec(), ]; let mut final_claims = [F::zero(); 2]; let mut proofs = Vec::with_capacity(circuit_data.layers.len()); for layer_index in 0..circuit_data.layers.len() { let layer = &circuit_data.layers[layer_index]; let (alpha, beta) = begin_layer(transcript); let mut quad_terms = layer.quad.clone(); bind_g( &mut quad_terms, current_logv, ¤t_challenges[0], ¤t_challenges[1], alpha, beta, ); let (proof, next_challenges, next_claims) = sumcheck_prove_layer( transcript, &circuit_pad.layers[layer_index], &in_layers[layer_index], quad_terms, layer.logw, ); current_logv = layer.logw; current_challenges = next_challenges; final_claims = next_claims; proofs.push(proof); } (proofs, final_claims) } ]]>

Generate constraints from the public inputs and the padded proof This section defines the procedure symbolic_sumcheck_verifier_core for transforming the proof returned by sumcheck_prove into constraints to be checked by the commitment scheme. Specifically, each layer produces one linear constraint and one quadratic constraint. One additional linear constraint is added after processing the input layer. The main difficulty in describing the algorithm is that it operates not on concrete witnesses, but on expressions in which the witnesses are symbolic quantities. Symbolic manipulation is necessary because the verifier does not have access to the witnesses. In the reference implementation, symbolic quantities are represented by affine expressions Expression<F> of the form k + SUM_{i} a[i] * Var(i) for known constant k and coefficients a[i]. Var(i) represents the i-th variable in the combined witness vector W. Linear constraints are converted into sparse constraint terms LigeroTerm<F> representing A * W + b = 0, and quadratic constraints are represented by variable indices (c0, c1, cr) enforcing W[c0] * W[c1] = W[cr]. { pub logv: usize, pub claim: [Expression; 2], pub hc: [Vec; 2], } pub struct SymRes { pub a: Vec>, pub b: Vec, } fn constrain_to_be_zero( a: &mut Vec>, b: &mut Vec, expr: &Expression, ) { let c = b.len(); for (&witness_idx, &coeff) in &expr.terms { a.push(LigeroTerm { coeff, constraint_idx: c, witness_idx, }); } b.push(expr.known); } pub fn symbolic_sumcheck_round( claim: Expression, round_pad: &[usize; 2], hp_evals: &[F; 2], ts: &mut Transcript, ) -> (Expression, F) { let challenge_val = round_poly(ts, hp_evals); let lag = lagrange_basis(challenge_val); let p0 = Var(round_pad[0]) + hp_evals[0]; let p2 = Var(round_pad[1]) + hp_evals[1]; let p1 = claim - p0.clone(); let next_claim = p0 * lag[0] + p1 * lag[1] + p2 * lag[2]; (next_claim, challenge_val) } fn verify_layer( a: &mut Vec>, b: &mut Vec, claims_state: &mut ClaimsState, pad: &LayerPad, clr: &CircuitLayer, plr: &SumcheckLayerProof, ts: &mut Transcript, ) { let (alpha, beta) = begin_layer(ts); let mut lchal_hc = [Vec::new(), Vec::new()]; let mut claim = claims_state.claim[0].clone() + claims_state.claim[1].clone() * alpha; for round in 0..clr.logw { for hand in 0..2 { let hp = &plr.hp[hand][round]; let round_pad = &pad.rounds[round].hp[hand]; let (next_claim, challenge_val) = symbolic_sumcheck_round(claim, round_pad, &hp.evals, ts); claim = next_claim; lchal_hc[hand].push(challenge_val); } } let eqq = eval_bound_quad( &clr.quad, claims_state.logv, &claims_state.hc[0], &claims_state.hc[1], &lchal_hc[0], &lchal_hc[1], clr.logw, alpha, beta, ); let prod_expr = (Var(pad.claims.c0) * plr.claims[1] + Var(pad.claims.c1) * plr.claims[0] + Var(pad.claims.cr) + (plr.claims[0] * plr.claims[1])) * eqq; claim -= prod_expr; constrain_to_be_zero(a, b, &claim); end_layer(ts, &plr.claims); *claims_state = ClaimsState { logv: clr.logw, claim: [ Var(pad.claims.c0) + plr.claims[0], Var(pad.claims.c1) + plr.claims[1], ], hc: lchal_hc, }; } fn input_constraint( a: &mut Vec>, b: &mut Vec, num_public_inputs: usize, num_inputs: usize, pub_inputs: &[F], claims_logv: usize, claims_hc0: &[F], claims_hc1: &[F], got_expr: Expression, alpha: F, ) { let mut eq_vec = Vec::with_capacity(num_inputs); for i in 0..num_inputs { eq_vec.push(eq2(i, claims_logv, claims_hc0, claims_hc1, alpha)); } let mut pub_binding = F::zero(); for i in 0..num_public_inputs { pub_binding += eq_vec[i] * pub_inputs[i]; } let mut mle_expr = Expression::from(pub_binding); for w in 0..(num_inputs - num_public_inputs) { mle_expr += Var(w) * eq_vec[num_public_inputs + w]; } mle_expr -= got_expr; constrain_to_be_zero(a, b, &mle_expr); } pub fn symbolic_sumcheck_verifier_core( mut pad_index: usize, pub_inputs: &[F], circuit_data: &Circuit, proof: &[SumcheckLayerProof], ts: &mut Transcript, ) -> SymRes { let mut a = Vec::new(); let mut b = Vec::new(); let num_inputs = circuit_data.ninput; let num_public_inputs = circuit_data.npublic_input; let logv_output = ceil_lg2(circuit_data.noutput); let (_, g_ch) = begin_circuit::(ts); let hc_init = g_ch[0..logv_output].to_vec(); let mut claims_state = ClaimsState { logv: logv_output, claim: [Expression::zero(), Expression::zero()], hc: [hc_init.clone(), hc_init], }; let circuit_pad = CircuitPad::generate_indices(circuit_data, &mut pad_index); for ly in 0..circuit_data.layers.len() { verify_layer( &mut a, &mut b, &mut claims_state, &circuit_pad.layers[ly], &circuit_data.layers[ly], &proof[ly], ts, ); } let alpha_input = ts.get_elt_field(); let got_expr = claims_state.claim[0].clone() + claims_state.claim[1].clone() * alpha_input; input_constraint( &mut a, &mut b, num_public_inputs, num_inputs, pub_inputs, claims_state.logv, &claims_state.hc[0], &claims_state.hc[1], got_expr, alpha_input, ); SymRes { a, b } } ]]>

Serializing objects This section explains how a proof consists of smaller, related objects, and how to serialize each such component. As in the preceding sections, the procedures are given as excerpts from the reference implementation. A size, meaning either the length of an array or an index into one, is serialized as exactly four bytes in little endian order: (writer: &mut W, val: usize) -> std::io::Result<()> { writer.write_all(&(val as u32).to_le_bytes()) } /// Reads a size written by `write_size_4bytes`. pub fn read_size_4bytes(reader: &mut R) -> std::io::Result { let mut buf = [0u8; 4]; reader.read_exact(&mut buf)?; let val = u32::from_le_bytes(buf); Ok(val as usize) } ]]> Almost every array in a proof has a length that both parties compute from the circuit and from the agreed parameters, and such an array is serialized as its elements in order, with no length prefix. The two exceptions are the runs of the opened columns and the Merkle path; both are preceded by a size, and both are described below. A digest is serialized as the HASH_LEN bytes produced by the hash function H of the chosen profile; for SHA-256, HASH_LEN is 32. The Merkle column blinding nonces are also HASH_LEN bytes each.

Serializing structs When a section includes just a struct definition, it is serialized in the natural way, starting from the top-most component and proceeding to the last one, each component is serialized in order.

Serializing Field elements This section describes a method to serialize field elements, particularly when the field structure allows efficient encoding for elements of subfields. Before a field element can be serialized, the context must specify the finite field. In most cases, the Circuit structure will specify the finite field, and all other aspects of the protocol will be defined by this field. A finite field or FieldID is specified using a variable-length encoding. Common finite fields have been assigned special 1-byte codes. An arbitrary prime-order finite field can be specified using the special 0xF_ byte followed by a variable number of bytes to specify the prime in little-endian order. For example, the 3 byte sequence f10101 specifies F₂₅₇. Similarly, a quadratic extension using the polynomial x^2 + 1 can be specified using the 0xE_ designators. Finite field identifiers.

Finite field	FieldID
p256	0x01
p384	0x02
p521	0x03
GF(2¹²⁸)	0x04
GF(2¹⁶)	0x05
2¹²⁸ - 2¹⁰⁸ + 1	0x06
2^64 - 59	0x07
2^64 - 2^32 + 1	0x08
F_{2^64 - 59}²	0x09
secp256k1	0x0a
F_{2^{0--15}-byte prime}²	0xe{0--f}
F_{2^{0--15}-byte prime}	0xf{0--f}

The GF(2¹²⁸) field uses the irreducible polynomial x¹²⁸ + x⁷ + x² + x + 1. The p256 prime is equal to 115792089210356248762697446949407573530086143415290314195533631308867097853951, which is the base field used by the NIST P256 elliptic curve. The p384 prime is equal to 39402006196394479212279040100143613805079739270465446667948293404245721771496870329047266088258938001861606973112319 which is the base field used by the NIST P384 curve. The p512 prime is equal to 2⁵²¹ - 1. The F_p64^2 field is the quadratic field extension of the base field defined by prime 18446744073709551557 using polynomial x^2 + 1, i.e. by injecting a square root of -1 to the field.

Serializing a single field element Unless specified otherwise, a field element, referred to as an Elt, is serialized to bytes in little-endian order. For example, a 256-bit element of the finite field F_p256 is serialized into 32-bytes starting with the least-significant byte. An element of field F is written as F::to_bytes(), which always produces F::serialized_size() bytes, and is read back as follows: (reader: &mut R) -> std::io::Result { let mut buf = vec![0u8; F::serialized_size()]; reader.read_exact(&mut buf)?; F::from_bytes(&buf) .map_err(|e| std::io::Error::new(std::io::ErrorKind::InvalidData, e.to_string())) } ]]>

Serializing an element of a subfield In some cases, when both Prover and Verifier can explicitly conclude that a field element belongs to a smaller subfield, then both parties can use a more efficient sub-field serialization method. This optimization can be used when the larger field F is a field extension of a smaller field, and both parties can conclude that the serialized element belongs to the smaller subfield. Such an element is written as sf.to_subfield_bytes(), which produces sf.subfield_serialized_size() bytes, and is read back as follows: ( reader: &mut R, sf: &F::Subfield, ) -> std::io::Result { let size = sf.subfield_serialized_size(); let mut buf = vec![0u8; size]; reader.read_exact(&mut buf)?; sf.from_subfield_bytes(&buf) .map_err(|e| std::io::Error::new(std::io::ErrorKind::InvalidData, e.to_string())) } ]]>

Serializing a Sumcheck Transcript The padded sumcheck transcript is the array of SumcheckLayerProof values produced by sumcheck_prove, one per circuit layer, written in layer order: ( io: &mut W, sumcheck_proof: &[SumcheckLayerProof], ) -> std::io::Result<()> { for ly in sumcheck_proof { for r in 0..ly.hp[0].len() { io.write_all(&ly.hp[0][r].evals[0].to_bytes())?; io.write_all(&ly.hp[1][r].evals[0].to_bytes())?; io.write_all(&ly.hp[0][r].evals[1].to_bytes())?; io.write_all(&ly.hp[1][r].evals[1].to_bytes())?; } io.write_all(&ly.claims[0].to_bytes())?; io.write_all(&ly.claims[1].to_bytes())?; } Ok(()) } ]]> Thus each layer contributes 4 * log_w field elements followed by the two padded claims, for a total of 4 * log_w + 2 elements. Within a round, the four elements are the evaluations of the left and right polynomials at the two points P0 and P2, in the order l(P0), r(P0), l(P2), r(P2). The padded transcript incorporates the optimization in which the eval at 1 is omitted and reconstructed from the expected value of the previous challenge. Nothing in this structure is length-prefixed: the number of layers and the value of log_w for each layer are given by the circuit, which is why the corresponding reader, read_sumcheck_proof, takes the circuit as an argument.

Serializing a Ligero Proof A Ligero proof consists of the three response polynomials, the Merkle column blinding nonces, the opened columns, and the Merkle authentication path: ( io: &mut W, cp: &LigeroProof, sf: &F::Subfield, ) -> std::io::Result<()> { for val in &cp.ldt_poly { io.write_all(&val.to_bytes())?; } for val in &cp.linear_poly { io.write_all(&val.to_bytes())?; } for val in &cp.quad_poly_low { io.write_all(&val.to_bytes())?; } for val in &cp.quad_poly_high { io.write_all(&val.to_bytes())?; } for nonce in &cp.column_nonces { io.write_all(nonce)?; } let req = &cp.queried_columns; let mut subfield_run = false; let mut i = 0; let total_elts = req.len(); while i < total_elts { let mut runlen = 0; while i + runlen < total_elts { if sf.contains_subfield(req[i + runlen]) == subfield_run { runlen += 1; } else { break; } } write_size_4bytes(io, runlen)?; for j in i..(i + runlen) { if subfield_run { io.write_all(&sf.to_subfield_bytes(req[j]))?; } else { io.write_all(&req[j].to_bytes())?; } } i += runlen; subfield_run = !subfield_run; } write_size_4bytes(io, cp.merkle_paths.len())?; for p in &cp.merkle_paths { io.write_all(p)?; } Ok(()) } ]]> The lengths of the four polynomial arrays are BLOCK, DBLOCK, NREQ, and DBLOCK - BLOCK respectively, and so none of them is length-prefixed. The last two are the non-zero segments of the quadratic test polynomial; its middle WR elements are identically zero and are not sent. The column_nonces array holds the NREQ Merkle column blinding nonces, one per opened column, each of HASH_LEN bytes. The opened columns queried_columns are the NREQ * NROW field elements of the opened columns, in row-major order. The concept of a run allows saving space when a long run of field elements belong to a subfield of the Finite field. Runs consist of a 4-byte size element, and then that many Elt elements that are either in the field or the subfield. Runs alternate, beginning with full field elements. In this way, rows that consist of subfield elements can save space. The maximum run length is set to 2²⁵. Because the runs strictly alternate and the first run is a full-field run, the encoder has no way to signal that the opened columns begin with a subfield element other than by emitting a full-field run of length zero. A zero-length run is therefore permitted, but only as the very first run of the sequence and only once; anywhere else it would be either redundant, since two adjacent runs of the same kind can always be merged, or an attempt to encode the same byte string in more than one way. A reader MUST reject a zero-length run that is not the first run, and MUST reject a second consecutive zero-length run. Both cases occur in practice: the P-256 test vector in begins with a zero-length run because its first opened element lies in the subfield, whereas the GF(2¹²⁸) vector begins directly with a full-field run of all NREQ * NROW elements. Finally, the Merkle authentication path is the one part of a proof whose length is not determined in advance, since it depends on which columns were opened; it is therefore preceded by a size. Each element of the path is a digest of HASH_LEN bytes.

Serializing a Sequence of proofs In general, a proof string carries a sequence of N proofs, for N >= 1: The proofs are concatenated with no separators and no count, because the circuit identifier names the ordered list of circuits that together make up the statement, and thus fixes both the number of proofs N and the circuit that each proofs[i] belongs to. The ordered list of circuits makes a proof self-delimiting: it supplies the field, the number of layers, the value of log_w for each layer, and the Ligero geometry, which determine every length in the two preceding sections. A reader parses the proofs in order, using the i-th circuit to parse proofs[i]. Because each circuit carries its own FieldID, successive proofs in one string are in general over different fields, and their field elements differ in width; a reader MUST establish the field context afresh at each proof boundary rather than assume a single element size for the whole string. A reader MUST reject a proof string that ends before all N proofs have been parsed. If Proofs constitutes the entire message, then a reader MUST reject any trailing bytes. The arguments in pub are the public inputs to all N circuits and are not repeated per proof. Proving one statement with several circuits normally also requires data that binds the proofs to each other, so that the verifier learns that the circuits were evaluated on consistent inputs. Such linking data is specific to the application and is outside the scope of this document. A single proof is the commitment to the witness, followed by the padded sumcheck transcript, followed by the Ligero proof: { pub root: [u8; 32], pub sumcheck_proof: Vec>, pub ligero_proof: LigeroProof, } pub fn write_zk_proof( io: &mut W, proof: &ZkProof, sf: &F::Subfield, ) -> std::io::Result<()> { io.write_all(&proof.root)?; write_sumcheck_proof(io, &proof.sumcheck_proof)?; write_ligero_proof(io, &proof.ligero_proof, sf)?; Ok(()) } ]]> Here root is the root of the Merkle tree described in , and is HASH_LEN bytes long. The public arguments to the circuits are carried alongside the proofs rather than inside them:

Security Considerations Both the Ligero and Longfellow systems satisfy the standard properties of a zero-knowledge argument system: completeness, soundness, and zero-knowledge. Frigo and shelat provide an analysis of the soundness of the system, as it derives from the Soundness of the Ligero proof system and the sumcheck protocol. Similarly, the zero-knowledge property derives almost entirely from the analysis of Ligero . A mechanically verifiable proof for the soundness and zero-knowledge properties of the joint scheme is in preparation.

IANA Considerations This document does not make any requests of IANA.

References Normative References Informative References THE KNOWLEDGE COMPLEXITY OF INTERACTIVE PROOF SYSTEMS Novel polynomial basis and its application to Reed-Solomon erasure codes How to Prove False Statements: Practical Attacks on Fiat-Shamir Ligero: Lightweight Sublinear Arguments Without a Trusted Setup Anonymous credentials from ECDSA Fiat-Shamir From Simpler Assumptions

Acknowledgements

Test Vectors This section contains test vectors. Each test vector in specifies the configuration information and inputs. All values are encoded in hexadecimal strings.

Test Vectors for Merkle Tree These vectors exercise the tree construction and the batch inclusion proof only. The leaves below are the leaf digests themselves, so no nonces are involved; the nonce-blinded leaf construction used by the Ligero commitment is exercised by the vectors in , which list their nonces explicitly.

Vector 1

Leaves: 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a dbc1b4c900ffe48d575b5da5c638040125f65db0fe3e24494b76ea986457d986 084fed08b978af4d7d196a7446a86b58009e636b611db16211b65a9aadff29c5 e52d9c508c502347344d8c07ad91cbd6068afc75ff6292f062a09ca381c89e71 e77b9a9ae9e30b0dbdb6f510a264ef9de781501d7b6b92ae89eb059c5ab743db
Root: f22f4501ffd3bdffcecc9e4cd6828a4479aeedd6aa484eb7c1f808ccf71c6e76
Proof for leaves (0,1): 084fed08b978af4d7d196a7446a86b58009e636b611db16211b65a9aadff29c5 f03808f5b8088c61286d505e8e93aa378991d9889ae2d874433ca06acabcd493
Proof for leaves (1,3): e77b9a9ae9e30b0dbdb6f510a264ef9de781501d7b6b92ae89eb059c5ab743db 084fed08b978af4d7d196a7446a86b58009e636b611db16211b65a9aadff29c5 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a

Test Vectors for Fiat-Shamir Let p=115792089237316195423570985008687907853269984665640564039457584007908834671663 and Fp be the 4-word field defined by p.

Vector 1: WriteBytes

Description: Using Fp, the test steps are to (a) initialize the transcript object with the 4-byte string test; (b) write an array of bytes of size 100 that contains the integers 0, 1, 2, ..., 99; (c) generate 16 field elements:
- 0x8b297f0bffd583c6c6b6796385d5fd20a08665733b833970ebdd1054bbbc1b14
- 0x0667c08ad7f38efec5f30dc8aa4f20d749cdcf96d63a770f9810ac5c0ca8dcb1
- 0xc8037fc12d4da00b5dc7597e3042f33f72a06f970cb71fb6b103ebb5419d8a6b
- 0xfbbcfa1eac48728fbfdacc1c21e2f78119457e0846337e46140e38e62856c4c5
- 0x5358ae603691cc759faeb572fb6642654ea1c3dbc8f81d00276dd8c4df95aa58
- 0x5266158c3c895dede5a23b6ce85a9f564b8059ebfcd1741f54497ec58189873e
- 0x3ecea4b2343c007fc32f2aff40dc7320945f101ecae5d52494db21ad326e9739
- 0x6462dd575e6b874118607212feec7ce5417ae3bf0f2e86604596f35d48bbaea2
- 0x6d56c703c369edea3595db6b958241580ae9b4a76fead961413ed9e9e5852dcd
- 0x6d31073cee650212a71b7b13e9f951e00ef3b14a008a79dd95047b26a4a83d06
- 0x1b9e2a6666da63c43e52227d91a8a7f0bd5311f63c2e3a18839133375639e6cb
- 0x332ea49dd23dd4745631ecbb15696192b1fa127256baf7a0483fd27db6f09a48
- 0x43e735927ccbdc4d5ce912675d638d6d3dc8eef3def34504304e938846f157d6
- 0xdc4a8868ae75e733a7257a8589230392a98d78594836dfccd01304742b5b3ad5
- 0x976353931711c634f2691e507b119fd7f6e653d419a2620676122db08db18765
- 0x332729ab436dca654866a9382deaee0add6fb7e90a80261f1488e56598e8bc99

Vector 2: WriteFieldElement

Starting from the state at the end of Vector 1, (a) write the field element '7' in Fp; (b) generate 16 field elements
- 0x609db3e9a8f548df038519fa46cef23eb8c6553d3c1f698604e60a51613a738e
- 0x1cb69cb31999eb88e83c7586aac53f5e3286b084b0cf9e43619b48df01e0a310
- 0x3bf36e3ddc690a1b12b417628c115959b373d056c90c42dc2417baf46f538868
- 0xe336594f29dcda52e48896517b5cdb2d062ffd861ab02db5f8ca197aacc635f6
- 0xc1f396a8bad16bb0f57da6d380402a25b571bd4691226d11449a741440e325c8
- 0x5195336ec73751de066e3a8939b40c3c5555f1a513486dfc50dcf4c2d47e6ff2
- 0x8dcf872f3ded2b7ed1d1ee9a2b125bedc6eacd3c09b3a4a5286d8fc2fc3a6634
- 0x950dd2ef7be25eab686a6688497962ee4ad521da12b9ff3d8e56ad9435885b12
- 0xe14389d1d8448678cac33fdbc9aab20dba019e75149d170dd2f353891cd4b84f
- 0xe84906c09cd6423865baf64e48027cc598d52bdb90b17524c87ea892e53b5200
- 0x493cea587f1ec5622c04221cd6e5a41c26c1c1c24c0375f7aaa367d9678d83bc
- 0x5aca0010aced30bcb3b84a7f10ea39c4269ab7c92fcb6cff52958d8921ef2cc5
- 0x4498fa8340f41467c0fa813bd0ca83ef6e1c4b85c7b1168a94339fd9e8296139
- 0xf9a95b738a8e775421b1baa503abbeed2d283b236ebba25e1954b3c993d30a3d
- 0x98178711d03a0b1204ebb56b37bd3a2724dfb08e4dc925609391768b126d21f2
- 0x79251f49534f5c4b10b798b2dbf6e80a3b07593f616ce6a9617ccc61040aac78

Vector 3: WriteFieldElementArray

Starting from the state at the end of Vector 2, (a) write the 2-long array of field elements [8, 9]; (b) generate 16 field elements:

Vector 4: Nat

Starting from the state at the end of Vector 3,
- (a) write the 4-byte string "nats";
- (b) call nat(n) with the following list of parameters:
  - [1, 1, 1, 2, 2, 2, 7, 7, 7, 7, 32, 32, 32, 32, 256, 256, 256, 256, 1000, 10000, 60000, 65535, 100000, 100000].
- The result of each call corresponds to:
  - [0, 0, 0, 0, 0, 0, 3, 0, 4, 5, 10, 30, 27, 22, 100, 189, 3, 92, 999, 3105, 40886, 51590, 56367, 10678]

Vector 5: Choice

Starting from the state at the end of Vector 4, (a) write the 6-byte string "choose"; (b) call choose(m, 20) for the following values of m:
- m=31, k=20: [10, 29, 30, 11, 4, 15, 16, 28, 19, 21, 25, 18, 17, 3, 5, 23, 24, 22, 6, 1]
- m=32, k=20: [3, 17, 18, 8, 30, 7, 14, 19, 25, 23, 12, 4, 31, 16, 0, 6, 20, 27, 11, 10]
- m=63, k=20: [9, 56, 61, 45, 35, 53, 51, 3, 39, 32, 31, 6, 59, 58, 54, 22, 27, 62, 55, 19]
- m=64, k=20: [12, 52, 39, 17, 51, 38, 58, 2, 28, 27, 46, 63, 61, 50, 40, 55, 47, 13, 56, 32]
- m=1000, k=20: [157, 668, 572, 138, 913, 994, 797, 249, 440, 723, 489, 241, 383, 108, 710, 341, 406, 585, 42, 692]
- m=65535, k=20: [40745, 48408, 17108, 44500, 53993, 10008, 24910, 52200, 61265, 54989, 41237, 25958, 28697, 61187, 34729, 3525, 9005, 38627, 9724, 12169]

Test Vectors for Explicit Circuit, Sumcheck, and Ligero The following test vectors verify the complete zero-knowledge proof system using explicitly constructed layered quadratic circuits without requiring external binary circuit files or formats.

Randomness used by these vectors A Ligero commitment consumes randomness for the three blinding rows, for the NREQ random elements that prefix every witness and quadratic row, and for the Merkle leaf nonces. A proof is therefore reproducible only with respect to a fixed source of randomness. Both vectors below draw from the following deterministic generator, seeded with 12345, which is defined for test purposes only and MUST NOT be used to produce real proofs: Vec { let mut out = Vec::with_capacity(len); let mut state = self.state; for _ in 0..len { state = state .wrapping_mul(6364136223846793005) .wrapping_add(1442695040888963407); out.push(((state >> 32) & 0xff) as u8); } self.state = state; out } } ]]> The NREQ Merkle nonces of the opened columns are reproduced below for each vector, so that an implementation can check its commitment independently of the generator above. They also appear verbatim in the complete proof serialization, immediately after the four response polynomials and immediately before the run-length coded columns.

Vector 1: s-gonal Circuit over P-256 (Field ID 2)

Description: Circuit C(n, m, s) = 0 \iff (s - 2)m^2 - (s - 4)m - 2n = 0 verifying that n is the m-th s-gonal polygonal number over the NIST P-256 scalar field \mathbb{F}_p.
Field: P-256 Scalar Field (Field ID 2, order p = 115792089210356248762697446949407573530086143415290314195533631308867097853951)
Witness Inputs: W = [w_0, w_1, w_2, w_3] = [1, 45, 5, 6] with public input w_0 = 1, and private inputs n = 45, m = 5, s = 6.
Explicit Circuit Definition:
- Inputs: N_{in} = 4, N_{pub} = 1.
- Layer 1 (Intermediate wires U = [u_0, u_1, u_2, u_3, u_4] from input W):
  - u_0 = 1 = w_0 \cdot w_0
  - u_1 = m^2 = w_2 \cdot w_2
  - u_2 = s - 2 = w_3 \cdot w_0 - 2 \cdot w_0 \cdot w_0
  - u_3 = (s - 4)m = w_3 \cdot w_2 - 4 \cdot w_0 \cdot w_2
  - u_4 = 2n = 2 \cdot w_0 \cdot w_1
- Layer 0 (Output wire y_0 = 0 from intermediate U):
  - y_0 = u_2 \cdot u_1 - u_3 \cdot u_0 - u_4 \cdot u_0 = (s-2)m^2 - (s-4)m - 2n = 0
Proof System Parameters:
- RATE_INV: 4 (\rho = 1/4)
- NREQ: 6 (query count)
- NCOL: 64 (encoded codeword length)
- Derived geometry: BLOCK = 10, DBLOCK = 19, WR = 4, NW = 29, NQ = 2, NWROW = 8, NQT = 1, NROW = 14
Statement hash: the 23-byte ASCII string sgonal_test_vector_p256
RNG seed: 12345
Merkle nonces (one per opened column, in the order the columns were chosen):
- d406ef8c46fd239545520a5363d67d61bad1750d37b087c1e3611a12d47e477f
- 5fe986cae604828cae4bfbbc7415d64cd5e755848755a0d9d3120ad46eea8d86
- 0fa8593d45fef897767ce05ec5feac76d8f21910bc0ada856aeaa777629048ef
- 63619b9a06c668a2414e46f859a2fdb1ba63e8718fa6ce4bf532b2fb0b8ff4ef
- c9e35514c0ff4b62cb9730116947bef69325f3a4c1c6553b7bd161754f8008d8
- 057ec47e747c61954419b634dec16eb6adfeafb1a0e9fafbb2a9c85fcf9bced4
Commitment Root: 803aba51698a4bc4dddaa74b1d9971b8ec7c49c4847a7ff18e41dd476edf9b04
Sumcheck Proof Size: 768 bytes
Sumcheck Proof (hex):
Ligero Proof Size: 4652 bytes
Total ZK Proof Size: 5452 bytes
Complete Proof Serialization (hex):

Vector 2: Quadratic Polynomial Circuit over GF(2^128) (Field ID 5)

Description: Circuit verifying (s + 1)m^2 + (s + 1)m + n = 0 over the binary field GF(2^{128}).
Field: GF(2^{128}) (Field ID 5, polynomial representation modulo x^{128} + x^7 + x^2 + x + 1)
Witness Inputs: W = [w_0, w_1, w_2, w_3] = [1, 84, 5, 6] with public input w_0 = 1, and private inputs n = 84, m = 5, s = 6.
Explicit Circuit Definition:
- Inputs: N_{in} = 4, N_{pub} = 1.
- Layer 1 (Intermediate wires U = [u_0, u_1, u_2, u_3, u_4]):
  - u_0 = 1 = w_0 \cdot w_0
  - u_1 = m^2 = w_2 \cdot w_2
  - u_2 = s + 1 = w_3 \cdot w_0 + w_0 \cdot w_0
  - u_3 = (s + 1)m = w_3 \cdot w_2 + w_0 \cdot w_2
  - u_4 = n = w_0 \cdot w_1
- Layer 0 (Output wire y_0 = 0):
  - y_0 = u_2 \cdot u_1 + u_3 \cdot u_0 + u_4 \cdot u_0 = (s+1)m^2 + (s+1)m + n = 0
Proof System Parameters:
- RATE_INV: 4 (\rho = 1/4)
- NREQ: 6 (query count)
- NCOL: 64 (encoded codeword length)
- Derived geometry: BLOCK = 10, DBLOCK = 19, WR = 4, NW = 29, NQ = 2, NWROW = 8, NQT = 1, NROW = 14
Statement hash: the 26-byte ASCII string sgonal_test_vector_gf2_128
RNG seed: 12345
Merkle nonces (one per opened column, in the order the columns were chosen):
- 7ef857289b65bef3539deca0df3f44c67bd0f86b02afddd2eaf2df6b9ba36497
- 33946263e6da1ec940a9047547a6296f465821313eeb867d988aed265b82eb53
- 87b402da5412750ec00175350a9579b1f458b668155ba582d31b5d71331f2d41
- 978ee556b7e529dea3e0fbbde3d83fcb11871c478dd3ddb15fc27e628487950e
- 1c320449d0bed51ad492d371d066d55c4db059a1c59c267094ae3087746b1e61
- c809ce332b7354d1e4b593f335d980dc1f0579e171a0bd092761a12006f3b544
Commitment Root: 30dafd53c4f2441bb8457cd84fa69b3a822fbda58a46527d5cec8ce1903bc504
Sumcheck Proof Size: 384 bytes
Sumcheck Proof (hex):
Ligero Proof Size: 2632 bytes
Total ZK Proof Size: 3048 bytes
Complete Proof Serialization (hex):