Table of Contents
Fetching ...

Light Clients for Lazy Blockchains

Ertem Nusret Tas, David Tse, Lei Yang, Dionysis Zindros

TL;DR

This work tackles the challenge of enabling light clients for lazy blockchains, where consensus does not verify execution. It introduces a bisection-based protocol over augmented dirty ledgers, implemented as a dirty tree and Merkle Mountain Range, to locate the first disagreement between honest and adversarial full nodes and to verify state via fraud proofs and execution proofs. The protocol achieves succinct verification with $O(\log r)$-scale communication per round and $O(n)$-scale tournaments across $n$ provers, supported by formal completeness, soundness, and succinctness arguments; empirical results show light clients can synchronize across global full nodes in seconds while downloading orders of magnitude less data than full nodes. The approach is compatible with existing lazy blockchains and can be composed with superlight consensus oracles (e.g., FlyClient/NIPoPoWs) to yield polylogarithmic communication in $r$ overall, providing a practical path to scalable, secure light clients for lazy ledgers.

Abstract

Lazy blockchains decouple consensus from transaction verification and execution to increase throughput. Although they can contain invalid transactions (e.g., double spends) as a result, these can easily be filtered out by full nodes that check if there have been previous conflicting transactions. However, creating light (SPV) clients that do not see the whole transaction history becomes a challenge: A record of a transaction on the chain does not necessarily entail transaction confirmation. In this paper, we devise a protocol that enables the creation of efficient light clients for lazy blockchains. The number of interaction rounds and the communication complexity of our protocol are logarithmic in the blockchain execution time. Our construction is based on a bisection game that traverses the Merkle tree containing the ledger of all - valid or invalid - transactions. We prove that our proof system is succinct, complete and sound, and empirically demonstrate the feasibility of our scheme.

Light Clients for Lazy Blockchains

TL;DR

This work tackles the challenge of enabling light clients for lazy blockchains, where consensus does not verify execution. It introduces a bisection-based protocol over augmented dirty ledgers, implemented as a dirty tree and Merkle Mountain Range, to locate the first disagreement between honest and adversarial full nodes and to verify state via fraud proofs and execution proofs. The protocol achieves succinct verification with -scale communication per round and -scale tournaments across provers, supported by formal completeness, soundness, and succinctness arguments; empirical results show light clients can synchronize across global full nodes in seconds while downloading orders of magnitude less data than full nodes. The approach is compatible with existing lazy blockchains and can be composed with superlight consensus oracles (e.g., FlyClient/NIPoPoWs) to yield polylogarithmic communication in overall, providing a practical path to scalable, secure light clients for lazy ledgers.

Abstract

Lazy blockchains decouple consensus from transaction verification and execution to increase throughput. Although they can contain invalid transactions (e.g., double spends) as a result, these can easily be filtered out by full nodes that check if there have been previous conflicting transactions. However, creating light (SPV) clients that do not see the whole transaction history becomes a challenge: A record of a transaction on the chain does not necessarily entail transaction confirmation. In this paper, we devise a protocol that enables the creation of efficient light clients for lazy blockchains. The number of interaction rounds and the communication complexity of our protocol are logarithmic in the blockchain execution time. Our construction is based on a bisection game that traverses the Merkle tree containing the ledger of all - valid or invalid - transactions. We prove that our proof system is succinct, complete and sound, and empirically demonstrate the feasibility of our scheme.
Paper Structure (28 sections, 21 theorems, 9 equations, 6 figures, 2 tables, 6 algorithms)

This paper contains 28 sections, 21 theorems, 9 equations, 6 figures, 2 tables, 6 algorithms.

Key Result

lemma thmcounterlemma

The challenge game invoked at round $r$ with sizes $\ell_1$ and $\ell_2>\ell_1$ ends in $\mathcal{O}(\log(\ell_1))$ rounds of communication and has, considered in isolation, a total communication complexity of $\mathcal{O}(\log r)$.

Figures (6)

  • Figure 1: Bisection Game. Charlie the challenger helps the light client iteratively traverse the tree of Eve the evil responder. A green node indicates a match, while a red node indicates a mismatch, between the two dirty trees.
  • Figure 2: The challenger's MMR (top) is compared to the responder's alleged MMR. The first two peaks (A in blue) are the same, so they are skipped by Alg. \ref{['alg.peaks.vs.peaks']}. The second peak of the challenger is reached (B in purple) and compared against the responder's second peak (C). When found to be different, the challenger knows that the remaining responder peaks (in black, bottom) will lie within his own current tree (B, in purple); so Alg. \ref{['alg.peaks.vs.peaks']} Line \ref{['alg.peaks.vs.peaks.subtree']} calls Alg. \ref{['alg.challenger.tree.vs.peak']} to compare the black peaks against the purple tree.
  • Figure 3: In (a) and (b), we measure the time to complete a tournament of 17 geo-distributed provers. Error bars show the standard deviation. Solid lines show the trend. (a) Time when varying the tree degree $m$. (b) Time when varying the ledger size $L$. (c) Throughput of games with two provers and one verifier co-located in a data center. The verifier initiates games with variable parallelism to saturate the provers.
  • Figure 4: The alg. ran by the verifier to determine the winner of the bisection game.
  • Figure 5: Optimal Merkle tree degree $m$ (isolines) for a given network connection bandwidth (x-axis, in Mbps) and latency (y-axis, in ms). The $\times$ marker marks the particular example described in the text.
  • ...and 1 more figures

Theorems & Definitions (47)

  • definition thmcounterdefinition: Well-formed Ledgers, Trees and MMRs
  • definition thmcounterdefinition: State Security
  • lemma thmcounterlemma: Succinctness (Informal)
  • theorem thmcountertheorem: Completeness (Informal)
  • theorem thmcountertheorem: Soundness (Informal)
  • theorem thmcountertheorem: Tournament Runtime (Informal)
  • theorem thmcountertheorem: Security (Informal)
  • definition thmcounterdefinition: Ledger Safety
  • definition thmcounterdefinition: Ledger Liveness
  • definition thmcounterdefinition: Ledger Lipschitz
  • ...and 37 more