TL;DR

TeleportDAO and Eigen Labs recently published a paper focusing on the security and efficiency challenges faced by light nodes in Proof of Stake (PoS) blockchains when accessing and verifying on-chain data. The paper proposes a new solution to ensure the security and efficiency of light nodes in PoS blockchains through economic incentives, insured pre-security mechanisms, customizable “programmable security,” and cost-effectiveness. This innovative approach is worth further research. Note: Eigen Labs, the developer behind the Restaking protocol EigenLayer and EigenDA, has raised over $150 million from renowned venture capital firms such as a16z, Polychain, and Blockchain Capital. TeleportDAO, based in Vancouver, Canada, focuses on cross-chain communication infrastructure between Bitcoin and EVM public chains. The protocol successfully raised $9 million through a public sale on Coinlist, with investors including Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across, and bitSmiley.

Issues with Light Node Design

Currently, in PoS (Proof of Stake) blockchains, validators ensure network security by locking a certain amount of stake (like 32 ETH in Ethereum) to participate in the consensus network. This means that the security of PoS blockchains is economically safeguarded: the greater the total stake, the higher the cost or potential loss for anyone attempting to attack the network. This forfeiture mechanism depends on a feature known as “accountability security,” which allows for the forfeiture of a validator’s stake if they sign conflicting states. Full nodes are vital in maintaining the integrity of PoS blockchains. They store all transaction data, verify consensus signatures, maintain a complete transaction history, and execute state updates. These tasks demand significant computing resources and advanced hardware; for instance, running a full Ethereum node requires at least 2 TB of SSD storage. On the other hand, light nodes reduce computing resource demands by only storing block headers, making them suitable for verifying specific transactions/states in applications like mobile wallets and cross-chain bridges. However, light nodes depend on full nodes for block information during transaction verification. Currently, the market share of node service providers is quite concentrated, which compromises security, independence, and immediacy. This article explores solutions to balance data acquisition costs and latency to achieve optimal security for light nodes.

Existing Light Node Design Solutions

Bitcoin introduced Simple Payment Verification (SPV) as a protocol for light nodes. SPV allows light nodes to verify if a transaction is included in a specific block using Merkle Proof and block headers. This means light nodes only need to download the block headers to verify transaction finality by checking the block’s depth. Consequently, the computational cost for light node consensus verification in Bitcoin is relatively low. However, in PoS blockchains like Ethereum, consensus checks are inherently more complex. They involve maintaining the entire set of validators, tracking their stake changes, and performing numerous signature checks for the consensus network. Additionally, PoW light node security relies on the assumption that most full nodes are honest. To overcome SPV’s limitations, FlyClient and Non-Interactive Proofs of Proof-of-Work (NiPoPoW) offer sublinear cost proofs to clients. However, these methods are less effective for PoS consensus models.

In PoS blockchains, security is achieved through a forfeiture mechanism. This system assumes that consensus participants are rational, meaning they won’t attack the network if the cost exceeds any potential profit. To lower verification costs, Ethereum’s current light node protocol uses a sync committee of 512 randomly selected validators, each staking 32 ETH, but the signing process is not subject to forfeiture. This non-forfeiture design has major security flaws; dishonest signatures in the sync committee can mislead light nodes into accepting invalid data without any punishment. Even with a forfeiture mechanism, the total stake of the sync committee is small compared to the vast pool of Ethereum validators (over 1 million as of March 2024). Therefore, this method does not provide light nodes with security equivalent to the Ethereum validator set. This model is a special variant of multi-party computation under rational settings but lacks economic guarantees and fails to address threats from malicious, irrational data providers.

To tackle the security and efficiency challenges in the PoS bootstrapping process, PoPoS introduces a segmented game to effectively challenge the adversarial Merkle tree of PoS timing. While achieving minimal space requirements and avoiding the need for clients to always be online and maintain stakes, the issue of allowing clients to go offline and rejoin the network without incurring significant costs remains unresolved.

Another research approach uses zero-knowledge proofs to create concise proofs. For example, Mina and Plumo facilitate lightweight consensus verification using recursive SNARK combinations and SNARK-based state transition proofs. However, these methods impose significant computational burdens on block producers for generating proofs and do not address compensating light nodes for potential losses. In other PoS protocols (like the Tendermint protocol in Cosmos), the role of light nodes has been explored in their Inter-Blockchain Communication (IBC) protocol. But these implementations are tailored to their specific ecosystems and are not directly applicable to Ethereum or other PoS blockchains.

Design of a New Light Node Plan

In general, the new Plan incorporates an economic security module to achieve “programmable security,” enabling light nodes to choose different designs based on their specific security requirements. The security assumptions follow the 1/N + 1/M principle, which means that as long as there is at least one honest and effective node in both the full node network and the inspector network, the network can function properly.

Involved Modules/Roles

• Blockchain: The protocol is built on a programmable blockchain with defined rules for block finality. For example, on the Ethereum blockchain, a block is considered final after at least two subsequent epochs, usually taking about 13 minutes.
• Forfeiture Smart Contract: The protocol includes an on-chain forfeiture contract that follows standard smart contract abstractions. It can access the block hash of the previous block in the blockchain. All parties can send information to this contract.
• Data Providers: Data providers run full nodes and keep track of the blockchain’s latest state. They pledge assets and offer services to verify the validity of states requested by light nodes. They sign all data sent to light nodes with keys corresponding to their public keys, ensuring the data’s source and integrity.
• Inspectors: Inspectors are full nodes connected to light nodes that help verify data. Anyone can become an inspector and earn rewards by monitoring and penalizing misbehaving parties. For simplicity, the following plan assumes each light node is connected to at least one honest inspector.
• Light Nodes: Light nodes aim to verify whether a specific state/transaction is included in the blockchain at minimal cost. They connect to a group of data providers and inspectors during the verification process.
• Network: Data providers form a peer-to-peer (p2p) network and use the Gossip protocol to spread data. Light nodes connect to multiple data providers to send requests and receive responses.

Plan 1: Security First

Plan 1 focuses on ensuring data reliability through a challenge period and an inspector network. In simple terms, after a light node receives data signed by providers, it forwards this data to the inspector network for review. If any fraudulent data is detected within a specified period, the inspector will notify the light node that the data is unreliable, and the forfeiture module of the smart contract will confiscate the staked tokens from the data provider. Otherwise, the light node can trust the data’s reliability. The specific process for light nodes to request data is as follows:

1. Light nodes obtain the latest list of data providers from the current network and The light node retrieves the latest list of data providers from the current network and sets a challenge period. Note that the challenge periods are independent for each light node, but there is a maximum challenge period that applies to all light nodes. The challenge period is the maximum time the inspector network has to verify the data’s reliability, so the longer the period, the longer the delay for a single transaction.
2. After obtaining the list, the light node selects a group of data providers and ensures that their staked funds exceed the value of the current transaction. In theory, the higher the staked funds, the higher the cost for a data provider to act maliciously, and the lower the trust cost for the light node.
3. The light node sends a data request to this group of data providers, including the block number and the target state (the inclusion proof of the transaction).
4. The data providers respond with the hash of the corresponding block and the inclusion proof of the transaction, along with their signatures.
5. Upon receiving this information, the light node forwards it to the connected inspector network. If no data reliability warning is received by the end of the challenge period, the light node verifies the signatures and, if correct, confirms the data’s reliability.

1. However, if a warning is received from the inspector network, the light node must discard the previously received signatures. The inspector network will submit evidence to the smart contract’s forfeiture module. If the smart contract verifies that malicious activity occurred, the data provider’s stake will be forfeited. Since some or all of the selected data providers have been penalized, the light node needs to obtain a new list of data providers from the current network to confirm the forfeiture event.

Other points:

• Any full node can join or leave the data provider network by submitting “registration” and “withdrawal” requests to the smart contract. There is a minimum staking requirement to join the data provider network. Once a full node initiates a withdrawal, its status changes to “left,” and it will no longer receive requests from light nodes to prevent quick in-and-out malicious behavior. Additionally, the data provider network updates the list of active providers periodically. During this period, data providers cannot withdraw their funds, and withdrawal requests will take effect at the end of the current update period. The update frequency is higher than the maximum challenge period to ensure the completion of all light node data availability tests. Due to the network’s activity, light nodes need to obtain a new list of active providers at each update cycle. If the update cycle is extended, light nodes can enjoy a simpler verification process (by estimating the active list based on previous “registration” and “withdrawal” requests), but nodes wishing to leave will face a longer wait.
• When the inspector network receives data signatures, it checks whether the signatures belong to the data providers and whether the data has been “finally confirmed” in the consensus network. If the data does not appear on the valid chain, there are two possibilities. First, the data has not yet been finally confirmed by the blockchain, as different chains have different finality rules, like the longest chain principle. Second, the transaction is in a block on another valid chain. If the data is fraudulent, the inspector network will send a forfeiture request to the smart contract, including the data provider’s public key, signature, and block number, along with proof of the forfeiture event to alert the light node. The smart contract will use the consensus layer’s finality principles to compare the currently confirmed block number with the received data. If they do not match, the forfeiture event is triggered. Additionally, if a data provider is penalized for another set of data requests after being chosen by the light node, the inspector network will promptly notify the light node of the data provider’s lower reliability, prompting the light node to obtain a new list and select other providers.

Evaluate:

• Security: The light node uses the staking module and the inspector network to determine the cost of malicious actions for both rational and irrational data providers, thereby improving data reliability. However, since the entire protocol is based on the consensus network (tested on Ethereum in this paper), if the consensus layer is attacked, this protocol will also face a potential trust crisis. Therefore, a reputation mechanism can be introduced to ensure the system’s safety in extreme cases.
• Full-node level security: This solution aims to offer security assumptions equivalent to Ethereum’s PoS, meaning that full nodes must bear the forfeiture risk if they make false statements.
• Network activity: If the current network has only a few rational data providers, the light node will experience multiple rounds of delays. However, since each data provider’s throughput is not zero, every request can still be completed. Therefore, as long as there is one rational full node in the network, it can continue to operate. Additionally, since data providers’ income is linked to their staking amount, this encourages full nodes to over-stake to protect the network.
• Efficiency: The authors estimate that Ethereum validators will be the main users participating as data providers because they are already running full nodes and can earn additional income through this protocol. Small transactions might obtain reliable data from a single data provider (only needing one verification for the light node), while large transactions may require multiple data providers to obtain reliable data (the number of verifications increases linearly with the number of providers).

Plan 2: Prioritize efficiency

Plan 2 builds on Plan One by introducing an insurance mechanism for rapid data confirmation. In simple terms, after the light node determines the insurance based on the policy amount and duration, part or all of the data provider’s stake can be used to compensate for any subsequent losses incurred by the light node due to malicious data. This allows the light node to establish the initial credibility of the data as soon as it receives and verifies the data signature from the provider. The specific process for the light node to request data is as follows:

1. The light node calculates the potential maximum loss of the current transaction and then sets the policy amount and duration. The funds staked by the data provider in the insurance should exceed the policy amount to ensure sufficient compensation.
2. The light node determines the challenge period for the transaction. It is important to note that the policy period can cover the inclusion check of multiple transactions, so the total challenge period chosen by the light node cannot exceed the policy period; otherwise, some transactions may not be guaranteed.
3. After selecting the parameters (policy amount, policy period, the amount of funds staked by the data provider in the insurance, and the list of data provider intentions), the light node sends a request to the smart contract. After waiting for the block’s final confirmation time, it verifies whether the insurance purchase was successful. If it fails, it may be because other light nodes also chose the same data provider and settled first, resulting in insufficient remaining stakes to meet the original demand.
4. The light node sends a data request, which includes the block number, the target state (the inclusion proof of the transaction), and the insurance number.
5. The data provider sends the data and signature, which the light node verifies and forwards to the inspector network. The transaction is then preliminarily confirmed.
6. Upon receiving the data and signature, the inspector initially verifies the data’s credibility. If malicious behavior is detected, proof is submitted to the smart contract, and the corresponding data provider is penalized, with the penalty distributed to the light node.

Other points:

• The tokens staked by data providers in the insurance are independent for different light node requests to prevent the risk of multiple insurance repayments. Once a light node selects a data provider, the smart contract locks the corresponding staked tokens in the insurance, and other light nodes cannot allocate this stake until the policy period ends. If transactions are independent, the policy amount equals the maximum transaction amount. If transactions are not independent, the policy amount equals the total transaction amount. Given the same staked amount, light nodes will generally choose as few data providers as possible to ensure verification efficiency.
• Data providers can initiate a “withdrawal” request before the insurance period ends, but the withdrawal amount will only be received after the policy period ends.
• Strictly speaking, the policy period should be longer than the block’s final confirmation time + total challenge period + communication delay + computation/verification delay. The more data providers selected, the longer the policy period required based on the total challenge period.

Evaluation:

• Scalability: The scalability of Plan Two depends on the total amount of tokens that data providers are willing to stake in the insurance.
• Policy Cost: Since higher security levels are linked to the challenge period, data providers must stake for a time equal to or longer than the challenge period. Thus, higher security requirements lead to longer staking periods and higher costs for the light node. In formula terms, the staking cost for data providers is calculated as the data provider node revenue / (average annual staking utilization multiplied by the total number of blocks per year). The price that the light node has to pay is the staking cost multiplied by the policy period and policy size.

Plan Effectiveness

First, regarding light node computation efficiency, both plans for light nodes show millisecond-level verification efficiency (light nodes only need to verify the data once). Second, concerning light node latency, under different experimental configurations (as shown in the figure below), the latency is also at the millisecond level. It’s important to note that latency increases linearly with the number of data providers but always remains at the millisecond level. Additionally, in Plan One, because the light node needs to wait for the challenge period results, the latency is 5 hours. If the inspector network is reliable and efficient enough, this 5-hour delay can be greatly reduced.

Third, in terms of light node costs, in practice, light nodes incur two main costs: gas fees and insurance premiums, both of which increase with the policy amount. Additionally, for inspectors, the gas fees involved in submitting data will be reimbursed by the forfeited amount to ensure sufficient participation incentives.

Expansion Directions

• More Collateral: Currently, data providers stake ETH tokens, but transaction information is calculated in USD terms. This requires light nodes to assess the ETH exchange rate each time they obtain data to ensure sufficient collateral. Allowing multiple tokens for staking would give data providers more options and reduce the risk associated with a single currency.
• Authorization: Similar to joint mining, some retail investors can authorize their ETH to full nodes to participate in the data provider network, with earnings distributed according to their agreements, similar to LSD.
• Block Guarantee: To avoid the final confirmation period wait (12-13 seconds on Ethereum), light nodes can use a guarantee to reduce this waiting time. Light nodes add a symbol/identifier when making data requests and specify the type of guarantee needed (final confirmation/Proposed). Data providers then provide the corresponding data and signature upon receiving the request. If data providers fail to propose blocks under the “Proposed Guarantee” scenario, they will be penalized.

Note: Proposed blocks will eventually be finalized or become uncle blocks.

• Costs and Fees: For the inspector network, they need to stake a certain amount of tokens (greater than the gas fee) to submit proofs to the smart contract. Additionally, using Zero-Knowledge Proofs (ZKP) can reduce the costs associated with these proofs. Under the insurance mechanism, the premiums paid by light nodes go to data providers, while the inspector network takes a portion of the forfeited earnings from malicious providers.
• Data Availability: Data providers are essentially full nodes. Besides participating in the consensus layer network, they can also verify data availability. There are two schemes for verifying availability: the Pull model and the Push model. The Pull model involves light nodes randomly sampling data from full nodes. The Push model involves block producers distributing different blocks to data providers. Data providers using the Pull model are responsible for responding to sampling requests. Light nodes forward the received data to trusted nodes/validators, who attempt to reconstruct the block. If they cannot, the data provider will be penalized. The light node protocol proposed in this paper introduces an insurance mechanism, providing a new direction for data availability research.

Summary and Evaluation

The light node scheme proposed in this paper offers “programmable security” to address security needs in various situations. Scheme One prioritizes higher security at the cost of increased latency, whereas Scheme Two uses an insurance mechanism to offer light nodes “instant confirmation” services. These schemes are applicable in scenarios that require transaction finality, such as atomic transactions and cross-chain transactions.

Disclaimer：

1. This article is reprinted from [Eureka Partners]. All copyrights belong to the original author [Andy、Arthur]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.