The Zcash ArboretumThe Complete Arboretum PDF

7 Recursive proof composition and accumulation schemes

This section states recursive proof composition and accumulation for the inner-product argument; Orchard deploys neither. The protocol specification uses Halo 2 for one purpose, to prove and verify Action statements (protocol specification, § 4.1.13, “Zero-Knowledge Proving System”), and requires every Action proof to be valid (§ 4.6, “Action Descriptions”); the design proposal that introduced the pool states that it makes no use of the proof system’s support for recursive proofs (ZIP 224, under “Proving system”). A verifier holding several proofs may still check them together. The complete verification equation Ei of each proof is a multi-scalar multiplication over all d generators that should evaluate to 𝒪 (§3.8.1, “Batch verification”); for independent uniform μ1,…,μb∈𝔽 the verifier of b proofs checks ∑i[μi]⁢Ei=𝒪 instead. If some Ej≠𝒪, then Ej generates the group of prime order, so for any fixed values of the other factors exactly one μj satisfies the combined check, and a false batch passes with probability 1/|𝔽| (Lemma 3.14). Batch verification verifies the batch and emits nothing; it is not the accumulation developed here. In the classification of §1.2, the Pasta curves and the use Orchard makes of them (§7.4) are specified; recursion and accumulation over those curves are designed-but-unspecified: their constructions are published and the halo2 book describes them (Recursion chapter), and ZIP 224 leaves them to future protocol updates, but no specification defines a recursive statement or an accumulation rule for Zcash. Theorem 7.4 and Proposition 7.5 below are theorems, the first cited and the second proved.

7.1 Recursion and its two classical obstacles

The setting.

Consider a computation iterated many times,

zm=f(m)⁢(z0):=f⁢(f⁢(⋯⁢f⁢(z0)⁢⋯)),

one step f applied m times to an initial state, and suppose a verifier wants to be sure that zm is the honest result without recomputing the m steps. Valiant’s incrementally verifiable computation asks for a proof of zm that is updated step by step, each update costing about one step’s worth of proving and the finished proof no larger than the proof of a single step. The more general setting, in which computations branch and merge and each step consumes the proofs of its predecessors, is the proof-carrying data of Chiesa and Tromer: every message in a distributed computation carries a proof that it was produced correctly from messages that themselves carried such proofs.

The construction.

The natural construction is recursive proof composition: proving, inside one proof, that another proof verifies. Write 𝒱 for the verifier of a non-interactive argument (Crypto Guide, §“SNARKs: succinct non-interactive arguments of knowledge”), and suppose its algorithm is itself arithmetised, in the sense of §2, into a PLONKish circuit of Definition 2.7, the verifier circuit: its instance columns hold the statement and its advice columns hold a proof, and its gates are satisfiable exactly when 𝒱 accepts that proof of that statement. At step i+1 the prover proves the compound statement

“zi+1=f⁢(zi), and there exists a proof πi that the verifier circuit accepts for the statement of step i.”

The proof πi is advice of the step-(i+1) circuit, never sent onward; the proof πi+1 that results attests to step i+1 and, through the embedded verifier, to πi, hence to step i, and so on down to z0. One proof attests to the entire history, and the cost of producing πi+1 is the cost of one step of f plus one run of the verifier circuit, independent of how long the history is. The requirement on which everything rests is the one just used: the argument’s verifier must be efficiently expressible as a circuit. A verifier whose circuit is as large as the computation it checks would make each step as expensive as the whole history, and the construction would buy nothing.

Two obstacles.

The classical instantiations meet that requirement badly, in two different ways.

  1. 1.

    Pairings in a circuit, and a ceremony. The pairing-based systems, Groth16, which Sapling deploys, and PLONK compiled with the KZG commitment (Crypto Guide, §“SNARKs: succinct non-interactive arguments of knowledge” for Groth16 and the bilinear pairing; §“Polynomial commitment schemes”, under “KZG: evaluation in the exponent”), have constant-size proofs and verifiers that run in time independent of the circuit. But those verifiers evaluate pairings, and a pairing lands in a target group that lives in an extension field 𝔽pe of the curve’s base field, of degree e equal to the curve’s embedding degree (Crypto Guide, §“Instantiation on elliptic curves; the Pasta curves”, the large-embedding-degree criterion). A circuit whose native arithmetic is one prime field must emulate arithmetic in another field with many gates per operation, so a pairing is costly to express inside a circuit. These particular systems also need a trusted setup, the ceremony that §3.8.1 contrasted with hashed generators.

  2. 2.

    A linear-time verifier. The transparent systems built on the inner-product argument of §3 need no pairing and no ceremony, but their verifier is linear in the size of the committed vectors: the one multi-scalar multiplication G(0)=⟨𝐬,𝐆⟩ of length d that §3.4 singled out. Inside a verifier circuit that multiplication is d scalar multiplications of curve points, each a double-and-add with ℓ−1 doublings for an ℓ-bit scalar (Math Guide, §“Scalar multiplication and double-and-add”), so the verifier circuit grows linearly in d, the length of the committed vectors of the proof it verifies. A linear-time check dominates the verifier circuit and negates the per-step economy that recursion was meant to deliver.

Deferred verification.

Halo, the construction of Bowe, Grigg and Hopwood (Halo: Recursive Proof Composition without a Trusted Setup) from which Halo 2 descends, defers the linear-time part of verification instead of recomputing it at every step, and uses the inner-product argument, in which no pairing occurs. Bünz, Chiesa, Mishra and Spooner formalised the deferral as an accumulation scheme (Proof-Carrying Data from Accumulation Schemes; BCMS20), the notion the next subsection defines; their Theorem 7.1 is quoted below, without proof, as Theorem 7.4.

7.2 Accumulation schemes

The idea is to separate what a verifier must check at each step from what can be checked once, at the end of a chain. Fix a predicate Φ, a property of an input q decidable in polynomial time, for example “this inner-product opening is correct” of a transcript of Construction 3.2. An accumulation scheme replaces a sequence of checks of Φ by a sequence of accumulation steps and one run of a decider.

Definition 7.1 (Accumulation scheme).

Let λ be the security parameter (Crypto Guide, §“Adversaries and the security parameter”) and Φ a predicate on inputs q. An accumulation scheme for Φ is a triple (𝖯,𝖵,𝖣) of polynomial-time algorithms with access to a common random oracle, whose accumulators are bit strings.

  1. 1.

    The accumulation prover 𝖯, on input q and an old accumulator 𝖺𝖼𝖼old, outputs a new accumulator 𝖺𝖼𝖼 and an accumulation proof π𝖵.

  2. 2.

    The accumulation verifier 𝖵, on input (q,𝖺𝖼𝖼old,𝖺𝖼𝖼,π𝖵), outputs a bit; the bit 1 asserts that 𝖺𝖼𝖼 correctly accumulates q and 𝖺𝖼𝖼old.

  3. 3.

    The decider 𝖣, on input an accumulator, outputs a bit; an accumulator is valid if 𝖣 outputs 1 on it.

The scheme is complete if, whenever Φ⁢(q)=1, 𝖣⁢(𝖺𝖼𝖼old)=1 and (𝖺𝖼𝖼,π𝖵) is an output of 𝖯 on (q,𝖺𝖼𝖼old), both 𝖵⁢(q,𝖺𝖼𝖼old,𝖺𝖼𝖼,π𝖵)=1 and 𝖣⁢(𝖺𝖼𝖼)=1. It is sound if for every adversary of size polynomial in λ that outputs (q,𝖺𝖼𝖼old,𝖺𝖼𝖼,π𝖵) the probability, over the random oracle and the adversary’s coins, of

𝖵⁢(q,𝖺𝖼𝖼old,𝖺𝖼𝖼,π𝖵)=1∧𝖣⁢(𝖺𝖼𝖼)=1∧(Φ⁢(q)=0∨𝖣⁢(𝖺𝖼𝖼old)=0)

is negligible in λ.

The definition is that of BCMS20 (Section 4.1) with one input and one old accumulator per step; theirs admits any number of each and adds a generator and an indexer, which fix the public parameters and keys left implicit here. For recursion the size of an accumulator must also be bounded independently of the number of inputs accumulated into it (BCMS20, Definition 5.1).

Soundness carries the checks along a chain.

Lemma 7.2 (Soundness along a chain).

Let (𝖯,𝖵,𝖣) be sound in the sense of Definition 7.1, let 𝖺𝖼𝖼0 be valid, and let m be polynomial in λ. For any efficient algorithm producing q1,…,qm and 𝖺𝖼𝖼1,…,𝖺𝖼𝖼m, where 𝖺𝖼𝖼i accumulates qi and 𝖺𝖼𝖼i−1, such that 𝖵 accepts every step and 𝖣⁢(𝖺𝖼𝖼m)=1, the probability that Φ⁢(qi)=0 for some i is at most m times the soundness error of the adversary that outputs step i for a uniform i∈{1,…,m}; it is therefore negligible.

Proof.

If some qi violates Φ, then either 𝖺𝖼𝖼i is valid and step i exhibits the event of the soundness definition, or some later step j>i turns an invalid 𝖺𝖼𝖼j−1 into a valid 𝖺𝖼𝖼j and exhibits it. Let 𝒜 be the algorithm that produces the chain and outputs step i for a uniform i∈{1,…,m}; since the bad event forces some step to exhibit the soundness event, its probability is at most m times the soundness error of 𝒜, which is negligible because m is polynomial (Math Guide, §“Polynomial, exponential, and negligible functions”, the closure properties). □

The verifier of each step runs the accumulation verifier and never the decider. In a recursive chain the accumulation verifier runs inside the circuit of the step’s proof, so the argument also needs the knowledge soundness of each step’s proof, to recover what that circuit checked; BCMS20 prove the resulting proof-carrying data secure for computations of constant depth, which for a chain means constant length, because the extractor is applied recursively once per level (Theorem 5.2 and Remark 5.3).

For an inner-product polynomial commitment such a scheme is known under the hypothesis of Theorem 7.4 below, and it resolves the second obstacle of §7.1 where it arose: the verifier circuit runs the O⁢(log⁡d) part of the opening check, the rounds, the scalars and the small combinations of points, and accumulates the O⁢(d) part, the claim about G(0), into a running accumulator; the decider pays that multi-scalar multiplication once, at the end of the chain. The next subsection defines the accumulator, states the scheme as an interface theorem, and works the fold on the toy curve.

7.3 Accumulation and the Halo trick

The asymmetry, recalled.

Everything the verifier of Construction 3.2 does to decide the check (15), or its deployed form (29), is logarithmic in d: 3⁢k−2 field multiplications for g⁢(x;𝐮), a combination of the 2⁢k received points and a handful of fixed ones with O⁢(k) scalar multiplications, and a comparison of two curve points. The single exception is the evaluation

G(0)=⟨𝐬,𝐆⟩=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;u1,…,uk); 0),

a multi-scalar multiplication of length d over all the generators, which §3.4 named the one linear step and recognised as the unblinded commitment to the polynomial g whose value the verifier had just computed cheaply. Verifying an Action proof as the consensus rules require includes that step for every proof; batch verification, recalled at the start of this section, evaluates one combined multiplication for the proofs of a batch, and the batch is verified and nothing survives it. Accumulation takes the same kind of linear combination and does something else with it: it carries the combined claim forward as data, unverified, and pays for it once at the end of a chain. Figure 18 sets the two side by side; the rest of this subsection is the right-hand panel, and none of it is deployed by Orchard.

Refer to caption
Figure 18: Left: batch verification. Each proof’s complete verification equation Ei is a multi-scalar multiplication over the d generators (amber); the verifier combines them with fresh random factors and evaluates one multiplication immediately (red), then accepts or rejects. Right: accumulation. Each proof’s deferred claim is accumulated into a running accumulator (green), each step being checked at logarithmic cost; the accumulator is emitted for the next step, and a decider evaluates one length-d multiplication at the end of the chain. Both take random linear combinations; only the right-hand scheme carries a claim forward.

The atomic accumulator.

The claim to be deferred has a fixed shape, and the accumulator is that shape written down.

Definition 7.3 (Atomic accumulator for the inner-product argument).

An accumulator instance is a tuple

𝖠𝖼𝖼:=(G(0),u1,…,uk)∈𝔾×(𝔽×)k,

a curve point and the k round challenges of one opening. It is valid if and only if

G(0)=⟨𝐬⁢(𝐮),𝐆⟩=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;u1,…,uk); 0), (35)

with 𝐬⁢(𝐮) and g the structured scalars and the polynomial of Theorem 3.3, in the symmetric normalisation of Construction 3.2. The deferred claim concerns the unblinded commitment: the blinder of the opened commitment was discharged by the [r∗]⁢H term of (15), or the [f]⁢H term of (29), and plays no part in it. From here on the unary 𝖢𝗈𝗆𝗆𝗂𝗍⁢(⋅) abbreviates 𝖢𝗈𝗆𝗆𝗂𝗍⁢(⋅; 0).

The deployed analogue replaces 𝐬⁢(𝐮) and g by their forms in Remark 3.9; Proposition 7.5 and, with verifier-drawn challenges, the closure argument below hold for it verbatim, with Corollary 3.13 in place of Theorem 3.5, since they use only the linearity of the commitment, the degree of g and the knowledge soundness of the opening.

A verifier who is handed a point G(0) together with the challenges can complete the check (15) in O⁢(log⁡d) operations provided the tuple is valid; validity is precisely what he has not paid for. The scheme quoted next lets him defer that payment.

Theorem 7.4 (Accumulation for the inner-product argument; interface).

Let PCDL be the inner-product polynomial commitment of BCMS20 (Appendix A.2), for polynomials of degree below d over a group 𝔾 of prime order, and suppose that PCDL is a polynomial commitment scheme in the random oracle model, its openings in particular being extractable. Then (BCMS20, Theorem 7.1) there is an accumulation scheme in the sense of Definition 7.1, in the random oracle model, for the predicate “this PCDL opening is correct”, whose accumulators are themselves PCDL openings, such that:

  1. 1.

    the accumulation prover 𝖯 runs in time dominated by O⁢(d) scalar multiplications in 𝔾;

  2. 2.

    the accumulation verifier 𝖵 runs in time dominated by O⁢(log⁡d) scalar multiplications in 𝔾;

  3. 3.

    the decider 𝖣 is the opening check of PCDL: a succinct part, which yields a tuple of the form of Definition 7.3 in the normalisation of Remark 3.9, followed by the validity check (35) of that tuple, one multi-scalar multiplication of length d.

The theorem is quoted as an interface and not proved in this volume. Its hypothesis, the extractability of PCDL openings, is stated by BCMS20 as a conjecture from the binding of the Pedersen commitment, the extractor they record for the Fiat–Shamir-compiled opening running in superpolynomial time (BCMS20, Appendix A.3.2). The scheme PCDL is neither Construction 3.2, whose fold is symmetric, nor the deployed opening of Remark 3.9, which blinds every commitment and subtracts [v]⁢G0 where PCDL adds a multiple of its inner-product generator (the halo2 book’s Comparison to other work chapter); no theorem transferring it to either is proved here or cited, and in the classification of §1.2 that transfer, like accumulation over these curves, is designed-but-unspecified. What an accumulation step does for Construction 3.2, and why its random combination is sound, is worked out below at the level the volume proves things.

The accumulation step in the verifier circuit.

Consider a Halo 2 verifier circuit, expressed over the scalar field of one Pasta curve and verifying a proof produced over the other curve, an arrangement whose necessity §7.4 explains. At step i of a chain the circuit receives the previous proof πi−1, whose opening is an instance of Construction 3.2, and the accumulator 𝖠𝖼𝖼i−1 exposed as a public input of πi−1, of which it uses the instance on the curve πi−1 is committed on (see below), and does three things.

  1. 1.

    Run the succinct part. It recomputes the challenges 𝐮′ of the opening from the transcript, evaluates g⁢(x;𝐮′) with O⁢(k) scalar operations, and forms the left-hand side of (15) and every term of the right-hand side except the one on the final generator, here written G′⁣(0), with O⁢(k) point operations. The point operations are native, since the points of πi−1 have coordinates in the circuit’s field. The challenges, g⁢(x;𝐮′) and the scalar products lie in the scalar field of the curve πi−1 is committed on, the other Pasta field; they are computed non-natively, or exposed as public inputs and checked by the next circuit of the chain, which is native to that field (“What the cycle does and does not buy” in §7.4; the halo2 book’s Recursion chapter).

  2. 2.

    Witness the expensive part. It does not compute G′⁣(0). The prover of the step supplies the claimed point as advice, and the circuit uses it to complete the check, which is then passed conditionally on the validity of the fresh tuple (G′⁣(0),𝐮′) of that opening.

  3. 3.

    Accumulate. The step now holds two claims of the shape (35): the inherited instance (G(0),𝐮) of 𝖠𝖼𝖼i−1 and the fresh (G′⁣(0),𝐮′). For a challenge ρ derived by the random oracle from both tuples, the two reduce to the single claim

    G(0)+[ρ]⁢G′⁣(0)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮)+ρ⁢g⁢(X;𝐮′))=⟨𝐬⁢(𝐮)+ρ⁢𝐬⁢(𝐮′),𝐆⟩, (36)

    whose coefficient vector on the right anyone holding both challenge tuples can recompute. Proposition 7.5 shows that a false input survives the combination for at most one ρ. The step’s prover then opens the combined point at a fresh point, outside the circuit, and the circuit checks that opening succinctly as in item 1; the tuple the opening leaves behind is the new accumulator 𝖠𝖼𝖼i (over a 2-cycle, its instance on that curve), exposed as a public input of the proof πi the step produces. The paragraph “Closure: the prover-assisted step” below describes that opening.

Over a 2-cycle of curves (§7.4) the proofs alternate between the two curves, and the accumulator is a pair of instances, one per curve. The step that verifies a proof committed on one curve folds that proof’s fresh tuple into the instance on the same curve, which was last updated two steps earlier and forwarded unchanged by the intervening step, and it forwards the other curve’s instance in the same way, without point arithmetic. Figure 19 draws the chain. At its end a single multi-scalar multiplication of length d, run outside any circuit, checks the last accumulator and with it every opening in the history: for the scheme of Theorem 7.4 by Lemma 7.2.

Refer to caption
Figure 19: A chain of recursively composed proofs. Each step’s verifier circuit (blue) runs the logarithmic part of the previous proof’s opening check, witnesses the expensive point instead of computing it, combines the resulting tuple with the accumulator (green) it inherited by (36), and checks succinctly the opening of the combined point at a fresh point, whose tuple is the new accumulator, a public input of the step’s own proof. Over a cycle of curves each 𝖠𝖼𝖼i is a pair of instances, one per curve: each step folds into the instance on the curve of the proof it verifies and passes the other through unchanged. The decider (red) pays one length-d multi-scalar multiplication at the end of the chain, and no circuit ever contains one.

Why the fold is sound.

The soundness of the fold (36) is one line of linear algebra in the group.

Proposition 7.5 (Soundness of the ρ-fold).

Let (G(0),𝐮) and (G′⁣(0),𝐮′) be two accumulator instances and ρ uniform in 𝔽, drawn after both are fixed. If both instances are valid, the folded equation (36) holds for every ρ. If at least one is invalid, it holds for at most one value of ρ, hence with probability at most 1/|𝔽|.

Proof.

Set Δ:=G(0)−𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮)) and Δ′:=G′⁣(0)−𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮′)), the two errors. By linearity of the commitment (Crypto Guide, §“Pedersen vector commitments”, the remark that linearity survives), 𝖢𝗈𝗆𝗆𝗂𝗍⁢(g+ρ⁢g′)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g)+[ρ]⁢𝖢𝗈𝗆𝗆𝗂𝗍⁢(g′), so the left-hand side of (36) minus the right is Δ+[ρ]⁢Δ′, and the equation holds exactly when

Δ+[ρ]⁢Δ′=𝒪. (37)

If both instances are valid, Δ=Δ′=𝒪 and the equation holds for all ρ. Otherwise two cases. If Δ′≠𝒪, then, 𝔾 being cyclic of prime order, Δ′ generates 𝔾 and the map ρ↦[ρ]⁢Δ′ is a bijection 𝔽→𝔾 (Math Guide, §“The mixed inner product with group elements”, the one-dimensional vector space 𝔾 over 𝔽), so exactly one ρ sends Δ′ to −Δ: the discrete logarithm of −Δ to the base Δ′, which exists whether or not anyone can compute it. If Δ′=𝒪, then Δ≠𝒪 and (37) holds for no ρ. A uniform ρ hits the at most one bad value with probability at most 1/|𝔽|. □

Example 7.6 (The fold on the toy curve).

The fold is run on the 97-point curve and the four generators G0,…,G3 of §3.7, with d=4 and the symmetric structured scalars of Theorem 3.3, on two challenge tuples, (u1,u2)=(52,44) with 𝐬=(80,10,68,57) and G(0)=⟨𝐬,𝐆⟩=(21,10), and (u1′,u2′)=(41,39) with 𝐬′=(64,11,53,47) and G′⁣(0)=(23,2), both valid by construction, for every ρ∈𝔽97. With both instances valid the folded equation (36) holds for all 97 values of ρ. Spoiling an instance by adding a nonzero multiple of G0 to its point makes its error Δ a nonzero point, and the surviving values of ρ are counted again. With the first instance false and the second valid, no ρ survives: this is the case Δ′=𝒪≠Δ of the proof. With the second false and the first valid, exactly one survives, ρ=0, the value that discards the second instance altogether. With both false exactly one survives, ρ=50, the discrete logarithm of −Δ to the base Δ′ on this curve, where such logarithms are a short search. In every spoiled case the count is at most one of 97: the bound 1/|𝔽| of Proposition 7.5, attained.

Closure: the prover-assisted step.

The folded claim (36) is not an accumulator instance. Its coefficient vector 𝐬⁢(𝐮)+ρ⁢𝐬⁢(𝐮′) is in general not the structured vector of any single challenge tuple, so carrying it means carrying both tuples, and after m folds all m of them: the decider would still pay one multiplication of length d, but the accumulator would grow with the chain, against the size bound that recursion requires (§7.2). The tuple type of Definition 7.3 is therefore not closed under verifier-side linear combination alone. It is closed under one more step, which the prover assists. Write A:=G(0)+[ρ]⁢G′⁣(0) for the combined point and a⁢(X):=g⁢(X;𝐮)+ρ⁢g⁢(X;𝐮′) for the combined polynomial, of degree below d. The combined claim says exactly that A=𝖢𝗈𝗆𝗆𝗂𝗍⁢(a). The step’s prover opens A by the opening protocol of Construction 3.2 at a fresh point x′, derived by the random oracle from A and both tuples, claiming the value a⁢(x′), which the verifier computes for himself in O⁢(k) field operations from the two tuples, since g⁢(x′;𝐮) and g⁢(x′;𝐮′) are each a product of k factors. That opening does two things at once. First, it carries the combined claim up to a blinder.

Proposition 7.7 (Prover-assisted step, verifier-drawn challenges).

Under the hypotheses of Theorem 3.5, let ρ, x′ and the opening’s challenges be drawn uniformly by the verifier, in this order, ρ after the two tuples are fixed. There is an extractor which, given rewindable access to a step prover accepted with non-negligible probability, runs in expected polynomial time and outputs either blinders δ,δ′ with G(0)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮);δ) and G′⁣(0)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮′);δ′), or a nontrivial discrete-logarithm relation among 𝐆, H, U, U′. Its knowledge error is O⁢(log⁡d/|𝔽|)+(d−1)/|𝔽|+1/|𝔽|.

Proof.

By Theorem 3.5 the opening yields a representation A=⟨𝐚∗,𝐆⟩+[rA]⁢H, unique since a second one would be a discrete-logarithm relation among 𝐆 and H, and certifies a∗⁢(x′)=a⁢(x′) for the polynomial a∗ with coefficient vector 𝐚∗; two polynomials of degree below d that differ agree at a uniform x′, drawn after A was fixed, with probability at most (d−1)/|𝔽| (Math Guide, §“The Schwartz–Zippel lemma”), so except with that probability 𝐚∗ is the coefficient vector of a and A=𝖢𝗈𝗆𝗆𝗂𝗍⁢(a;rA). The blinder rA is the prover’s and need not be 0. Rewinding the choice of ρ and extracting again at a second value ρ~≠ρ gives representations of A and of A~:=G(0)+[ρ~]⁢G′⁣(0), whose difference is [ρ−ρ~]⁢G′⁣(0); solving yields G′⁣(0)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮′);δ′) and G(0)=𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮);δ) for blinders δ,δ′ that the extractor computes. This is the argument of Proposition 7.5 applied to the 𝐆-coordinates of the representations: a combination correct at two values of ρ has both errors zero. It is all the chain needs: a tuple whose point is 𝖢𝗈𝗆𝗆𝗂𝗍⁢(g⁢(X;𝐮);δ) still certifies the opening it came from, because, writing c for the final scalar that (15) calls a,

[c]⁢𝖢𝗈𝗆𝗆𝗂𝗍⁢(g;δ)+[r∗]⁢H=[c]⁢𝖢𝗈𝗆𝗆𝗂𝗍⁢(g)+[r∗+c⁢δ]⁢H,

so that opening satisfies the honest check with the blinder r∗+c⁢δ in place of r∗, and Theorem 3.5 applies to it; in (29) the offset joins the term [f]⁢H likewise. The chain thus carries the claim that each deferred point’s 𝐆-coordinates are 𝐬⁢(𝐮); the exact equality (35), blinder 0 included, is required only of the last accumulator, which the decider checks and an honest prover satisfies. An intermediate tuple may miss (35) by such a multiple [δ]⁢H without any opening it serves being false. □

Second, the opening leaves behind a deferred claim of the atomic form: it ends, as every opening does, in a point G′′⁣(0) and challenges 𝐮′′ that the verifier circuit witnesses rather than computes. The accumulator after the step is again one tuple. This is the accumulation step of BCMS20 (Section 7.1), which likewise derives the combining challenge and the fresh point by the random oracle from the tuples and the combined point; there the accumulator is the opening itself, and its succinct part runs at the next step. With ρ, x′ and the opening’s challenges drawn by a verifier, the step’s soundness is Proposition 7.7. With random-oracle challenges, the step’s soundness is BCMS20’s Theorem 7.1 for PCDL under its conjectured extractability (Theorem 7.4); for Construction 3.2 it is designed-but-unspecified.

What the accumulator carries.

The deferred equation (35) is a claim of commitment equality, equivalently a claim about the value of one multi-scalar multiplication, for a coefficient vector 𝐬⁢(𝐮) that is public and structured: anyone holding the challenges can write it down. It is not itself an evaluation opening; no polynomial is being evaluated at any point when the decider runs, only a point recomputed and compared. The accumulation protocol reduces this claim, and carries it along the chain, through the prover-assisted opening just described, which turns each commitment equality into one evaluation claim at a fresh point and each opening back into one commitment equality. The Orchard verifier, once more, does none of this: it computes G(0) and compares.

7.4 A cycle of curves for efficient native recursion

The verifier circuit of §7.3 was “expressed over the scalar field of one Pasta curve and verifying a proof produced over the other”. This subsection explains why the two curves are needed, what the arrangement buys, and where Orchard already uses half of it.

Two fields per curve, recalled.

A curve E over a prime field has two fields attached to it (Math Guide, §“Base fields, scalar fields, and the Pasta cycle”): the base field, in which its points’ coordinates lie and in which the group law’s slopes, squarings and inversions are computed, and the scalar field, the integers modulo the prime order of its group, in which the scalars of [k]⁢P live. Write Ep for a curve over 𝔽p and q:=#⁢Ep⁢(𝔽p) for its prime order, so that its base field is 𝔽p and its scalar field 𝔽q. A PLONKish circuit of Definition 2.7 is defined over one prime field 𝔽, its native field: its cells hold elements of 𝔽 and its gates are polynomial identities over 𝔽, so an addition or multiplication in 𝔽 costs one cell or one gate. Arithmetic in any other prime field is non-native: an element of the other field must be carried as several 𝔽-cells, each range-checked by the lookups of §2.7, and each of its operations becomes many gates with carries and reductions. Which field a circuit is native to is not a free choice. Its column polynomials are committed with the inner-product commitment of §3 on some curve, and a Pedersen commitment to a vector of 𝔽-elements needs a group whose scalar field is 𝔽; so the native field of a circuit is the scalar field of the curve its proof is committed on, exactly as the Action circuit, native to 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, is committed on Vesta, whose order is p𝖯𝖺𝗅𝗅𝖺𝗌 (§3.8).

Why one curve cannot host its own verifier.

Take a proof committed on Ep. Its group elements, the column and quotient commitments, the cross terms (Lj,Rj) and the deferred point of its opening, are points of Ep with coordinates in 𝔽p. The in-circuit folding of §7.3 adds and scales such points, which is base-field arithmetic in 𝔽p, so a verifier circuit handles them natively only if its native field is 𝔽p. But a circuit committed on Ep is native to the scalar field 𝔽q: its challenges, its structured scalars and every field operation of the succinct part are 𝔽q-arithmetic. One curve would host both jobs only if 𝔽p=𝔽q, that is, #⁢Ep⁢(𝔽p)=p. Curves with exactly p points exist; by Hasse’s theorem (Math Guide, §“The group structure of E⁢(𝔽p)”), which writes #⁢Ep⁢(𝔽p)=p+1−t with the trace t, they are the curves with t=1, called anomalous. On an anomalous curve the discrete logarithm is computable in polynomial time, the attack of Smart, of Semaev and of Satoh and Araki, and the Crypto Guide lists “not anomalous” among the criteria a curve must meet to be used at all (§“Instantiation on elliptic curves; the Pasta curves”, the anti-Smart criterion). So no secure curve has 𝔽p=𝔽q, and no one curve can host both the coordinates of its proofs and its own verifier circuit natively.

The 2-cycle.

The efficient resolution uses two curves that trade fields. A 2-cycle of elliptic curves is a pair (Ep,Eq) with

#⁢Ep⁢(𝔽p)=qand#⁢Eq⁢(𝔽q)=p,

both primes: the scalar field of each curve is the base field of the other. Then:

  1. 1.

    a circuit committed on Eq has native field 𝔽p, the scalar field of Eq; and 𝔽p is the coordinate field of Ep, so that circuit manipulates the points of a proof produced over Ep natively, and verifies such a proof at the cost §7.3 counted, the proof’s scalars aside;

  2. 2.

    the proof that circuit produces is committed on Eq, and its points have coordinates in 𝔽q, the native field of a circuit committed on Ep; so a circuit over 𝔽q handles its points natively in turn;

  3. 3.

    the proofs of a chain alternate between the two curves, each step handling its predecessor’s points natively (Figure 20).

Refer to caption
Figure 20: The Pasta 2-cycle. The base field of each curve (its coordinate field) is the scalar field of the other, so a circuit committed on Vesta (green) is native to 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌 and handles Pallas points (blue) natively, and symmetrically. In a recursive chain the proofs alternate along the two arrows. Orchard (amber) uses one direction of the cycle only: Pallas arithmetic inside a Vesta-committed circuit, with no verifier circuit at all.

What the cycle does and does not buy.

The cycle makes the preceding curve’s coordinate arithmetic native; it does not identify the two scalar fields, which remain distinct primes. Challenges squeezed in the previous proof’s field and the scalars derived from them are 𝔽p-elements that the 𝔽q-native circuit must handle: they need compatible encodings across the two fields, range checks where an element of the larger field is carried in the smaller, and, where a genuine 𝔽p multiplication is unavoidable, non-native scalar arithmetic. Nor is the cycle a logical necessity. A single curve could verify its own proofs with non-native coordinate arithmetic throughout, at a cost of many gates per point operation multiplied by the O⁢(log⁡d) point operations of the succinct part; that is possible and substantially more expensive. The cycle is the efficient native design, not the only correct one.

The deployed instance.

The Pasta cycle of the Math Guide (§“Base fields, scalar fields, and the Pasta cycle”; §“Pallas and Vesta assembled”) is a 2-cycle: Pallas is defined over 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌 with group order p𝖵𝖾𝗌𝗍𝖺, and Vesta over 𝔽p𝖵𝖾𝗌𝗍𝖺 with group order p𝖯𝖺𝗅𝗅𝖺𝗌, both curves y2=x3+5 (protocol specification, § 5.4.9.6, “Pallas and Vesta”). The cycle follows from the specification’s two primes and nothing else. With

p𝖯𝖺𝗅𝗅𝖺𝗌 =𝟶⁢𝚡⁢40000000 00000000 00000000 00000000 224698⁢𝚏𝚌⁢ 094⁢𝚌𝚏𝟿𝟷𝚋⁢ 992⁢𝚍𝟹𝟶𝚎𝚍⁢ 00000001,
p𝖵𝖾𝗌𝗍𝖺 =𝟶⁢𝚡⁢40000000 00000000 00000000 00000000 224698⁢𝚏𝚌⁢ 0994⁢𝚊𝟾𝚍𝚍⁢ 8⁢𝚌𝟺𝟼𝚎𝚋𝟸𝟷⁢ 00000001,

the point (−1,2) lies on Pallas, [p𝖵𝖾𝗌𝗍𝖺]⁢(−1,2)=𝒪 there, and exactly one multiple of p𝖵𝖾𝗌𝗍𝖺 lies in the Hasse interval [p+1−2⁢p,p+1+2⁢p] for p=p𝖯𝖺𝗅𝗅𝖺𝗌. That settles the order: the order of the point (−1,2) divides the prime p𝖵𝖾𝗌𝗍𝖺 and is not 1, so it is p𝖵𝖾𝗌𝗍𝖺, which therefore divides #⁢ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌) by Lagrange’s theorem (Math Guide, §“Cosets and Lagrange’s theorem”); the group order lies in an interval of length 4⁢p, far shorter than p𝖵𝖾𝗌𝗍𝖺, which contains one multiple of p𝖵𝖾𝗌𝗍𝖺; hence #⁢ℰ⁢(𝔽p𝖯𝖺𝗅𝗅𝖺𝗌)=p𝖵𝖾𝗌𝗍𝖺. The symmetric check on Vesta shows that the Vesta group has order p𝖯𝖺𝗅𝗅𝖺𝗌. The traces are

t𝖯𝖺𝗅𝗅𝖺𝗌 =p𝖯𝖺𝗅𝗅𝖺𝗌+1−p𝖵𝖾𝗌𝗍𝖺=−86663725065984043395317759,
t𝖵𝖾𝗌𝗍𝖺 =p𝖵𝖾𝗌𝗍𝖺+1−p𝖯𝖺𝗅𝗅𝖺𝗌=86663725065984043395317761,

each far inside the Hasse bound and neither equal to 1: neither curve is anomalous, as the Crypto Guide’s criterion requires. The two traces sum to 2, as they must for any 2-cycle, since (p+1−q)+(q+1−p)=2; the toy curve of §3.7, y2=x3+3 over 𝔽79 with 97 points, has trace 79+1−97=−17, and the case excluded in that subsection, a curve over 𝔽97 with 97 points and so trace 1, is exactly the anomalous one.

The cycle in the accumulation chain.

The Pasta cycle renders each step of §7.3 native. A proof committed on Vesta is produced by a circuit native to 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌; that circuit verifies the previous proof of the chain, committed on Pallas, whose group elements, the column and quotient commitments, the pairs (Lj,Rj) and the point of the Pallas accumulator instance it forwards, have coordinates in exactly 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, so the point arithmetic of the succinct checks and of the fold (36) is native. The next proof, committed on Pallas by a circuit native to 𝔽p𝖵𝖾𝗌𝗍𝖺, verifies the Vesta proof by the symmetric argument. This cross-curve alternation avoids non-native emulation of the preceding curve’s coordinate field; as “What the cycle does and does not buy” said, it does not eliminate the scalar-field conversions.

The half Orchard uses.

This is the part of the cycle in consensus. The Action circuit is native to 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌 and committed on Vesta (§3.8), and the statement it proves manipulates Pallas points: the note commitment 𝖼𝗆, a Pallas point whose x-coordinate 𝖼𝗆𝗑 is a public input; the randomised verification key 𝗋𝗄; and the net value commitment 𝖼𝗏net, the last two exposed by their coordinates in the instance column of §4.2. Their coordinates lie in 𝔽p𝖯𝖺𝗅𝗅𝖺𝗌, the circuit’s native field, by the very coincidence the cycle is built on, so the circuit computes on them natively, with gates such as the incomplete-addition gate of §4.1.2. The protocol specification records the arrangement: Vesta for the proof system, Pallas for the application circuit, both curves designed to be efficiently implementable inside a circuit though only Pallas is so used (protocol specification, § 5.4.9.6, “Pallas and Vesta”); ZIP 224 says the same in the language of this subsection, that the proposal uses half of the cycle, Pallas being the curve embedded in Vesta’s circuits, and that the full cycle is left for future use (ZIP 224, under “Curves”). One direction of Figure 20 is thus in consensus today; the return arrow, and everything in this section that depends on it, is not.