Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

The distributed prover

This chapter describes a distributed variant of the Akita prover: how the witness is split across many machines, which parts of one folding step are local, and the single protocol change — keeping a per-machine folded response — that lets the machines avoid shuffling large witnesses between each other. The machines can be separate GPUs, accelerators, or nodes; nothing below is specific to GPUs.

What "distributed-prover friendly" means

We hold the design to three concrete criteria:

  1. Distributable witness. The witness can be split across independent machines so that each machine owns and processes only its share.
  2. Low cross-machine communication. Machines must not exchange large payloads. Only short commitment vectors and small round-polynomial messages may cross the interconnect; the large per-machine witnesses stay put.
  3. Net speed-up. The resulting scheme must stay efficient enough that the per-machine work plus the small aggregation actually realises the parallel speed-up the hardware promises.

Throughout, assume machines (take , so machines). We divide the witness into contiguous block ranges. When the number of live blocks is not divisible by , a machine owns either the floor or the ceiling of the average; when there are fewer blocks than machines, some ranges are empty.

Setup: partitioning the witness

We spell the design out in the single-opening case (one opening point , one commitment, one committed slot). Let be the exact number of live source ring elements, choose positions per block, and set . The block-index Boolean domain has size , but only the prefix is live. Reshape the coefficient table into blocks , padding only the final block when . The opening point induces the inner evaluation vector and the live block vector , and the evaluation is .

We partition the block index set into contiguous ranges , where , and assign to machine . For and , these ranges are . This is the canonical proportional partition owned by WitnessLayout. Larger index spaces are always partitioned at the block level: for any the block partition induces .

The public key is still the three uniformly random matrices , , and with . All three are prefix views of one seed-expanded matrix, so every machine regenerates the same public columns locally — no setup is broadcast. In the distributed setting we view them column-blocked, and , where hold exactly the columns indexed by 's blocks, and we restrict the block vector as .

Component-by-component locality

We now walk each component of one folding step and check it against the three criteria.

The outer commitment

Machine stores its blocks and performs the ordinary inner commit on each, restricted to its block set. For every it digit-decomposes the block witness , computes the inner commitment , and digitises it to . Writing for the inner-commitment digits it owns, uses only its column block to form the partial outer commitment

The raw relation image is then the sum . The large local witnesses never leave ; only the short -vectors are summed. The aggregation machine negative-binary decomposes that sum through the two F maps and publishes only the 128-byte payload (criteria 1 and 2).

The opening commitment and the claim

The opening side is computed the same way. For every , computes the local block evaluation , digitises it to , and — using only its column block — forms the partial opening commitment , with . The global opening relation image is . The aggregation machine compresses that sum through the two H maps and publishes only the 128-byte payload . Each machine also forms its partial claim , and the claimed evaluation is .

So the raw , raw , and all follow the same pattern: each machine does the same inner/outer/opening computation as the single-machine prover, but only on its own blocks. The machines aggregate only the small relation images and scalar claims; one aggregation machine derives the shared compression digits and public terminal payloads.

The folded response — the hard part

After the verifier samples the folding challenges, the single-machine prover would form one global folded response

But each machine only holds the blocks in , so it can only compute a partial fold from its partial challenges . Crucially, each lives in the full ambient dimension — the same size as the entire folded witness. Summing the into one global would require an all-reduce of this large folded-witness payload across every machine, which directly violates criterion 2.

The protocol change. Instead of reconciling the , we keep them separate. Each becomes its own piece of the next-level witness: machine carries forward its own and never exchanges it. In effect, the next recursive witness now contains folded responses instead of one, and the machines need no -interaction at all.

Security accounting for the shared response

The aggregate commitment-consistency rows act on . This preserves the algebraic identity of the ordinary fold, but it changes the weak-binding envelope. The digit range check is applied separately to every using one common basis and one common digit depth . Thus a large positive coefficient in one chunk cannot be hidden by a negative coefficient in another. If the digit basis is , the exact difference interval for one chunk has diameter , while the difference interval for has diameter

where is the response-chunk count. With denoting the physical mass of the folding challenge, the A-role collision target is

The planner, generated schedule, and verifier admission all derive this exact raw target and select an audited A-role cell no smaller than it. A matrix sized for one response cannot be reused for several response chunks. The current SIS table does not add a separate coverage axis for the chunk count, so a two- or four-chunk schedule may use a conservative next-higher cell rather than the tightest possible collision-bound search. Every chunk retains the same full-width buffer—even an empty block range contributes a full-width zero response—whereas the local and ranges follow the actual number of blocks. The number of response chunks is therefore a protocol parameter, not merely a deployment choice. Production schedules expose only a small fixed set of counts, and verifier validation caps the count so that a malicious schedule cannot force arbitrarily fragmented setup evaluation.

Why only the first few rounds keep per-machine

Keeping a separate per machine is not free, so we do it only for a constant number of leading rounds. Two reasons:

  1. Proof size and fold depth. The separate enlarge the next witness relative to a single . Carrying that growth into the tail and final rounds would inflate the proof size and the number of fold levels, so those rounds keep the single-response protocol.
  2. Where the cost actually is. Only the first few rounds are large enough to be worth distributing. Once the scheduled recursive folds have reduced the full witness, the remaining rounds are cheap and run fine on a single machine. This does not require the root fold itself to shrink the witness.

So the schedule fixes a constant number of distributed rounds. Those leading rounds retain one per machine; the later rounds return to the single-response Akita protocol on one machine.

The next-round witness and the relation change

After the distributed rounds, each machine holds its own and can proceed to the next round on its own. Supporting this requires changing the witness format and the relation matrix so the relation is stated over the concatenation of the per-machine witnesses rather than over one global folded response. The rest of this chapter makes that change precise.

The per-machine partial root relation

Each machine holds its partial witness and the matching partial commitments, plus the fold of its own blocks. Over , machine satisfies:

Stacking these, has a local partial root relation

Denote the block matrix by , the local witness by , and the right-hand side by , so the local relation is compactly .

The virtually shared root relation

The verifier never sees the local ; it sees only the public output , whose entries are the sums of the partial values, and . So instead of exposing the local right-hand sides, the machines jointly prove one virtually shared root relation. With and the horizontal concatenation ,

The relation is virtually shared because no machine materialises the full witness or the full matrix : holds only and its column blocks , while the verifier checks the single public right-hand side obtained by summing the partial commitments.

Ring-switch lift and next-level commitment

Each machine lifts its partial relation from to : there is a unique quotient , with , such that

Summing the local identities, the global quotient is the coefficient-wise modular sum , just as the global commitments are sums of the partial commitments. The aggregated quotient is digit-decomposed as , recovering the same ring-switch witness shape as the single-machine protocol — except the root witness stays written as the concatenation of the per-machine witnesses.

Let be the extended witness. The lifted relation is over , with

The extended witness is assembled into the coefficient table of the next-level multilinear polynomial: each machine contributes its segment , and a pre-assigned aggregation machine additionally contributes the quotient segment . The machines then run the ordinary inner/outer commit at the next level's parameters on their assigned portions and sum the partial next-level relation images into one . The aggregation machine compresses and retains the two shared F digit vectors. The verifier sees exactly the single-machine recursive interface: one 128-byte extended-witness payload and one next-level opening claim.

Ring-switch and row-batching

For the verifier samples the ring-switching challenge and the row-batching point . Viewing the machines as one virtual prover, both sides evaluate the extended matrix at , obtaining and the target , i.e. row equations. Writing the extended matrix as with the quotient block , the row equations at become

The verifier batches the rows with the equality weights . For machine define its local -weighted row combination , and similarly for the quotient block; the batched target is . Let be the multilinear extension of , and let , denote the next-level witness-table coordinates of and . The full batched claim is

Compared with the single-machine claim , the distributed claim simply partitions both witness-dependent factors. Machine owns a subset of the next-level witness table and the matching restriction of the row-batched weight, so no machine materialises the full witness table or the full weight function. In the subsequent sum-check the same decomposition holds round by round: each machine computes the round-polynomial contribution for the coordinates it owns, and the machines aggregate only the small round-polynomial coefficients. The verifier sees the same batched claim as in the single-machine protocol.

Recap against the three criteria

  • Distributable witness. The balanced block partition gives each machine a disjoint contiguous share, and every step — inner/outer/opening commit, the partial fold, the quotient lift, the next-level commit, and the sum-check — is computed per machine over its own blocks.
  • Low communication. Only short objects ever cross machines: the -sized partial commitments , the scalar claims , the coefficient-wise quotient sum, and the small per-round sum-check messages. The large items — the inner/opening digits and, decisively, the folded responses — never leave their machine. Keeping a per-machine is exactly the change that removes the one all-reduce that would otherwise dominate communication.
  • Net speed-up. Per-machine is kept only for the constant block of leading (large) rounds; afterward the prover reverts to the single-machine protocol, so the witness-growth and extra fold levels are bounded and the distributed parallelism translates into an end-to-end win.