Forward the Original Title‘TeleportDAO：数据验证安全与效率之弈 —— 轻节点设计最新实践’

TL;DR

TeleportDAO and Eigen Labs recently jointly published a paper focusing on the security and efficiency challenges faced by light nodes when accessing and verifying on-chain data in proof-of-stake (PoS) blockchains. This paper proposes a new solution to ensure the security and efficiency of light nodes in PoS blockchains through a series of measures such as economic incentives and insured pre-security mechanisms, as well as customized “programmable security” and cost-effectiveness. It is very forward-looking and worthy of in-depth study.

Note: Eigen Labs is the developer behind the Restaking protocols EigenLayer and EigenDA. Eigen Labs has currently raised more than 150 million US dollars from well-known venture capital institutions such as a16z, Polychain, and Blockchain Capital.

TeleportDAO is located in Vancouver, Canada. It is a cross-chain communication infrastructure project focusing on the Bitcoin and EVM public chains. The protocol has successfully raised $9 million in a round of public sales and financing through Coinlist. This round of financing received participation from multiple investors including Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across and bitSmiley.

Existing Problems in Light Node Design

Currently, in PoS blockchains, validators participate in the consensus network by locking a certain amount of stake (such as 32 ETH in Ethereum) to ensure network security. Therefore, the essence of PoS blockchain security is protected by economics, that is, the larger the total stake, the greater the cost or loss required to attack the consensus network. The implementation of this slashing mechanism relies on a feature called “accountability safety”, that is, if the validator signs a conflicting state, the stake can be slashed.

Full nodes play a vital role in maintaining the integrity of the PoS blockchain. They store all block transaction information, verify consensus signatures, replicate a complete copy of transaction history, and perform state updates. These processes require a lot of computing resources and complex hardware. For example, running a full Ethereum node requires at least 2 TB of SSD storage. In contrast, light nodes reduce computing resource requirements and only store block headers, so they are only suitable for scenarios where specific transactions/statuses are verified, such as mobile wallets and cross-chain bridges. In addition, light nodes rely on full nodes to provide block information when verifying transactions, but the current market share of node service providers is relatively concentrated, so security, independence and immediacy cannot be fully guaranteed. Therefore, this paper explores the trade-off between data acquisition cost and latency for light nodes to achieve optimal security.

Existing Light Node Design Solutions

Bitcoin introduced Simple Payment Verification (SPV) as its light node protocol. SPV enables light nodes to use Merkle Proof and block headers to verify whether a transaction is included in a specific block. Therefore, light nodes only need to download the block header of the blockchain to verify the finality of the transaction by checking the depth of the block. In this case, the computational cost of verifying consensus by light nodes in Bitcoin is relatively low. However, in PoS blockchains such as Ethereum, the design of consensus checking is inherently more complex. It involves maintaining the entire set of validators, tracking their stake changes, and performing many signature checks for the consensus network. On the other hand, the security of PoW light nodes relies on the assumption that most full nodes are honest. To address the limitations of SPV, FlyClient and Non-Interactive Proof of Work (NiPoPoW) prove these blocks to clients at a sublinear cost. However, their applicability to the PoS consensus model is weak.

In contrast, PoS blockchains gain security through slashing mechanisms. The system relies on consensus participants being rational and not attacking the network if the cost of an attack exceeds any potential profit. To reduce verification costs, Ethereum’s current light node protocol relies on a sync committee consisting of 512 randomly selected Ethereum validators, each of which stakes 32 Ethereum, but the signing process will not be fined. This unslashable design has a major security flaw, and dishonest signatures in the synchronization committee can mislead light nodes into accepting invalid data without being punished. Even with the introduction of slashing mechanisms, the total stake of the Sync Committee is still small compared to the huge Ethereum validator pool (as of March 2024, the number of Ethereum validators has exceeded 1 million). Therefore, this approach cannot provide light nodes with security equivalent to the Ethereum validator set. This model represents a special variant of multi-party computation in a rational setting, but fails to provide economic-based guarantees or address the threats posed by malicious, irrational data providers.

To address the security and efficiency challenges in the PoS bootstrap process, PoPoS introduces a segmentation game to effectively challenge the adversarial Merkle tree of PoS timing. While they achieve minimal footprint and avoid requiring clients to always be online and staked, the problem of enabling clients to go offline without incurring significant costs to rejoin the network remains unsolved.

Another research approach focuses on using zero-knowledge proofs to create concise proofs. For example, Mina and Plumo effectively facilitate lightweight consensus verification by using recursive SNARK composition and SNARK-based state transition proofs. However, these approaches impose a considerable computational burden on block producers to generate proofs, and they do not address the issue of compensating light nodes for potential losses. In the context of other PoS protocols, such as the Tendermint protocol used in Cosmos, the role of light nodes is explored in their Inter-Blockchain Communication (IBC) protocol. However, these implementations are specific to their respective ecosystems and are not directly applicable to Ethereum or various other PoS blockchains.

New Light Node Design

Generally speaking, the new solution introduces an economic security module to achieve “programmable security”, and light nodes can decide on different solution designs based on their own security needs. The security assumption is basically 1/N + 1/M, that is, as long as there is an honest and valid node in the full node and the prosecutor network, the normal operation of the network can be guaranteed.

Related Modules/Roles

• Blockchain: The protocol is built on a programmable blockchain, and the rules for finalizing blocks are deterministic. For example, on the Ethereum blockchain, the finalization of a block requires at least two subsequent epochs, which usually takes about 13 minutes.
• Slashing Smart Contract: The protocol includes an on-chain slashing contract that conforms to the standard smart contract abstraction. It has access to the block hash of the previous block in the blockchain. All parties can send messages to this contract.
• Data Providers: Data providers run full nodes and track the latest state of the blockchain. They pledge assets and provide services to verify the validity of the state requested by light nodes. They sign all data sent to light nodes with the secret key corresponding to their public key, thereby verifying the source and integrity of the data.
• Prosecutors: Prosecutors are full nodes connected to light nodes to assist in data verification. Anyone can become a prosecutor and profit by monitoring and slashing parties that behave improperly. For simplicity, the following scheme assumes that each light node is connected to at least one honest prosecutor.
• Light Node: A light node verifies whether a specific state/transaction is included in the blockchain at the lowest cost. During the verification process, the light node connects with a group of data providers and prosecutors.
• Network: Data providers form a peer-to-peer (p2p) network and use the Gossip protocol to disseminate data. Light nodes connect to some data providers to send requests and receive responses.

Option 1: Security First

Option 1 mainly achieves data credibility through the introduction of a challenge period and a prosecutor network. Simply put, after the light node receives the data signed by the provider, it sends this part of the data to the prosecutor network for review. Within a certain period, if there is data fraud, the prosecutor will remind the light node that the data is not credible, and the penalty module of the smart contract will penalize the provider’s pledged tokens. Conversely, the light node can trust the credibility of these data.

Specific process of light node requesting data:

1. The light node obtains the latest list of data providers from the current network and determines a challenge period. It is worth noting that this challenge period is independent among different light nodes, but the challenge period upper limit applies to all light nodes. The challenge period is the longest time for the prosecutor network to check data credibility, so the longer the time, the longer the delay per transaction.
2. After obtaining the list, the light node will select a group of data providers and ensure that their respective staked funds are greater than the value of the current transaction. Theoretically, the higher the staked funds, the higher the cost of data provider’s misconduct, and the lower the trust cost of the light node.
3. The light node sends the corresponding data request to this group of data providers, which includes the corresponding block number and the target state (the inclusion proof of this transaction).
4. The data provider sends the corresponding block hash and the inclusion proof of the transaction, and attaches a signature.
5. After the light node receives the above-mentioned materials, it forwards them to the current connected prosecutor network. If no data credibility warning is received after the challenge period ends, the light node will verify this signature and pass the data credibility test if there is no error.

1. But if a warning is received from the prosecutor network, the light node needs to discard the signature received earlier. The prosecutor network will submit the relevant proof to the penalty module of the smart contract. If the smart contract finds that the misconduct indeed occurred after checking the data, the stake of the corresponding data provider will be penalized. Since part/all of the selected data providers have been penalized, the light node needs to re-obtain a new batch of data provider lists from the current network to confirm the slashing event has indeed occurred.

Other points:

• Any full node can join or leave the data provider network by initiating “registration” and “withdrawal” requests to the smart contract. There is a minimum staking threshold for registering to participate in the data provider network. Once a full node chooses to initiate a withdrawal, their status in the network will immediately change to “leaving”, and they can no longer receive requests from light nodes, to prevent potential malicious behavior of rapid entry and exit. In addition, the data provider network updates the list of currently active data providers in cycles, during which data providers cannot receive withdrawal funds. A withdrawal request will take effect in the last block of the current update cycle, and the update frequency will be higher than the challenge period limit to ensure that all light node data availability tests have been completed. Due to the activity of the data provider network, light nodes need to re-obtain the list of currently active providers every time the network is updated. If the update cycle is extended, light nodes can enjoy a more streamlined verification process (by estimating the current active list through the “registration” and “withdrawal” requests of the previous cycle), but nodes that wish to leave will face a longer waiting time.
• Upon receipt of the data signature, the prosecutor network checks whether the signature belongs to the data provider and assesses if the data has been “finally confirmed” in the consensus network. If the data does not appear on a reasonable chain, there are two possibilities. First, the data has not yet been finally confirmed by the current blockchain, different chains have different finality rules, such as the longest chain principle. Second, the transaction is in a block of another reasonable chain. If the above data is found to be falsified, the prosecutor network will send a slashing request to the smart contract, which includes the data provider’s public key, data provider’s signature, block number, and at the same time sends a proof of the slashing event to remind the light node. Upon receipt of this data, the smart contract measures whether the current block number finally confirmed is consistent with the received data according to the finality principle of the consensus layer. If they are inconsistent, then the slashing event is triggered. Further, if a data provider chosen by the light node is slashed because of another group of data requests, the prosecutor network will promptly send the slashing event to remind the light node that the data provider’s data credibility is low, and the light node will then re-obtain the list and select other providers.

Evaluate:

• Security: The light node determines the cost of malicious behavior for rational and irrational data providers through the staking module and the prosecutor network, enhancing the credibility of data. However, since the entire protocol is based on the consensus network (this paper tests on Ethereum), once the consensus layer is attacked, the protocol may also face a potential trust crisis. Therefore, a reputation mechanism can be further introduced to ensure systemic risk in extreme situations.
• Full Node-Level Security: This scheme aims to provide security equivalent to Ethereum’s PoS assumption, that is, full nodes need to bear slashing risk for making false statements.
• Network Activity: If the current network only has a few rational data providers, the light node will face multiple rounds of delay, but since each data provider’s throughput is not zero, every request will always be completed. Therefore, as long as the network has one rational full node, it can ensure the network can continue to operate. At the same time, as the income of data providers is linked to the amount of staking, this also encourages full nodes to protect the network by staking more than required.
• Efficiency: The article’s author team predicts that Ethereum validators are the main users participating in data providers, as validators are already running full nodes and can gain additional income through this protocol. Small transactions may get credible data through a single data provider (the light node only needs to verify once), while large transactions may need multiple data providers to get credible data (the number of verifications increases linearly with the number of providers).

Option 2: Efficiency First

Solution 2 realizes rapid data confirmation by proposing an insurance mechanism based on Solution 1. In simple terms, after the light node determines the insurance according to the policy amount and duration, part/all of the pledge of the data provider can be reimbursed for the subsequent losses of the light node due to data malice. Therefore, after the light node receives and verifies the data signature provided by the provider, it can determine the initial credibility of the data.

Specific process of light node requesting data:

1. The light node calculates the maximum potential loss of the current transaction, and then sets the insurance policy amount and insurance period. The amount of funds pledged by the data provider for insurance should be greater than the insurance policy amount to ensure sufficient repayment funds.
2. The light node determines the challenge period for the transaction. It is worth noting that the policy period can cover the inclusion checks of multiple transactions, so the total challenge period selected by the light node cannot exceed the policy period, otherwise some transactions may not be covered.
3. After selecting the parameters (policy amount, policy term, amount of funds pledged by the data provider for insurance, list of intended data providers), the light node can send a request to the smart contract. Then, after waiting for the final confirmation time of the block, it can verify whether the insurance purchase is successful. If it fails, it may be because other light nodes have also selected the data provider and settled first, so the remaining pledge is not enough to match his original demand.
4. The light node sends a data request, which includes the insurance number in addition to the block number and the target state (inclusion proof of the transaction).
5. The data provider sends the data and signature, the light node verifies the signature and forwards it to the prosecutor network, and then the transaction has been preliminarily confirmed.
6. After receiving the data and signature, the prosecutor will initially verify the credibility of the data. If there is any malicious behavior, the prosecutor will submit the proof to the smart contract and impose a fine on the corresponding data provider, which will be distributed to the light nodes.

Other points:

• The data provider’s staked insurance tokens are independent of each other between different light node requests to prevent the risk of multiple insurance repayments. After the light node selects the data provider, the smart contract will lock the corresponding tokens pledged for insurance, and other light nodes will not be able to allocate this part of the pledge before the end of the insurance period. If the transactions are independent, the insurance amount is the same as the maximum transaction amount. Otherwise, the insurance amount is the same as the total transaction amount. Under the same pledge amount, light nodes generally choose as few data providers as possible to ensure verification efficiency.
• Although the data provider can initiate a “withdrawal” request before the end of the insurance period, the withdrawal amount will only be received after the end of the insurance period.
• Strictly speaking, the insurance policy period should be greater than the final block confirmation time + total challenge period + communication delay + calculation/verification delay. The more data providers you choose, the longer the insurance policy period will be based on the total challenge period.

Evaluate:

• Scalability: The scalability of Option 2 is determined by the total amount of tokens that data providers are willing to stake for insurance.
• Policy Cost: Because higher security levels are linked to the challenge cycle, this means that the data provider must stake for a period greater than or equal to the challenge cycle. Therefore, the higher the security requirements, the longer the stake cycle, and the higher the fee paid by the light node. According to the formula, the data provider’s stake cost is calculated by the data provider’s node income/(average stake utilization throughout the year multiplied by the total number of blocks per year). The price that the light node needs to pay is the stake cost multiplied by the policy period and policy size.

Solution Effectiveness

First, in terms of light node computing efficiency, both light node solutions demonstrate millisecond-level verification efficiency (light nodes only need to verify the data once).

Second, in terms of light node latency, in different scenarios of experimental configuration (see the figure below), the latency is at the millisecond level. It is worth noting that the latency increases linearly with the number of data providers, but the latency is always at the millisecond level. In addition, in Solution 1, since 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 latency can also be significantly reduced.

Third, in terms of light node costs, in reality, there are two costs for light nodes: gas fee and insurance premium, both of which will increase as the insurance policy amount increases. In addition, for inspectors, the gas involved in submitting data will be repaid with the fine amount to ensure sufficient participation incentives.

Extension Direction

• More Collateral: Currently, the token staked by data providers is ETH, but transaction information is calculated based on the U standard, which means that light nodes need to measure the exchange rate of ETH every time they obtain data to ensure that the amount of collateral is high enough. If multiple tokens are allowed to be staked, data providers can have more staking options, thus avoiding the risk exposure of a single currency.
• Authorization: Similar to joint mining, some retail investors can participate in the data provider network by authorizing their own ETH to the full node, and the profits are distributed according to their own agreement. Please refer to LSD.
• Block Guarantee: In order to avoid waiting for the final confirmation period (12-13 seconds in Ethereum), light nodes can use a guarantee to reduce this waiting time. The light node will first add a symbol/identification when requesting data and determine what kind of guarantee is required (final confirmation/proposed). The data provider provides the corresponding data and signature after receiving the request. When the data provider does not have a proposed block under the “proposed guarantee” situation, they will be fined. \
  \
  Note: Proposed blocks will eventually be finalized or become uncle blocks.
• Cost and Fees: For the prosecutor network, they need to stake a certain amount of tokens (greater than gas) to submit proofs to the smart contract. In addition, the cost of this part of the proof can be reduced through the zkp method. In addition, under the insurance mechanism, the premiums submitted by the light nodes will be given to the data providers, while the prosecutor network will extract part of the penalty income from the malicious providers.
• Data Availability: Data providers are essentially full nodes. In addition to participating in the consensus layer network, they can also verify data availability. There are two types of schemes for verifying availability: Pull model and Push model. The former refers to the light node randomly extracting data obtained from the full node. The latter refers to the block producer distributing different blocks to data providers. For data providers that adopt the Pull model, they are responsible for returning sampling requests. After receiving the data, the light node forwards it to the trusted node/validator, and they try to restore the block. If they fail, the data provider will be fined. The light node protocol in this article proposes an insurance mechanism on this basis, providing a new exploration direction for data availability research.

Conclusion and Assessment

The light node solution proposed in this article provides “programmable security” to meet the security requirements in different situations. Option 1 trades higher latency for high security, while Option 2 provides “instant confirmation” services for light nodes by introducing an insurance mechanism. These solutions can be used in scenarios where the finality of transactions needs to be confirmed, such as atomic transactions and cross-chain.

Disclaimer：

1. This article is reprinted from [Eureka Partners]. Forward the Original Title‘TeleportDAO：数据验证安全与效率之弈 —— 轻节点设计最新实践’. 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.