Practical Light Clients for Committee-Based Blockchains

TL;DR

It is shown that most light clients are rarely offline for more than a week, validators are unlikely to drastically change in most permissioned blockchains and in a number of permissionless blockchains, such as Cosmos and Polkadot, and a novel practical system is proposed that achieves minimal communication and computational costs for light clients when compared to existing protocols.

Abstract

Light clients are gaining increasing attention in the literature since they obviate the need for users to set up dedicated blockchain full nodes. While the literature features a number of light client instantiations, most light client protocols optimize for long offline phases and implicitly assume that the block headers to be verified are signed by highly dynamic validators. In this paper, we show that (i) most light clients are rarely offline for more than a week, and (ii) validators are unlikely to drastically change in most permissioned blockchains and in a number of permissionless blockchains, such as Cosmos and Polkadot. Motivated by these findings, we propose a novel practical system that optimizes for such realistic assumptions and achieves minimal communication and computational costs for light clients when compared to existing protocols. By means of a prototype implementation of our solution, we show that our protocol achieves a reduction by up to $90$ and $40000\times$ (respectively) in end-to-end latency and up to $1000$ and $10000\times$ (respectively) smaller proof size when compared to two state-of-the-art light client instantiations from the literature.

Figures (6)

• Figure 1: Overview of our setup (see \ref{['sec:blockchains']}).
• Figure 2: Empirical cumulative distribution function of measurements of $m$ in Bitcoin. We include the data used to create this plot in Table \ref{['tab:cum']} in the Appendix.
• Figure 3: Maximum size of static validator subsets over a two-week period. Absolute values are indicated in red. We include the data used to create this plot in Table \ref{['tab:quorumsize']} in the Appendix.
• Figure 4: Light client protocol for an update from epoch $\textsf{e1}$ to the current epoch $\textsf{e2}$.
• Figure 5: Evaluation results of our solution when compared to SV, PoPoS popos and CSSV cssv in our implementation setup. Also note that the PoPoS code crashed for values of $m>2^{18}$. We, therefore, had to extrapolate the PoPoS latencies corresponding to $m=2^{19}$ and $m=2^{20}$.

Theorems & Definitions (9)

• Definition 1
• Proposition 1
• proof
• Proposition 2
• proof
• Definition 2: Transitive Multi-Signature
• Proposition 3
• proof
• proof