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. Authors:
(1) Zhongtang Luo, Purdue University (luo401@purdue.edu);
(2) Rohan Murukutla, Supra (r.murukutla@supraoracles.com);
(3) Aniket Kate, Purdue University / Supra (aniket@purdue.edu). This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Expectations of Blockchain Accessibility II. Expectations of Blockchain Accessibility III. Approach I: Maintain a Ledger Locally - Run a Full Node III. Approach I: Maintain a Ledger Locally - Run a Full Node IV. Approach II: Query a Third-Party Ledger-Node-As-A-Service (NAAS) IV. Approach II: Query a Third-Party Ledger-Node-As-A-Service (NAAS) V. Approach III: Light Node - External Query & Local Verification V. Approach III: Light Node - External Query & Local Verification VI. Concluding Remark and References 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 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 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. Authors: (1) Zhongtang Luo, Purdue University (luo401@purdue.edu); (2) Rohan Murukutla, Supra (r.murukutla@supraoracles.com); (3) Aniket Kate, Purdue University / Supra (aniket@purdue.edu). Authors: Authors: (1) Zhongtang Luo, Purdue University (luo401@purdue.edu); (2) Rohan Murukutla, Supra (r.murukutla@supraoracles.com); (3) Aniket Kate, Purdue University / Supra (aniket@purdue.edu). This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Balancing Blockchain Access: Local Nodes vs. Third-Party Services

Navigating the Node-as-a-Service Market: Benefits, Risks, and Open Questions

Blockchainize.TECH

Too Long; Didn't Read

Make resilience your competitive advantage

Light Nodes: Balancing Cost and Data Integrity in Blockchain Accessibility

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Simplifying Blockchain: How Abstraction is Revolutionizing the Web3 Wallet Experience on Flow

The Human Factor In Blockchain Development: How It's Prevented Blockchain From Flourishing

Last Mile of Blockchains: RPC and Node-as-a-Service

Key Expectations for Blockchain Accessibility: Integrity, Availability, and Privacy

A Novel Pipeline for Classifying and Repairing Smart Contracts at Scale

Simplifying Blockchain: How Abstraction is Revolutionizing the Web3 Wallet Experience on Flow

The Human Factor In Blockchain Development: How It's Prevented Blockchain From Flourishing

Last Mile of Blockchains: RPC and Node-as-a-Service

Key Expectations for Blockchain Accessibility: Integrity, Availability, and Privacy

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps