Unconditionally Safe Light Client

TL;DR

This work tackles secure, low-resource light clients for Proof-of-Stake blockchains by formalizing cryptoeconomic security and introducing programmable, insurer-enabled security. It presents two protocols, LC_eco with economic security and LC_ins with insured security, to balance latency, cost, and robustness. The authors implement and evaluate a Solidity/TypeScript stack on a testnet, showing concrete trade-offs such as latency versus insurance cost and establishing scalability under realistic assumptions. The approach enables application-specific light clients that can achieve near-full-node trust with tunable security and financial protections, broadening practical use cases like wallets and cross-chain bridges.

Abstract

Blockchain applications often rely on lightweight clients to access and verify on-chain data efficiently without the need to run a resource-intensive full node. These light clients must maintain robust security to protect the blockchain's integrity for users of applications built upon it, achieving this with minimal resources and without significant latency. Moreover, different applications have varying security needs. This work focuses on addressing these two key requirements in the context of Proof-of-Stake (PoS) blockchains and identifying the fundamental cost-latency trade-offs to achieve tailored, optimal security for each light client. The key security guarantee of PoS blockchains is economic (implied by the "stake"). In this paper we formalize this cryptoeconomic security to light clients, ensuring that the cost of corrupting the data provided to light clients must outweigh the potential profit, thereby economically deterring malicious actors. We further introduce "insured" cryptoeconomic security to light clients, providing unconditional protection via the attribution of adversarial actions and the consequent slashing of stakes. The divisible and fungible nature of stake facilitates programmable security, allowing for customization of the security level and insurance amount according to the specific needs of different applications. We implemented the protocols in less than 1000 lines of Solidity and TypeScript code and evaluated their gas cost, latency, and the computational overhead. For example, for a transaction with value of \$32k, the light client can choose between zero cost with a latency of 5 hours or instant confirmation with an insurance cost of \$7.45. Thus, the client can select the optimal point on the latency-cost trade-off spectrum that best aligns with its needs. Light clients require negligible storage and face minimal computational costs,...

Figures (7)

• Figure 1: Insurance cost vs. Transaction size (or covered value) for different insurance duration
• Figure 2: System participants and their interactions.
• Figure 3: The normal path for economic security. We have simplified this example, by supposing the light client has chosen only one data provider. Also, we only show the honest watcher here.
• Figure 4: The dispute resolution path for economic security. This simplified example assumes the light client has selected a single data provider and depicts only the honest watcher.
• Figure 5: This diagram illustrates the blockchain's growth and details the process by which a data provider exits the protocol.