Part1Introduction

Blockchain-based, systems such as Bitcoin and Ethereum, typically include three types of participants: consensus nodes (also known as miners or validators), who run a consensus protocol to reach a common agreement on the current blockchain state, full nodes who store and communicate blockchain data, and clients which submit queries or transactions. Full nodes are considered to have relatively sufficient resources to perform their tasks, which involve communicating with each other through a gossip protocol in a peer-to-peer fashion, storing and communicating unconfirmed transactions, maintaining the entire blockchain history and replying to queries. To perform transactions (e.g. in cryptocurrencies such as Bitcoin and Ethereum), clients first need to verify that the underlying blockchain is valid. Naively, this implies downloading and verifying all blocks, an operation that could take hours or days, and require gigabytes of bandwidth and storage. Therefore, the only remaining option for resource-constrained clients (such as mobile devices or browsers) is to place their trust on full nodes which will serve as intermediary servers, provide clients a view of the blockchain based on client queries, and forward submitted transactions on the client's behalf.

Nevertheless, in the early days of Bitcoin, the three roles mentioned were not necessarily distinct. For example, the Bitcoin core software served as a common frontend to solve the Proof of Work puzzle as part of the consensus protocol, run a full node and submit queries and transactions. However, it quickly became necessary to decouple the client functionality to ensure less powerful clients can interact with the system while preserving as many security guarantees possible, which was mainly done through the Simplified Payment Verification (SPV) protocol. Interestingly, while SPV required much less resources compared to a full node, it was still not lightweight enough to support resource-constrained environments with very low computational, storage and communication capabilities such as a mobile or browser-based client, while the introduction of more complex blockchain systems such as Ethereum made this gap even wider. In addition, SPV introduced additional trust assumptions and attack vectors, as all communication and queries are executed through a single server.

More recently, several implementations and academic works were proposed as "light clients" or "light-client friendly", either tailored to specific blockchain systems, or even as entirely new systems. However, every proposal provides different properties, definitions and goals for a light client, either implicitly or explicitly, while there are still many different interpretations for a "light client" in the blockchain space, even after a decade of evolution of cryptocurrencies. As a result, existing implementations approach the problem from a different angle, and no complete solution exists that makes a mobile client possible while maintaining all of the strong security guarantees of the underlying blockchain system.

In this paper, we unify the diverse conception of light clients in the blockchain world by providing definitions for light client properties in terms of functionalities, efficiency and security, and provide a common list of assumptions for such clients. Then, we provide a systematization of prominent existing works based on our defined properties. Finally, through our systematization, we provide a series of insights and gaps serving as exciting future research directions, including considerations regarding long range attacks due to validator re-configurations, and light clients for privacy preserving blockchains or as smart contracts to allow for native interoperability between independent ledgers.

1What is a Light Client?

We begin by providing an informal definition of a standard (non-light) client, which is the generic protocol that directly interacts with the blockchain system. This interaction includes at least one of the following functionalities:

• Perform queries (e.g. the balance of an account or the state of a transaction, with a specific time or block number as optional parameters). Such queries are typically accompanied by proofs verifiable by the client protocol (created by other entities in the system such as consensus participants or full nodes), in order to preserve security and prevent the client from being manipulated by malicious actors.

• Hold secret information (e.g. account private keys) and submit transactions to the blockchain system. This functionality is often referred to as a wallet.

Note that the terms clients and wallets are often considered equivalent and used interchangeably in the blockchain space, with the term "wallet" typically associated with a specific software implementation. However, based on the above informal definition, we make an explicit distinction between these terms: In a nutshell, a wallet is the software implementation of the client protocol that holds secret information used to submit transactions to the blockchain. As an example, Bitcoin Core  is Bitcoin's standard client which includes both wallet and full node functionalities, as discussed previously.

Starting again from the cryptocurrency community, a "light client" mostly refers to the wallet software running a "more" lightweight client implementation in its back-end compared to the standard client. This software usually interacts with the blockchain through a fully synchronized node, which in turn submits the transactions on the client's behalf (e.g. by placing them on a "mempool" and broadcasting them to other nodes and miners through a gossip protocol). The goal of such a client is to be more compatible with resource-constrained environments such as mobile devices or browsers, where the system's fully-fledged client might be prohibitive to work. Also, another goal of the light client might be to reduce the costs of the initial joining process, without requiring to download the full blockchain history (which for a standard client is typically in the order of gigabytes). The trade-off however for the efficiency of such clients is usually security; for instance they might need to trust the full node they are interacting with, they do not verify the consensus process, do not store and communicate ledger information themselves, and therefore do not contribute to decentralization, one of the blockchain's main goals.

However, in some implementations (e.g. Ethereum or Polkadot), a "light client" refers to a "lighter" version of a full node (i.e. with faster setup and synchronization time and lower computational/storage requirements), which only stores block headers but still directly interacts with the blockchain network in a peer-to-peer fashion, and therefore does not need to introduce all of the trust assumptions discussed above. However this type of client is still not suitable to run in very constrained environments such as mobile devices, and is still above the bar in terms of such requirements.

Towards the "light client" goal, some systems have adopted additional cryptographic primitives or techniques, for instance succinct proofs to maintain a "compact" representation of the blockchain with fast verification.

Based on the above, we can envision an "ideal" light client as a client having very low computation, storage, communication and initial setup requirements (making such a client feasible even in mobile devices or browsers). However, the light client should retain the security guarantees without introducing additional trust assumptions. Therefore, it still needs to act as the verifier of efficient cryptographic proofs, which will convince the client on the received query replies (e.g. on an account's balance or the state of a transaction). These proofs would be created by entities in the blockchain in the prover role (e.g. miners or full nodes), ideally without introducing a significant overhead.

2Light Client Implementations in Major Blockchain Systems

We now overview how a light client is perceived and implemented in prominent blockchain systems.

Bitcoin

As discussed previously, the earliest and most well known concept of light client is the Simplified Payment Verification (SPV) client in Bitcoin. An SPV light client only verifies the chain of Proof of Work solutions through the block headers, and requests Merkle proofs on-demand from a full node to verify if a specific transaction is valid (e.g. for transactions that are associated with a wallet address). This approach, while popular even by today's wallets, is not consistent with "decentralization", and introduces additional security assumptions as well as privacy concerns. Satoshi's whitepaper proposed "pruning" as a method to downsize the blockchain (and therefore make it practical for light clients) by discarding spent transaction outputs in each block. However, this method

• requires clients to make a full synchronization even before performing pruning, and

• as of today, it has not been implemented because of security concerns. We also note some early proposals to store Bitcoin's UTXO set in a Merkle tree for fast bootstrapping.

Ethereum

Being an account-based system, Ethereum has the following three types of nodes:

• full nodes (most common), which cryptographically verify all account states at all times, but can prune account state tries older than 1024 blocks to save space.

• archival nodes, which always keep the full blockchain history without pruning, and

• light nodes which only store block headers to reduce resource requirements. Note that pruning can potentially hurt past transaction or account state querying (and therefore auditability) if there are no archival nodes available to provide a query reply along with a proof (e.g. a Merkle path). Also, Ethereum node software implementations include client and wallet functionalities, therefore the terms clients and nodes are used interchangeably.

In contrast with Bitcoin, there is no single node/client software implementation but several different open-source clients written in different programming languages. Geth, written in Go, is the most commonly used, and recently introduced a new "snapshot" functionality for full node synchronization in order to improve read disk access speeds, by including a "flattened" version of all account states as well. However, no Ethereum node/client is light-client friendly even in light mode . In practice, considering a Raspberry Pi 4 as a "light client" platform (which is still more powerful compared to mobile devices, especially in terms of energy resources), a geth full node with the new snapshot features can barely run on in, as it still needs a great amount of fast read-write disk storage (i.e at least 1TB SSD). A geth light node comes without that storage requirement but it still requires a slow, communication-intensive setup phase, which is also required when the node desynchronizes (e.g. in periods of power-off, sleep or disconnections) and is prone to database corruptions.

All Ethereum node types rely on an initial peer discovery algorithm based on the Kademlia Distributed Hash Table (DHT) protocol to connect to other nodes. This is in contrast with Bitcoin core software (the official standard node/client for Bitcoin), which relies on a hardcoded DNS list feed. Lastly, Ethereum plans to implement light clients in its Proof of Stake version (Ethereum 2.0 ) by introducing "sync committees" to help minimize bootstrapping costs, however at the time of writing, details for these committees have not yet been released.

Algorand

Implementing an SPV client in a Proof of Stake blockchain such as Algorand is not straightforward, since block headers are not enough to securely verify the chain (i.e. the client also needs the voters' balances for each block). Vault, a recent work approach based on Algorand's Proof of Stake protocol, "skips" blocks in each verification step, essentially compressing the block history, while also compressing the voter certificates themselves by using a smaller committee size, but requires a larger percentage of the committee members to vote in order to preserve the validity of the certificate.

Diem

Clients in Diem interact with the blockchain through a full node's JSON-RPC endpoint , however the client API at the time of writing simply provides answers to queries, without accompanying proofs to provide the client verification capabilities. A client with full verifying functionalities is work in progress, and a recent work includes a framework to make client implementations in Diem lightweight.

Mina

Mina inherently supports light clients (full-nodes) through recursive SNARK compositions, which enable maintaining a constant-sized (20KB) blockchain that can be efficiently verified by a client with limited resources. It utilizes a variant of Ouroboros proof-of-stake algorithm to preserve consensus security properties. However Mina, while being light-client oriented, still requires a heavy amount of work for the Block producers, who are in the prover role (its testnet has a 8-core processor and 16 GB of RAM as minimum requirements).

ZCash

ZIP 221 implements Flyclient, an efficient block header verification method for light clients. Based on Non-Interactive Proofs of Proof-of-Work (NIPoPoWs), it compresses blockchain transaction histories for light clients by only needing to download a small subset of all block headers, which correspond to blocks with higher difficulty target.

Cardano

Although Cardano currently has naive light client implementations that need to place their trust on a full node, it plans to utilize recent work (Mithril) to enable secure and fast boostrapping of light clients in Proof of Stake using a novel primitive, "stake-based threshold multisignatures".

Cosmos-InterBlockchain Communication (IBC)

Using the Tendermint BFT Proof of Stake consensus , Cosmos' InterBlockchain Communication (IBC) proposes a decentralized protocol for making blockchains communicate with each other, even when these ledgers have fundamentally different underlying architectures. IBC has explicit light client support tailored to its consensus algorithm, which only requires to download block headers after a trusted period, which contain sufficient validator signatures proving correctness of validator evolution up to that period. State proofs are then provided to light clients through a full node.

Binance

A light client in Binance chain, which uses a Proof of Stake consensus variant (Proof of Authority), is simply implemented by querying a full node, seemingly with a trust model that resembles SPV.

Part2Cryptographic Building Blocks

In this section we briefly discuss common cryptographic building blocks used by light clients.

3Succinct Set Representation and Proofs

• Cryptographic Accumulators enable a succinct and binding representation of a set of elements and support constant-size proofs of membership (or nonmembership) on . An accumulator typically consists of algorithms to add an element to it, create a membership proof that is contained in the accumulator, verify , and later update a proof to after an element has been added to the accumulator. Sub-categories of accumulators are defined if an accumulator manager is needed, if trapdoor information exists and if it supports additional operations like removing elements or creating proofs of non-membership. Merkle Trees are a specific construction of accumulators, where each element is represented in a tree of hashes.

• Vector commitments enable committing to a vector of elements , and later open the commitment at any position of the vector. While a VC might not be necessarily hiding as a standard commitment, it needs to be position binding instead of just binding.

• SNARKs (succinct non-interactive arguments of knowledge) are proof systems that are succinct (i.e. have very small proof size compared to that of the statement or the witness) and do not require interaction between the prover and the verifier. zk-SNARKs are a special type of SNARKS augmented with the zero-knowledge property, i.e. constructing a verifiable proof without revealing any information about the witness. In addition, zk-SNARK verification typically requires much less computation than constructing the proof itself.

4Hash Functions and Signatures

• Aggregate signatures are a special type of digital signatures, where from a set of users with each user having a signing keypair and a subset of signatures and corresponding messages , an aggregator can combine them into a single aggregate signature .

• Threshold signatures enable a subset of out of valid signers to generate a signature, but does not allow to create a valid signature with fewer than of those signers.

• Chameleon hashes  are collision-resistant hash functions, that have additional properties associated with public-private key pairs compared to standard hash functions. While anyone can compute the output of the chameleon hash function using the public key, the private key serves as trapdoor information to easily find collisions for a specific input.

Part3Definitions

5Light Client Properties

Given the plethora of light-client definitions and implementations that exist in the blockchain space, there is a need to unify and standardize their functional, efficiency and security properties. We informally discuss these properties below, assuming a blockchain which contains transactions and accounts , with participating light clients , consensus participants and full nodes . By we define the genesis block which we assume that holds all the system parameters and will be used for verifiable bootstrapping.

Functional properties

The system needs to support the following protocols which all run between a client and a set of full nodes who always keep as an input and serve as intermediaries:

• The client on input the genesis block , bootstraps/initializes its state st by running an interactive protocol with a full node and receives a proof of correct initialization.

• The client updates its state from st to st'  to reflect the newest view of via an interactive protocol with a full node.

• The client verifies that st is a correct transition from st or and outputs .

• st, data The client makes a query for data where data (e.g. timestamp or block height) or data acc (e.g. an account's address). We also assume that data includes the type of query, i.e. current balance of an account, sender/receiver/value of a transaction, etc. The client receives a reply and a proof . If data typically returns error , however optionally, it can still provide a proof of non-existence as .

• Vrfy (st, Client verifies for and outputs

• (optional wallet functionality): Submit a transaction to on behalf of acc with secret information sk.

Security properties

We list the required security properties that correspond to threats relevant to the operation of the light client.

• Secure bootstrapping and synchronizing: This property implies that given a publicly known genesis block , an adversarial full node should not be able to convince an honest client to accept a forged blockchain state (for any ) and therefore accept queries on it.

• Secure querying: After bootstrapping, a malicious adversary should not be able to convince a light client to accept a forged transaction or account state. For instance, the adversary should not be able to convince the client that an unverified or forged transaction exists in the blockchain or accept an incorrect account balance. Secure querying also includes the case where falsely convinces the that an accepted transaction or existing account is not part of the blockchain history (i.e. forged proof of non-existence), which is omitted for brevity from our definition.

Efficiency properties

We identify the following efficiency properties in terms of storage, computation and communication costs (|B| denotes blockchain size, or number of blocks). We focus on the operations that happen on the light client side.

• Efficient bootstrapping and synchronizing: Init() and Upd () computation and communication are sublinear to .

• Efficient storage: storage costs (i.e. state size) for light clients, is sublinear to .

• Efficient communication: and (if applicable) require communication costs sublinear to , where communication happens between and .

• Efficient client computation: and (if applicable) require client computation costs sublinear to

• requires computational costs sublinear to .

Overall, the overhead for B, CN and N in order to support light clients should be minimal compared to the equivalent system that does not provide such support. That said, the full nodes supporting the light clients, might already perform work linear to B.

6Underlying Assumptions

While the variety of light clients operate under different threat models and assumptions depending on the underlying system properties (i.e. PoW or PoS based consensus), we identify a set of common assumptions that we list below.

Basic light client assumptions

To the best of our knowledge, all light client designs implicitly make the following assumptions:

• Trusted genesis block

• Reliable consensus (i.e. safety and liveness).

• Secure underlying cryptographic primitives.

• Weak synchrony, i.e. no long network partitions. We do not consider Eclipse network level attacks.

Additional assumptions

Depending on their design, some systems impose additional assumptions.

• Trusted setup phase for the underlying cryptographic primitives (i.e. zkSNARKs setup).

• Network-level assumptions: we assume that a client receives and relays information in a peer-to-peer fashion (i.e. distributed networking). This is generally preferred over communicating with a single full node which could act maliciously by relaying a forged view of B to C or prevent it from completing Init() or Upd() (i.e. DoS attack).

• Game-theoretic assumptions, i.e. that participants behave in a rational model.

• Special assumptions e.g. fixed Proof of Work difficulty or certain blockchain participants performing specific operations (e.g. accounts needing to restore other accounts not included in the bootstrapped state).