DLT Interoperability and More ⛓️#4 ⛓️ — SoK: Blockchain Light Clients

In this series, we analyze papers on blockchain and interoperability (and both).

This edition covers a paper from 2021 on light clients

Photo by Irina Krutova on Unsplash

➡️ Title:SoK: Blockchain Light Clients
➡️ Authors: Panagiotis Chatzigiannis, Foteini Baldimtsi, and Konstantinos Chalkias

➡️ Contributions:

• the authors systematize the research area of blockchain light clients

➡️ Introduction to the area:

• Anyone participating in a blockchain protocol can run a full node by downloading all the blockchain, and by re-executing every transaction since its inception. This is typically a very lengthy, time-consuming, and resource-consuming process, considering that Ethereum takes around 700 Gigabytes. Some ideas tackle this problem, for example, the usage of snapshots to efficiently bootstrap new nodes onto Hyperledger Fabric networks.
• Light clients need to synchronize with full nodes to work.
• Several solutions exist to allow someone to participate on the network (reads and writes), keeping desirable security properties, instead of downloading the whole chain. Each light client, depending on its implementation (coming with different functionalities and security models) should be able to verify on-chain facts as a core feature.
• Security properties light clients should provide. 1) “Secure querying: After bootstrapping, a malicious adversary A should not be able to convince a light client C to accept a forged transaction or account state”, 2) “Secure bootstrapping and synchronizing: This property implies that given a publicly known genesis block B1, an adversarial full node A should not be able to convince an honest client C to accept a forged blockchain state B∗ (for any B∗) and therefore accept queries on it.”
• Many different implementations exist, which is the study object of this survey.

💪 Strong points:

• The authors detail what are the features a light client should offer as a basis: the ability to perform queries and hold secret information. Queries are for instance retrieving a certain state of the blockchain and should come with verifiability guarantees (this is, accompanied by a cryptographic proof accounting for the validity of communicated state). Hold secrets refers to private keys that the light client uses to submit transactions to the blockchain (this is, it has a wallet).
• The paper talks about the main light client implementations, with reference to the underlying architectures of the blockchains they are connected to.
• The paper provides very interesting insights about specific light client implementations (see Points of interest)

😞 Limitations:

• This paper misses on previous important work on blockchain interoperability that also tackles light clients
• Under “Basic light client assumptions.”, seems like the authors take for granted the security of light clients, e.g., “Reliable consensus (i.e. safety and liveness).”, “Weak synchrony, i.e. no long network partitions. We do not consider Eclipse network-level attacks.”, which is not always the case.

🔥 Points of interest:

• The first light client is known as Simplified Payment Verification (SPV). SPV operates on the Bitcoin network. In our survey on blockchain interoperability, we also talk about how SPV works. However, SPV “introduced additional trust assumptions and attack vectors, as in many implementations all communication and queries are executed through a small set of servers”.
• “The trade-off however for the efficiency of such [light] 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 [29]”
• Ethereum 2.0 wants to introduce “sync committees” to help minimize bootstrapping costs of light clients: nodes that hold block headers instead of the whole blockchain.
• “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 [27] (i.e. the client also needs the voters’ balances for each block”
• “IBC has explicit light client support tailored to its consensus algorithm [42], which only requires to download block headers after a trusted period, which contain sufficient validator signatures proving the correctness of validator evolution up to that period. State proofs are then provided to light clients through a full node.”
• Different techniques to design light clients: 1) Header Verification and Consensus Evolution, 2) Compressing the State, 3) Removing the State, and 4) Leveraging Game-theoretic Assumptions
• “Overall, aggregate signatures, already used by Plumo, is a promising primitive towards light client implementations, as it is estimated to save a significant portion of the needed bandwidth and storage. Another potential option is for the validators to engage in some interactive protocol in advance as part of the consensus committee protocol, using threshold signatures”
• “No light client approach or implementation explicitly considers frequent offline phases, where the client needs to re-sync with the current system state.” — this means there is some research to be done on the liveness (and also safety) of light client implementations, due to having to rely on the availability and honesty of the full nodes.
• The price to implement light clients as smart contracts is the finalization latency of the blockchain running the smart contract, gas fees associated to the light client operation, and the lack of security research.
• “Interoperability: Ideally, light clients should be implemented as a smart contract without the use of trusted oracles. This would allow for verifying transactions of a blockchain A inside a contract of blockchain B.” and “Implementing reasonably efficient light clients inside smart contracts might be impractical for many non-zero-knowledge proof friendly blockchains or ledgers without succinct fraud-proof in optimistic settings”

🚀 How does it relate to our work at Técnico Lisboa, INESC-ID, and Blockdaemon? (views are my own and do not necessarily reflect the opinions of my employer)

• Blockdaemon provides a comprehensive offer of full nodes that can support light nodes deployed in the industry.
• It would be interesting to see how could sync committees be used to create efficient Ethereum 2.0 light clients, allowing interoperability of blockchain A <-> Ethereum 2.0 with verifiable security (provided by this sync committee).

🚀 What are the implications for our work?

• Light clients have the potential to improve not only the decentralization of a network (depending on its implementation) but also blockchain interoperability, as it allows providing factual information to a blockchain on what happened on a second blockchain.