PaperlayerView exact revision on arXiv

Source-linked AI summary

Guppy: Efficient Light Clients via Recursive Zero-Knowledge Proofs

George Danezis, Deepak Maram, Arnab Roy, Alberto Sonnino, Karl Wüst

arXiv:2609.07963v2cs.CR

TL;DR

Light clients need efficient state proofs, but validators’ full-state commitments are costly and high-throughput chains may omit them. Guppy has validators commit to updates while an off-chain recursive-proof service maintains a verifiable state tree. Its implementation processes thousands of updates per second with a few seconds of latency, and the authors conclude that completeness can fit modern blockchain performance requirements.

  • Problem

    Full-state commitments burden validators, while high-throughput chains that omit them leave light clients without a way to verify state.

    Source: §1 · p. 1

  • Method

    Guppy has validators commit to checkpoint updates and uses an untrusted off-chain service with recursive ZK proofs to maintain a Merkle tree over full state.

    Source: §1 · p. 2

  • Results

    Guppy processes thousands of state updates per second with a few seconds of end-to-end latency and negligible validator overhead.

    Source: §6 · p. 16

  • Takeaways & Limitations

    The prototype demonstrates that light-client completeness is compatible with modern blockchains’ performance requirements.

    Source: §6 · p. 16

    Supporting event streams requires validators to add a key-value store and address operational concerns such as synchronizing state for new validators.

    Source: §6 · p. 17

Abstract

from arXiv · show

Traditional light clients rely on validators committing to the entire blockchain state at every block via a state commitment such as a Merkle tree, allowing clients to verify facts using short proofs. However, maintaining large and ever-growing state trees imposes a significant burden on validators and lies on the critical path of block production. As a result, many modern high-throughput chains avoid this approach altogether. This work asks whether efficient inclusion proofs can be supported without requiring validators to maintain full state commitments. We present Guppy, a protocol that achieves this by having validators commit to just the state updates. An off-chain, untrusted service, secured by recursive Zero-Knowledge Proofs (ZKPs), then maintains a verifiable Merkle tree over the full state. This design keeps validator overhead negligible and does not increase the asymptotic complexity of block construction. Our design rests on two key technical ideas. First, a hash-chain commitment moves validator signature verification out of the ZK circuit, keeping the proving circuit efficient. Second, we design a parallel recursive proving pipeline that leverages cheap recursion in modern ZKPs to ensure latency grows only logarithmically with throughput. Our Plonky2-based implementation demonstrates that Guppy can maintain a Merkle tree of size 2^30 while processing thousands of updates per second, adding only 2-4 s of latency.

1 Introduction

Full-state commitments make short light-client proofs costly for validators, while high-throughput chains without them leave clients unable to verify state. Guppy has validators commit to updates and uses an off-chain recursive-proof service to maintain a verifiable state tree.

Motivation

  • Full-state commitments burden validators because updates touch multiple database entries and the state grows, while high-throughput chains often omit them and leave light clients without state verification.The paper frames the central question as whether efficient proofs, with logarithmic proof sizes, can be supported without full-state commitments.Source: §1 · pp. 1–2

Design

  • Validators commit only to checkpoint updates; an untrusted off-chain ZK service recursively proves updates advance a Merkle-tree root over the full state.Clients can receive a balance and Merkle path at a checkpoint even when the address last changed years earlier.Source: §1 · p. 2

Guppy-A

  • A hash-chain head in each signed checkpoint header attests to earlier updates and moves validator-signature verification outside the ZK circuit.The circuit exposes the head as a public input, while the client checks it in the signed header and verifies validator signatures.Source: §1 · p. 2

Guppy-B

  • Guppy-B sustains any throughput given enough machines, with end-to-end latency growing only logarithmically with throughput.Its aggregation tree combines parallel proofs before a sequential cyclic proof verifies the prior cyclic proof and aggregated proof once per checkpoint.Source: §1 · pp. 2–3

Evaluation

  • 2,250 updates/s at 4 s median latency were achieved by Guppy-B with 14 machines; microbenchmarks predict 8,571 updates/s at 3.15 s with 41 machines.The validator-side commitment for 213 updates takes under 10 ms; the one-month Sui measurement found peak demand in the thousands of updates per second.Source: §1 · p. 3

Contributions

  • Guppy supports queries over event streams, balances, or objects, including all events of a type at a checkpoint, which Ethereum’s state tree cannot answer.The contributions describe completeness for current and historical state of supported streams with negligible validator overhead, adding one header field per checkpoint.Source: §1 · p. 3

2 Model

The model treats a blockchain as signed checkpoints and its data as evolving streams. Guppy targets verifiable state queries for any stream at any checkpoint while keeping validator resource costs linear in checkpoint size.

2.1 Blockchain model

  • A checkpoint contains transaction contents and a header, commonly with a contents commitment, and validators sign the header under the current committee key.The model applies to signed-checkpoint chains such as Ethereum and Sui, which differ in whether validators commit to a full-state Merkle root.Source: §2.1 · pp. 3–4

2.2 Streams

  • A stream is a key-value map from unique identifiers to short states, updated deterministically from checkpoint contents; updates/s counts stream updates produced or processed per second.Examples include address-balance streams and event streams that fold matching events into a hash-chain state.Source: §2.2 · pp. 4–5

2.3 Goals

  • The goal is completeness—verifiable queries for any stream’s state at any checkpoint—while validator bandwidth, memory, and computation remain O(k), independent of total stream IDs M.The requirements allow validator internal storage to grow by O(M) for a new stream.Source: §2.3 · p. 5

2.4 API and Correctness

  • Validators commit to each checkpoint’s stream updates, the ZK service advances a global stream commitment and returns states with proofs, and clients verify those proofs using validator keys.A state is correct at checkpoint c when it incorporates all updates to that stream through c and excludes later updates; Merkle operations verify, update, or insert leaves.Source: §2.4 · pp. 5–6

3 The Guppy protocols

Guppy shifts full-state Merkle-tree maintenance from validators to a recursive ZK service, while validators commit to stream updates. It develops Guppy-A and Guppy-B, with Guppy-B splitting proof generation into parallel, aggregation, and sequential phases.

3 The Guppy protocols

  • The ZK service maintains Merkle commitments to stream states and processes checkpoints in-circuit, enabling inclusion proofs for queries to any stream at any checkpoint.The Merkle tree supports efficient proofs while tracking all stream identifiers.Source: §3 · p. 6

3.1 Validator commitment

  • Validators batch stream updates, hash each batch, and chain the batch hashes from the previous checkpoint commitment into a header-included commitment.Batching enables parallel commitment generation and later parallel proof generation.Source: §3.1 · p. 6

3.2 A first attempt: Guppy-A

  • Guppy-A recursively verifies the previous proof and applies updates using Merkle paths, while avoiding validator signature verification inside the ZK circuit.Its cost is approximately r + N · h · (2d + 1 + 1/b) constraints.Source: §3.2 · pp. 7–8
  • For Guppy-A, accepted state queries are correct under signature unforgeability, hash collision resistance, and knowledge-soundness of the recursive ZK proofs.The result holds except with negligible probability.Source: §3.2 · p. 7
  • Guppy-A can batch checkpoints to amortize recursion costs, but batching sacrifices intermediate-checkpoint queries and each proof must finish before the next bundle arrives.Otherwise latency grows rapidly and the system stalls.Source: §3.2 · p. 8

3.3 Our main protocol: Guppy-B

  • Guppy-B subdivides bundles into β sub-bundles, proves them in parallel, combines proofs through an aggregation tree, then uses a cyclic proof to extend the previous sequential proof.Each aggregation circuit verifies proofs from the level below and checks that adjacent outputs match inputs.Source: §3.3 · pp. 8–10
  • With a fixed bundle slot, Guppy-B can process multiple checkpoints together if their updates fit within N and the sequential phase finishes within the slot.A slot length of at least 0.63 s avoids throughput caps, given the stated sequential-phase runtime.Source: §3.3 · p. 10
  • End-to-end latency is O(log_α(ρ)) in throughput because β grows with target throughput and aggregation has log_α(β) levels.The parallel phase is treated as O(1) when sub-bundles are proved simultaneously, and the sequential phase is constant-time.Source: §3.3 · p. 10

4 Implementation and Evaluation

Guppy-B sustains thousands of updates per second with latency growing sub-linearly as bundles grow, while validator-side commitment remains under 10 ms. Guppy-A handles smaller update rates, and its throughput depends on batching and proving interval.

4 Implementation and Evaluation

  • The Rust/Plonky2 evaluation ran on AWS, and one month of Sui measurements found an object-stream peak of 8,709.68 updates/s.The evaluation also measured an events-stream peak of 4,560.84 updates/s.Source: §4 · pp. 10–11
  • Circuit degree d = ceil(log2 g) indexes Plonky2 proving time, with degree 14 taking 0.627 s.Source: Table 1 · p. 11, §4 · p. 11

4.1 Validator overhead

  • Below 10 ms of validator overhead is achieved with batch size 50, while the largest measured Sui checkpoint contained 2,114 updates.Batch sizes of 10, 100, and 1,000 yielded 50,000, 49,890, and 49,876 gates for a base circuit processing 1,000 updates.Source: §4.1 · p. 11

4.2 Guppy-A

  • At M = 2^30, Guppy-A reaches about 294 updates/s with a 5.96 s proving interval, while shorter intervals offer finer query time granularity.Throughput peaks at an intermediate degree for M = 2^10 and M = 2^20; Guppy-A proof sizes range from 120 to 150 KB.Source: Figure 3 · p. 12, §4.2 · p. 12

4.3 Guppy-B

  • 2,250 updates/s at 4 s median latency was observed for Guppy-B with 1,800-update bundles on 14 machines.The measurements confirm sub-linear latency growth with bundle size.Source: Figure 4 · p. 13, §4.3 · p. 14
  • 8,571 updates/s at 3.15 s is predicted for Guppy-B with 5,400 updates and 41 machines; latency grows logarithmically with bundle size.The special configuration uses an aggregation tree whose levels increase with bundle size.Source: §4.3 · p. 13
  • Prover stages each take about 0.63 s across bundle sizes, while primary witness construction rises from 0.05 s at 200 updates to 0.18 s at 1,800.The measured throughput gap from the theoretical curve is attributed to the experiment's 0.8 s bundle interval rather than 0.63 s.Source: Figure 5 · p. 14, §4.3 · p. 14

5 Related work

Prior light-client designs generally rely on a state root in the header, while Guppy provides completeness when validators commit only to updates. Its off-chain service complements systems that assume a state root by producing one for chains that lack it.

5 Related work

  • Guppy provides light-client completeness on chains whose validators commit only to checkpoint updates, rather than the full state.The paper characterizes Guppy as the first design to do so.Source: §5 · p. 14
  • Header-chain compression and consensus-proof designs still read state through a header state root, which Sui and Solana do not publish.Fraud and data-availability approaches need an honest full node, while BITE and ZLiTE rely on trusted hardware.Source: §5 · p. 15
  • Sunfish uses the same validator-side hash-chain commitment, but obtains sub-state values by re-executing transactions and lacks succinct arbitrary-object inclusion proofs.Guppy adds an untrusted ZK service for full-state, per-checkpoint inclusion proofs.Source: §5 · p. 15
  • Verkle trees and other commitment schemes shrink proofs or aid maintenance, but state commitments remain on validators' critical path; high-throughput chains may omit state roots.Guppy fills that gap without putting the commitment back on validators.Source: §5 · p. 15
  • Co-processors and zkVM indexers consume an existing state root, whereas Guppy produces a root by proving tree updates from validator-signed effects without re-executing transactions.Source: §5 · p. 15
  • Unlike distributed provers that scale one large statement, Guppy-B exploits independent Merkle-tree updates in a natural tree of small circuits and off-the-shelf recursion.Mangrove and zkTree share the shape of Guppy-B's aggregation tree, while folding schemes remain an alternative when checkpoint-by-checkpoint proofs are unnecessary.Source: §5 · p. 16

6 Conclusion

Guppy shifts global state maintenance to an off-chain ZK service while validators commit only to per-checkpoint updates. Its prototype processes thousands of updates per second with a few seconds of latency, while the conclusion outlines scope boundaries and future directions.

6 Conclusion

  • Guppy shifts state maintenance off chain and has validators commit to per-checkpoint updates rather than the global state.The off-chain ZK service maintains global commitments; validators avoid the heavy costs of maintaining those commitments on chain.Source: §6 · p. 16
  • Thousands of state updates per second with a few seconds of end-to-end latency demonstrate Guppy’s prototype performance with negligible validator overhead.The design combines hash-chain commitments, recursive proofs, and a parallel proving pipeline; Guppy-B has logarithmic latency growth and can sustain arbitrarily high throughput given sufficient parallelism.Source: §6 · p. 16
  • Fixed-size circuits charge the ZK service for N updates per slot even when fewer updates occur.A circuit supporting multiple bundle sizes could allow per-slot sizing, but its efficiency remains future work.Source: §6 · p. 17
  • A fixed-set variant tracks only selected streams, reducing proving cost while retaining completeness for those streams.For that variant, the Merkle-tree commitment is replaced with a simple hash over the tracked states.Source: §6 · p. 17
  • For event streams, validators need a new key-value store and operational support for state synchronization; object streams on Sui reuse existing storage.Whether the ZK service can also maintain per-stream state depends on the cost of updating those structures inside the circuit, which the paper leaves for future work.Source: §6 · p. 17

A Proof of Theorem 1

The appendix proves that accepted state queries are correct under stated cryptographic assumptions and specifies the Merkle operations and recursive circuits used by Guppy-A and Guppy-B.

A Proof of Theorem 1

  • An accepted query returns the correct stream value at checkpoint c under signature unforgeability, hash collision resistance, and proof-system knowledge soundness.The proof uses hybrid games; the final game binds the signed header, update sequence, and queried leaf to the committed root.Source: A Proof of Theorem 1 · pp. 21–22

B Formal statements

  • The formal appendix collects the Merkle-tree operations, Guppy-A circuit statement, proof-serving procedure, and Guppy-B cyclic-circuit statement.It supplements the material summarized in Section 2 and Sections 3.2 and 3.3.Source: B Formal statements · p. 22

B.1 Merkle-tree API

  • The Merkle API verifies leaf inclusion, verifies and updates a leaf along its path, and inserts a leaf at a specified index.The update operation returns the new root after changing the stream value.Source: §B.1 · p. 23

B.2 The Guppy-A circuit

  • For a bundle corresponding to one checkpoint, processing its updates computes the Merkle root after that checkpoint.Existing streams are updated along their Merkle paths, while new streams are inserted at the current index.Source: §B.2 · p. 23
  • Guppy-A’s circuit verifies the prior proof, applies a bundle’s updates to the Merkle tree, and checks the resulting root, stream count, and hash-chain commitment.Its parameters include tree depth, validator batch size, and the number of batches per circuit invocation.Source: §B.2 · pp. 23–24

B.4 The cyclic circuit of Guppy-B

  • Guppy-B’s cyclic circuit verifies the previous sequential proof and an aggregation proof for the next checkpoint.The sequential proof’s public inputs carry the state root, update commitment, stream count, and checkpoint number.Source: §B.4 · pp. 24–25

B.3 Serving and verifying proofs

Clients verify a state query using a Merkle path, a validator-signed checkpoint header, and a recursive proof. Guppy-Sparse adapts this process to a fixed, small set of stream identifiers.

B.3 Serving and verifying proofs

  • A client verifies a query by checking the Merkle path, confirming the signed header contains the matching update commitment and checkpoint, and verifying the recursive proof.The service returns the claimed value, recursive proof, checkpoint header, and Merkle path.Source: §B.3 · p. 24

C Guppy-Sparse

  • Guppy-Sparse tracks only a fixed, small set of stream identifiers when completeness is needed for selected streams and proving costs should be minimized.It commits to the tracked state with a simple hash rather than a Merkle tree.Source: C Guppy-Sparse · p. 25
  • The sparse circuit checks the prior proof, applies checkpoint updates to tracked state, and outputs commitments to that state and the update chain.For small tracked sets, clients receive the full tracked-state list and can verify a query with constant-time verification.Source: C Guppy-Sparse · p. 25

D Evaluation details

The evaluation appendix collects measurements and derivations behind Section 4, including circuit sizing, machine requirements, and latency breakdowns.

D Evaluation details

  • Appendix D supplements Section 4 with measurements and derivations behind its reported numbers.Its topics include circuit sizes, Guppy-B machine requirements and special configurations, and per-prover end-to-end latency.Source: D Evaluation details · p. 25
  • Appendix D.1 gives circuit-size measurements and derivations underlying Section 4’s batch and sub-bundle parameters; Table 3 reports base-circuit size across batch sizes for processing 1,000 updates.Source: D Evaluation details · p. 25, Table 3 · p. 26
  • Table 3 compares base-circuit sizes across batch sizes while holding the processed workload at 1,000 updates.The workload is the product of batch size and number of batches.Source: Table 3 · p. 26

D.1 Circuit sizes

Circuit sizing informs two configuration choices: batch size can prioritize validator convenience, while the largest supported sub-bundle fixes the special configuration’s sub-bundle size.

D.1 Circuit sizes

  • Table 4 reports the maximum sub-bundle size handled by Guppy-B’s base circuit at each Plonky2 degree.The table tests increments of fifty with M = 230 and b = 50.Source: Table 4 · p. 26
  • Because batch size b barely changes base-circuit size, validators can choose it for convenience.Source: §D.1 · p. 26
  • The per-degree maximum in Table 4 fixes sub-bundle size y for the special configuration.Source: §D.1 · p. 26, Table 4 · p. 26

D.2 Number of machines for Guppy-B

Guppy-B parameter selection balances latency against throughput and machine constraints; the tested special configuration performed best among explored choices, but is not claimed to be globally optimal.

D.2 Number of machines for Guppy-B

  • The special configuration performed best among tested choices, but the authors do not claim global optimality.Source: §D.2 · p. 26
  • For a target throughput, which fixes bundle size N, parameter selection seeks batch size, sub-bundle size, and aggregation factor that minimize end-to-end latency.Source: §D.2 · p. 26
  • With a cap on machines instead, the dual objective is to maximize sustainable throughput.Systematic exploration of this design space is left to future work.Source: §D.2 · p. 26

D.3 Latency breakdown

Guppy-B’s prover latency remains about 0.63 seconds across the tested bundle sizes, while measured end-to-end differences can reflect additional overheads.

D.3 Latency breakdown

  • About 0.63 s is the median latency of each prover for bundle sizes N = 200, N = 600, and N = 1,800.Figure 5 breaks down prover latency across those bundle sizes.Source: §D.3 · p. 26
  • Table 5 reports throughput and machine counts for fully utilized bundles, using the largest N in each row.Source: Table 5 · p. 27
  • The partial witness builder’s latency grows slightly with worker count and bundle size, but remains low.Source: §D.3 · p. 27
  • Prover latency is invariant in worker count, so predicted-versus-measured end-to-end differences can reflect network, queuing, context-switching, or witness-assembly overheads.Source: §D.3 · p. 27
Loading 2609.07963v2…