Paper 2019/226

Flyclient: Super-Light Clients for Cryptocurrencies

Benedikt Bünz and Lucianna Kiffer and Loi Luu and Mahdi Zamani

Abstract

To validate transactions, cryptocurrencies such as Bitcoin and Ethereum require nodes to verify that a blockchain is valid. This entails downloading and verifying all blocks, taking hours and requiring gigabytes of bandwidth and storage. Hence, clients with limited resources cannot verify transactions independently without trusting full nodes. Bitcoin and Ethereum offer light clients known as simplified payment verification (SPV) clients, that can verify the chain by downloading only the block headers. Unfortunately, the storage and bandwidth requirements of SPV clients still increase linearly with the chain length. For example, as of July 2019, an SPV client in Ethereum needs to download and store about 4 GB of data. Recently, Kiayias et al. proposed a solution known as non-interactive proofs of proof-of-work (NIPoPoW) that allows a light client to download and store only a polylogarithmic number of block headers in expectation. Unfortunately, NIPoPoWs are succinct only as long as no adversary influences the honest chain, and can only be used in chains with fixed block difficulty, contrary to most cryptocurrencies which adjust block difficulty frequently according to the network hashrate. We introduce Flyclient, a novel transaction verification light client for chains of variable difficulty. Flyclient is efficient both asymptotically and practically and requires downloading only a logarithmic number of block headers while storing only a single block header between executions. Using an optimal probabilistic block sampling protocol and Merkle Mountain Range (MMR) commitments, Flyclient overcomes the limitations of NIPoPoWs and generates shorter proofs over all measured parameters. In Ethereum, Flyclient achieves a synchronization proof size of less than 500 KB which is roughly 6,600x smaller than SPV proofs. We finally discuss how Flyclient can be deployed with minimal changes to the existing cryptocurrencies via an uncontentious velvet fork.

Note: Major rewrite. Proofs for variable difficulty.