Light Nodes: Balancing Cost and Data Integrity in Blockchain Accessibility

Table of Links

Abstract and I. Introduction

II. Expectations of Blockchain Accessibility

III. Approach I: Maintain a Ledger Locally - Run a Full Node

IV. Approach II: Query a Third-Party Ledger-Node-As-A-Service (NAAS)

V. Approach III: Light Node - External Query & Local Verification

VI. Concluding Remark and References

V. APPROACH III: LIGHT NODE - EXTERNAL QUERY & LOCAL VERIFICATION

With the cost of running a full node continuously rising, the Ethereum community is seeking to develop a solution that can ensure data integrity and reduce system requirements. The result is the light node [23]: A light node is a server that only synchronizes limited information (such as block headers) with the blockchain network instead of block contents. When a light node encounters an RPC query, it pulls related contents from the blockchain network, verifies the contents with the synchronized information, and sends the result back to the client (see Fig. 4).

Traditionally, a light node synchronizes all block headers with the network and pulls related blocks to answer the query when it receives one. However, the recent innovation of ultralight nodes, such as Flyclient [10], allows a light node to synchronize less data with the blockchain but still be able to verify data related to the query, provided that some node in the blockchain network is willing to compute a piece of proof for the correctness of the data.

When the required data on the blockchain is very specific and limited, like when the users only care about one address that they own, specific light nodes, in the form of wallet software, are also available to the users. For zero-knowledgebased blockchains (such as Zcash [21] and Monero [14]), the wallet software can synchronize with the blockchains by downloading and analyzing blocks one by one to extract all transactions related to the address, without actually storing the blocks. These specific light nodes can be much more efficient for new blockchain users because they only care about blocks that come after the creation of the address, so they do not have to analyze any data before the creation time.

There are also many studies on universal light nodes in the research area, but few have been deployed to real-world blockchains [12]. Some notable examples in active development include Flyclient [10] and IBC [30]. A light node is expected to ensure data integrity because it can check the block contents with the node’s synchronized headers. However, a recent study shows that the security guarantee is weakened when the adversary controls the network [44].

A. The Case of Ethereum

We notice that support for light nodes is minimal as of 2022 for Ethereum, one of the most popular blockchains [24]: there is only one execution client and no production-ready light clients on the consensus layer. The proper functioning of light nodes depends on their ability to pull blocks from full nodes in the network, but there is no incentive for full nodes to provide such service, and as a result, light nodes often fail to find peers.

Future development on light nodes focuses on allowing light nodes to relay information among themselves [22]: it is planned not to provide financial incentives for nodes, and the network is designed to work like BitTorrent and IPFS.

B. Open Questions

While significant engineering effort is still necessary before light clients become universal, there is still room for innovations to improve the client’s performance. A recent SoK paper has suggested privacy-preserving, efficient resynchronization after offline, and cross-chain interoperability as potential future research directions [12].

Based on the premise that proving some statement to be true is more difficult than proving it to be false, some recent study also focuses on fraud proof [1]. The idea is that the light node does not need to verify the information it receives to be true, but can simply ask a few full nodes to make sure that it is not false.

We also notice that no matter the design of the light client, if it needs a full node to serve as a proofer for additional efforts beyond simply broadcasting a block, then incentives might be necessary to ensure that the full node renders the service. Toward that end, we think that the light node mechanism may merge with the node-as-a-service providers, with the providers serving the light nodes in a way that ensures integrity. In this sense, light nodes may evolve as a way to a verifiable RPC protocol.