TeleportDAO: The game between data verification security and efficiency, the latest practice of light node design

Author: Andy, Arthur

TL;DR

TeleportDAO and Eigen Labs recently published a paper focusing on the role of light nodes in Proof of Stake (PoS)BlockchainThe challenges faced when accessing and verifying on-chain dataSafetyand efficiency challenges. This paper proposes a new solution.Through financial incentives and insuredSafetymechanism, and customized "programmableSafety”A series of measures to ensure PoS BlockchainMedium and light nodesSafetyPerformance and efficiency. It is very forward-looking and worthy of further 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, located in Vancouver, Canada, is a cross-chain communication infrastructure project focusing on Bitcoin and EVM public chains. The protocol has successfully raised $9 million through a round of public sale and financing through Coinlist. This round of financing has been participated by many investors including Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across and bitSmiley.

Existing problems in light node design

Currently, in PoS Blockchain中，验证者通过锁定一定数量的质押（如以太坊中的 32 ETH）来参与共识网络，从而确保网络安全。因此，PoS Blockchain安全的本质是由经济保护的，即总质押越大，攻击共识网络所需的成本或损失就越大。执行这种罚没机制依赖于一种称为“问责安全”的功能，即如果验证者签署了相互冲突的状态，就可以罚没质押。

Full nodes play a vital role in maintaining the integrity of the PoS blockchain. They store all block transaction information, verify consensus signatures, make full copies of transaction history, and perform status 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 solid-state drive 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 terminals.walletand 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 article 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 a slashing mechanism. The system relies on consensus participants being rational, meaning they will not attack 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, which consists of 512 randomly selected Ethereum validators.Xiaobai NavigationEach validator stakes 32 Ethereum, but the signing process cannot be slashed. This non-slashable design has major security flaws, and dishonest signatures in the synchronization committee can mislead light nodes into accepting invalid data without being punished. Even with the introduction of the slashing mechanism, the total stake of the synchronization committee is still small compared to the huge pool of Ethereum validators (as of March 2024, the number of Ethereum validators has exceeded 1 million). Therefore, the security provided by this method for light nodes cannot be equivalent to the Ethereum validator set. This model represents a special variant of multi-party computation in a rational setting, but cannot 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. Although they achieve minimal space and avoid requiring clients to always be online and maintain stakes, the problem of enabling clients to go offline without incurring a large cost to rejoin the network remains unsolved.

Another research approach focuses on usingZero knowledge proofto 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 methods impose a considerable computational burden on block producers to generate proofs, and they do not address the issue of compensation for potential losses of light nodes. 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. But 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 design different solutions 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.

Involved 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.

• Confiscation Intelligencecontract：The protocol includes a standard smartcontract抽象的链上罚没contract。它可以访问区块链中前一个区块的区块哈希值。所有各方都可以向该合约发送信息。

• Data providers: Data providers run full nodes and track the latest state of the blockchain. They pledge their assets and provide services to verify the validity of the state requested by light nodes. They sign all data sent to light nodes with a 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 misbehave. For simplicity, the following scheme assumes that each light node is connected to at least one honest prosecutor.

• Light Node: Light nodes verify whether a specific state/transaction is included on the blockchain with minimal cost. Light nodes connect with a group of data providers and prosecutors during the verification process.

• Network: Data providers form a peer-to-peer (p2p) network and use the Gossip protocol to propagate data. Light nodes connect to some data providers to send requests and receive responses.

Solution 1: Safety first

Option 1 mainly achieves data credibility by proposing a challenge period and a prosecutor network.In simple terms, after receiving the data signed by the provider, the light node will send this part of the data to the prosecutor network for review. Within a period of time, if the data is falsified, the prosecutor will remind the light node that the data is unreliable, and the penalty module of the smart contract will confiscate the pledge of the data provider.Token,On the contrary, light nodes can trust the credibility of this 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 the challenge period is independent of each other for different light nodes, but the upper limit of the challenge period applies to all light nodes. The challenge period is the maximum time the prosecutor network uses to check the credibility of the data, so the longer the time, the longer the delay in single-transaction delivery.

2. After obtaining the list, the light node will select a group of data providers and ensure that their respective pledged funds are greater than the value of the current transaction. In theory, the higher the pledged funds, the higher the cost for the data provider to do evil, and the lower the trust cost of the light node.

3. The light node sends a corresponding data request to this group of data providers, which includes the corresponding block number and the target state (inclusion proof of the transaction)

4. The data provider sends the hash of the corresponding block and the inclusion proof of the transaction, along with a signature.

5. After receiving the above information, the light node forwards it to the currently linked prosecutor network. If no data credibility warning is received after the challenge period, the light node verifies the signature and passes the data credibility test if it is correct.

   

6. However, if a warning is received from the prosecutor network, the light node needs to discard the previously received signature. The prosecutor network will submit relevant proofs to the confiscation module of the smart contract. After checking the data, if the smart contract finds that the malicious behavior has indeed occurred, the corresponding data provider's pledge will be confiscated. Since some/all of the selected data providers have been confiscated, the light node needs to obtain a new list of data providers from the current network to confirm that the confiscation event has indeed occurred.

   

Other points:

• Any full node can join/leave the data provider network by initiating "register" and "withdraw" 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 "leave" and they will not be able to receive requests from light nodes to prevent the possibility of fast entry and exit. In addition, the data provider network will update the current network active data providers according to a cycle, during which the data providers cannot receive withdrawal funds. The 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 active providers in the current network during each round of network update cycle. If you choose to extend this update cycle, light nodes can enjoy a simpler verification process (the current active list can be estimated through the "register" and "withdraw" requests of the previous cycle), but full nodes that want to leave will have to face a longer waiting time.

• After receiving the data signature, the prosecutor network will check whether the signature belongs to the data provider and measure whether the data has been "finally confirmed" in the consensus network. If the data does not appear on the reasonable chain, there are two possibilities. First, the data has not been finalized by the current blockchain. Different chains have different finality rules, such as the longest chain principle. Second, the transaction is in the block of another reasonable chain. If the above data is falsified, the prosecutor network will send a confiscation request to the smart contract, including the public key of the data provider, the signature of the data provider, and the block number, and send a proof of the confiscation event to remind the light node at the same time. After receiving this data, the smart contract will measure whether the current finalized block number is consistent with the received data through the finality principle of the consensus layer. If not, the confiscation event is triggered. In addition, if the light node is confiscated due to another set of data requests after selecting a data provider, the prosecutor network will promptly send the confiscation event to remind the light node that the data credibility of the provider is low, and the light node will re-obtain the list and select another provider.

Evaluate:

• safety:Light nodes determine the cost of rational and irrational data providers to do evil through the pledge module and the prosecutor network to improve data credibility. However, because the entire protocol is based on a consensus network (tested on Ethereum in this article), once the consensus layer is attacked, the protocol will also be subject to a potential trust crisis. Therefore, a reputation mechanism can be further introduced to ensure systemic risks in extreme cases.

• Full node level security:This scheme hopes to provide a security assumption equivalent to Ethereum PoS, that is, full nodes will bear the risk of being fined if they make false statements.

• Network activity:If the current network has only a few rational data providers, light nodes will face multiple rounds of delays, but since the throughput of each data provider is not zero, each request can always be completed. Therefore, as long as the network has a rational full node, it can ensure that the network can continue to operate. At the same time, since the income of data providers is linked to the size of the staked amount, this also encourages full nodes to adopt over-staking to protect the network.

• efficiency:The author team estimates that Ethereum validators are the main users of data providers, because validators are already running full nodes and can obtain additional benefits through the protocol. Small transactions may be able to obtain trusted data through a single data provider (only one verification is required for light nodes), while large transactions may require multiple data providers to obtain trusted data (the number of verifications increases linearly with the number of providers).

Option 2: Efficiency First

Plan 2 proposes an insurance mechanism based on Plan 1 to achieve rapid data confirmation.Simply put, after the light node determines the insurance based on the policy amount and duration, part/all of the data provider's pledge can be reimbursed for the light node's subsequent losses 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 be verified whether the insurance purchase was 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 is 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:

• Data providers’ collateral is insuredTokenDifferent light node requests are independent of each other to prevent the risk of multiple insurance repayments. After the light node selects the data provider, the smart contract will place the corresponding pledge on the insurance.TokenThe policy amount is locked, and other light nodes cannot allocate this part of the pledge before the end of the insurance period. If the transactions are independent, the policy amount is the same as the maximum transaction amount. Otherwise, the policy amount is the same as the total transaction amount. Under the premise of 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 must 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.

Program 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, according to 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 greatly 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 pledged 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 pledged funds is high enough. If multiple tokens are allowed to be pledged, data providers can have more pledge 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 cycle (12-13 seconds in Ethereum), light nodes can reduce this waiting time through a guarantee. Light nodes will first add a symbol/identifier when requesting data and determine which guarantee (final confirmation/Proposed) is required. After receiving the request, the data provider provides the corresponding data and signature. When the data provider does not propose a block under the "Proposed guarantee" situation, they will be fined.
  Note: Proposed blocks will eventually be finalized or become uncle blocks.

• Costs and Fees:For the prosecutor network, they need to pledge a certain amount of tokens (greater than gas) to submit proofs to the smart contract. In addition, this part of the proof can reduce the cost through the zkp method. In addition, under the insurance mechanism, the premium submitted by the light node will be given to the data provider, and the prosecutor network will extract part of the penalty income of the malicious provider.

• 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 using 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.

Summary and evaluation

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

The article comes from the Internet:TeleportDAO: The game between data verification security and efficiency, the latest practice of light node design

Related recommendations: Spectral: 8 million airdrops, zero-threshold smart contract compilation and deployment, building a Web3 on-chain proxy economy

The ability to compile, test, and optimize smart contracts based on the Solidity language is what distinguishes Syntax from other blockchains. AI Important features of agents. Written by: Xiaobai Navigation Coderworld After seeing the continuous airdrop farce in the Restaking track, the machine intelligence network Spectral recently launched its Season…