[Paper Review] Superlight -- A Permissionless, Light-client Only Blockchain with Self-Contained Proofs and BLS Signatures

Roman Blum, Thomas Bocek|arXiv (Cornell University)|Jan 8, 2019

Blockchain Technology Applications and Security7 references4 citations

TL;DR

Superlight proposes a permissionless, light-client-only blockchain that enables transaction verification using self-contained proofs (SCPs) and BLS signatures, allowing nodes to validate transactions with only block headers instead of the full blockchain. This reduces storage requirements significantly while maintaining security and decentralization, though at the cost of increased computational overhead from BLS signatures and perfect Bloom filters.

ABSTRACT

Blockchain protocols are based on a distributed database where stored data is guaranteed to be immutable. The requirement that all nodes have to maintain their own local copy of the database ensures security while consensus mechanisms help deciding which data gets added to the database and keep powerful adversaries from derailing the system. However, since the database that forms the foundation of a blockchain is a continuously growing list of blocks, scalability is an inherent problem of this technology. Some public blockchains need a few 100 GB to Terabytes of storage. In this work, we present the concept Superlight with self-contained proofs, which is designed to improve scalability of a public blockchain, while preserving security and decentralization. Instead of all nodes having a local copy of the whole blockchain to verify a transaction, nodes can derive the validity of a transaction by only using block headers. To keep the block headers compact, BLS signatures are used to combine signatures. We provide a definition of SCPs and show the required steps of a client to create a proof that is accepted by other nodes for transferring funds. The advantage of such a light-client-only blockchain is the lower storage requirement, while the drawback is an increased computational complexity due to BLS signatures, limited use-cases due to lack of a global state, and the requirement for an interactive protocol between sender, receiver, and miner to create a transaction.

Motivation & Objective

• To address the scalability limitations of public blockchains caused by the need for full-node storage of growing blockchain data.
• To enable a permissionless blockchain where all participants can operate as lightweight clients, reducing per-node storage requirements.
• To design a system where transaction validity can be verified using only block headers and self-contained proofs, eliminating the need for full blockchain history.
• To evaluate the trade-offs between reduced storage and increased computational cost due to BLS signatures and perfect Bloom filters.

Proposed method

• The system uses self-contained proofs (SCPs) that bundle transaction validity proofs within each transaction, enabling verification using only block headers.
• BLS signatures are used to aggregate multiple signatures into a single compact signature, reducing block header size and enabling efficient verification.
• Perfect Bloom filters are constructed to represent all known addresses in the system, storing only the set of participating addresses to minimize header bloat.
• The block header includes the perfect Bloom filter, BLS signature aggregate, and a list of all known addresses, enabling light clients to validate transactions without full blockchain access.
• A mechanism is defined to compute a perfect Bloom filter by iteratively increasing its size until no false positives occur for non-participating addresses.
• The protocol assumes all clients store block headers and their own transaction data, including Merkle proofs, to reconstruct SCPs when needed.

Experimental results

Research questions

• RQ1 Can a blockchain be designed to operate solely with light clients, eliminating the need for full nodes while preserving security and decentralization?
• RQ2 How can transaction validity be proven using only block headers and minimal metadata, without requiring access to the full blockchain history?
• RQ3 What is the trade-off between storage reduction and computational cost when using BLS signatures and perfect Bloom filters in a blockchain context?
• RQ4 To what extent can block header size be reduced using perfect Bloom filters compared to storing addresses directly?
• RQ5 How does the system ensure that light clients can reconstruct valid proofs even after losing individual transactions or proofs?

Key findings

• The use of perfect Bloom filters reduces block header size significantly compared to storing all addresses directly, with tests showing a 3000-bit header size for 400 participating addresses out of 500 total addresses.
• BLS signatures allow for efficient aggregation of multiple signatures into a single compact signature, reducing the size of proof components in block headers.
• The computational cost of generating perfect Bloom filters increases with the number of participating addresses, but the method ensures no false positives for non-participating addresses.
• The system enables full transaction verification using only block headers and self-contained proofs, allowing all nodes to act as light clients and reducing per-node storage requirements.
• A key limitation is that if a client loses a transaction or its Merkle proof, it can no longer generate valid self-contained proofs, risking permanent loss of funds.
• The approach requires a hard fork to deploy on existing blockchains due to changes in data structure, cryptographic mechanisms, and consensus protocols.