pith. sign in

arxiv: 2604.26736 · v1 · submitted 2026-04-29 · 💻 cs.CR

Catching the Fly: Practical Challenges in Making Blockchain FlyClient Real

Pericle Perazzo , Dario Capecchi This is my paper

Pith reviewed 2026-05-07 11:13 UTC · model grok-4.3

classification 💻 cs.CR
keywords FlyClientZcashblockchain verificationproof of worklightweight clientsadversary modelproof optimizations
0
0 comments X

The pith

An alternative adversary model and two optimizations enable the first practical FlyClient prover on Zcash.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper aims to close the gap between the theoretical FlyClient protocol and actual use on live blockchains by tackling implementation barriers. It defines a new adversary model that sets verifier parameters according to real economic costs to attackers and reduces the data required in proofs. The authors deliver the first working prover code for Zcash and measure its performance across different setups. They also test two optimizations that shrink proof sizes, one of which needs no change to the blockchain's consensus rules. If these steps succeed, resource-limited devices could perform secure proof-of-work checks without downloading full chain data.

Core claim

The paper claims that FlyClient becomes production-ready through an alternative adversary model that parametrizes the verifier under a concrete economic interpretation while saving proof space, the first practical prover implementation for the Zcash blockchain with performance estimates under varied configurations, and two optimizations that minimize proof sizes, one without requiring any consensus change.

What carries the argument

The alternative adversary model for FlyClient, which parametrizes the verifier with economic costs and reduces proof space, together with the prover implementation for Zcash.

If this is right

  • Verifiers can be configured using concrete economic costs rather than abstract security parameters.
  • Proof sizes decrease, supporting deployment on devices with limited storage and bandwidth.
  • Performance benchmarks under multiple configurations allow selection of suitable settings for different environments.
  • One optimization applies immediately without altering the underlying blockchain rules.
  • Lightweight verification becomes feasible for mobile wallets, IoT devices, and smart-contract bridges.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The prover code and optimizations could be ported to other proof-of-work chains with similar data structures.
  • Economic parametrization may allow dynamic tuning of security levels based on current attack costs in cross-chain systems.
  • Real network tests could reveal latency or bandwidth effects not captured in the controlled evaluations.
  • The size-reduction techniques might apply to other light-client protocols that rely on sampling.

Load-bearing premise

The alternative adversary model accurately reflects the economic incentives facing real attackers on the blockchain.

What would settle it

Executing the implemented prover on the live Zcash network and directly measuring actual proof generation times, sizes, and verification costs against the reported estimates would confirm or refute the practical performance results.

Figures

Figures reproduced from arXiv: 2604.26736 by Dario Capecchi, Pericle Perazzo.

Figure 1
Figure 1. Figure 1: Example of MMR constructed over a blockchain. view at source ↗
Figure 2
Figure 2. Figure 2: Optimal c ∗ for interactive and non-interactive proofs, varying the blockchain length and the adversarial block budget. (0.2161, 231) for the non-interactive one. This configuration results in an interactive proof of 423 samplings and a non￾interactive one of 504 samplings (-37% saving). Considering that each Zcash header is 1,487 bytes if represented in bi￾nary format, the wa-adversary parametrization dec… view at source ↗
Figure 3
Figure 3. Figure 3: Database upgrade time. keep the HistoryTree of the tip header up to date. Therefore, FlyClient capability does not introduce sensitive degradation with respect to the sync time. If a legacy instance with an old database format gets upgraded, it takes about 10 hours to upgrade the database to the new format with a chain of about 3M blocks, while a full sync requires almost 40 hours. It can be seen from the … view at source ↗
Figure 4
Figure 4. Figure 4: shows our reference FlyClient verifier, described as pseudo-code that uses the aforementioned RPC functions. The FLYCLIENTVERIFIER function (Figure 4a) tests the trust￾worthiness of a set of verifiers P, starting from the one that declared the chain with the most work. The CHECKPROVER function (Figure 4b) tests a single prover p, by first performing ndet deterministic samplings (Lines 3–9) and then nprob p… view at source ↗
Figure 5
Figure 5. Figure 5: FlyClient proof size with respect to the proof representation. view at source ↗
Figure 7
Figure 7. Figure 7: FlyClient proof size with respect to the type of verifier. view at source ↗
Figure 9
Figure 9. Figure 9: Example of cumulative proof of ancestry. view at source ↗
Figure 10
Figure 10. Figure 10: FlyClient proof size under different optimizations. view at source ↗
read the original abstract

FlyClient is a lightweight blockchain verification protocol that enables proof-of-work validation using minimal data, making it ideal for resource-constrained environments like mobile wallets, Internet-of-Things devices or cross-chain bridges implemented with smart contracts. Despite its strong potential for enabling lightweight blockchain verification, FlyClient protocol is still in the experimental stages, with limited real-world deployments and performance evaluations under diverse conditions. In this paper we bridge the gap between theory and deployment, by addressing several technical challenges to advance FlyClient to a production-ready solution. Namely, our contribution is three-fold: (i) we formally introduce an adversary model alternative to the original FlyClient one, that allows us to parametrize a verifier under a concrete economic interpretation, while also saving some proof space; (ii) we provide the first practical FlyClient prover implementation for a production blockchain (Zcash), and we estimate its performance under different configurations; (iii) we introduce and evaluate two optimizations that minimize the size of FlyClient proofs, the first of which does not require any consensus change.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper claims to advance FlyClient from theory to production by (i) introducing an alternative adversary model that parametrizes the verifier via an economic interpretation while reducing proof space, (ii) delivering the first practical FlyClient prover implementation for the Zcash blockchain together with performance estimates under varying configurations, and (iii) proposing and evaluating two proof-size optimizations, one of which requires no consensus change.

Significance. If the alternative model preserves the original FlyClient security guarantees, the work supplies a concrete, reproducible implementation and performance data for a production blockchain; these are genuine strengths that move lightweight PoW verification closer to deployable use in mobile wallets, IoT devices, and cross-chain bridges. The non-consensus-change optimization is particularly valuable for adoption.

major comments (1)
  1. [§3] §3 (Alternative Adversary Model): the manuscript replaces the original FlyClient adversary with a new economic model that is claimed to preserve negligible probability of accepting an invalid chain under the same hash-rate assumptions, yet supplies no explicit security reduction, game equivalence, or counter-example analysis relating the two games. Because the security claims for the Zcash prover (contribution ii) and both optimizations (contribution iii) rest entirely on the new model, this gap is load-bearing.
minor comments (2)
  1. [Evaluation section] The performance tables would benefit from explicit error bars or confidence intervals on the reported proof-generation times and space savings.
  2. [§3] Notation for the economic parameters (e.g., the cost function used to set verifier thresholds) is introduced without a consolidated table of symbols.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive review and for recognizing the practical value of the Zcash implementation and the non-consensus optimization. We address the single major comment below.

read point-by-point responses

  1. Referee: [§3] §3 (Alternative Adversary Model): the manuscript replaces the original FlyClient adversary with a new economic model that is claimed to preserve negligible probability of accepting an invalid chain under the same hash-rate assumptions, yet supplies no explicit security reduction, game equivalence, or counter-example analysis relating the two games. Because the security claims for the Zcash prover (contribution ii) and both optimizations (contribution iii) rest entirely on the new model, this gap is load-bearing.

    Authors: We agree that the manuscript does not contain an explicit security reduction, game equivalence proof, or counter-example analysis relating the original FlyClient adversary game to the proposed economic model. The current §3 presents the economic model as an alternative that parametrizes the verifier via concrete costs and claims it yields a negligible acceptance probability for invalid chains under the same hash-rate bounds, but the argument remains informal. Because the security of the prover implementation and both proof-size optimizations depends on this model, the gap is indeed load-bearing. In the revised manuscript we will add a new subsection to §3 that (i) formally defines both games, (ii) provides a reduction showing that any adversary succeeding in the economic game with non-negligible probability can be used to break the original FlyClient game (up to a factor polynomial in the economic parameters), and (iii) discusses edge cases where the models may diverge. This revision will be completed before resubmission. revision: yes

Circularity Check

0 steps flagged

No significant circularity: implementation and evaluation paper with independent contributions

full rationale

The paper focuses on practical implementation of a FlyClient prover for Zcash, performance estimation under configurations, and two optimizations for proof size. No derivation chains, equations, or fitted parameters are described that reduce by construction to the paper's own inputs or prior self-citations. The alternative adversary model in contribution (i) is presented as a new formalization allowing economic parametrization and space savings, but without any self-referential definition, ansatz smuggling, or load-bearing self-citation that would make the result equivalent to its premises. The work is self-contained as an engineering effort building on the original FlyClient protocol with external benchmarks for evaluation.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities are described in the abstract; the work centers on implementation, performance estimation, and protocol optimizations rather than new theoretical constructs.

pith-pipeline@v0.9.0 · 5477 in / 991 out tokens · 77654 ms · 2026-05-07T11:13:10.874331+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    FlyClient: Super-light clients for cryptocurrencies,

    B. B ¨unz, L. Kiffer, L. Luu, and M. Zamani, “FlyClient: Super-light clients for cryptocurrencies,” in2020 IEEE Symposium on Security and Privacy (SP), 2020, pp. 928–946

    work page 2020

  2. [2]

    On the deployment of FlyClient as a velvet fork: chain-sewing attacks and countermeasures,

    T. Nemoz and A. Zamyatin, “On the deployment of FlyClient as a velvet fork: chain-sewing attacks and countermeasures,” Cryptology ePrint Archive, Paper 2021/782, 2021. [Online]. Available: https: //eprint.iacr.org/2021/782

    work page 2021

  3. [3]

    SmartFly: Fork-free super-light Ethereum Classic clients for Internet of Things,

    P. Perazzo and R. Xefraj, “SmartFly: Fork-free super-light Ethereum Classic clients for Internet of Things,”IEEE Internet of Things Journal, vol. 11, no. 9, pp. 15 348–15 358, 2024

    work page 2024

  4. [4]

    Zcash protocol specification,

    D.-E. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, “Zcash protocol specification,” Electric Coin Company, Tech. Rep., 2024, version 2024.5.1-112-gcf7a5c. [Online]. Available: https://caladex.io/api/files/ /papers/zcash%20white%20paper.pdf

    work page 2024

  5. [5]

    ZIP 221: FlyClient—consensus- layer changes,

    S. Bowe, D.-E. Hopwood, and J. Lee, “ZIP 221: FlyClient—consensus- layer changes,” https://zips.z.cash/zip-221, 2020, zcash Improvement Proposal

    work page 2020

  6. [6]

    Zebra: The zcash foundation’s full node implemen- tation of the zcash protocol,

    Zcash Foundation, “Zebra: The zcash foundation’s full node implemen- tation of the zcash protocol,” https://github.com/ZcashFoundation/zebra, 2026, zcash full node written in Rust; includeszebradnode binary and supporting crates

    work page 2026

  7. [7]

    The velvet path to superlight blockchain clients,

    A. Kiayias, A. Polydouri, and D. Zindros, “The velvet path to superlight blockchain clients,” inProceedings of the 3rd ACM Conference on Advances in Financial Technologies, ser. AFT ’21. New York, NY , USA: Association for Computing Machinery, 2021, p. 205–218. [Online]. Available: https://doi.org/10.1145/3479722.3480999

    work page doi:10.1145/3479722.3480999 2021

  8. [8]

    Proofs of proofs of work with sublinear complexity,

    A. Kiayias, N. Lamprou, and A.-P. Stouka, “Proofs of proofs of work with sublinear complexity,” inFinancial Cryptography and Data Security, J. Clark, S. Meiklejohn, P. Y . Ryan, D. Wallach, M. Brenner, and K. Rohloff, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2016, pp. 61–78

    work page 2016

  9. [9]

    Non-interactive proofs of proof- of-work,

    A. Kiayias, A. Miller, and D. Zindros, “Non-interactive proofs of proof- of-work,” inFinancial Cryptography and Data Security, J. Bonneau and N. Heninger, Eds. Cham: Springer International Publishing, 2020, pp. 505–522

    work page 2020

  10. [10]

    Coda: Decentralized cryptocurrency at scale,

    J. Bonneau, I. Meckler, V . Rao, and E. Shapiro, “Coda: Decentralized cryptocurrency at scale,” Cryptology ePrint Archive, Paper 2020/352,

    work page 2020

  11. [11]

    Available: https://eprint.iacr.org/2020/352

    [Online]. Available: https://eprint.iacr.org/2020/352

    work page 2020

  12. [12]

    Plumo: An ultralight blockchain client,

    P. Vesely, K. Gurkan, M. Straka, A. Gabizon, P. Jovanovic, G. Konstan- topoulos, A. Oines, M. Olszewski, and E. Tromer, “Plumo: An ultralight blockchain client,” inFinancial Cryptography and Data Security, I. Eyal and J. Garay, Eds. Cham: Springer International Publishing, 2022, pp. 597–614

    work page 2022

  13. [13]

    Merkle mountain range,

    P. Todd, “Merkle mountain range,” https://github.com/opentimestamps/ opentimestamps-server/blob/master/doc/merkle-mountain-range.md, 2016, original documentation describing the Merkle Mountain Range data structure

    work page 2016

  14. [14]

    How to prove yourself: Practical solutions to identification and signature problems,

    A. Fiat, Amosand Shamir, “How to prove yourself: Practical solutions to identification and signature problems,” inAdvances in Cryptology — CRYPTO’ 86, A. M. Odlyzko, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 1987, pp. 186–194

    work page 1987

  15. [15]

    EIP-7623: Increase calldata cost,

    Ethereum Foundation, “EIP-7623: Increase calldata cost,” https://eips. ethereum.org/EIPS/eip-7623, 2024, ethereum Improvement Proposal

    work page 2024

  16. [16]

    EIP-4844: Shard blob transactions (proto-danksharding),

    V . Buterin, D. Feist, D. Loerakker, G. Kadianakis, M. Gar- nett, and M. van der Wijden, “EIP-4844: Shard blob transactions (proto-danksharding),” https://eips.ethereum.org/EIPS/eip-4844, 2023, ethereum Improvement Proposal

    work page 2023

  17. [17]

    Argon2: The memory- hard function for password hashing and other applications,

    A. Biryukov, D. Dinu, and D. Khovratovich, “Argon2: The memory- hard function for password hashing and other applications,” in Proceedings of the 2016 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2016, pp. 292–302. [Online]. Available: https://eprint.iacr.org/2015/430

    work page 2016

  18. [18]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Wood, “Ethereum: A secure decentralised generalised trans- action ledger,” https://ethereum.github.io/yellowpaper/paper.pdf, 2014, ethereum Yellow Paper; describes the Ethash proof-of-work algorithm

    work page 2014