Light client communication method, system and device based on consensus committee and storage medium

Abstract

The invention discloses a light client communication method, system and device based on a consensus committee, and a storage medium, belongs to the technical field of block chains, and solves the technical problem that an existing light client protocol still has obvious limitations in the aspects of storage and communication overhead, security and consensus mechanism compatibility. The invention discloses a light client protocol compatible with various consensus mechanisms and having universality and security, the protocol designs a consensus committee dynamic election mechanism without a trusted third party based on chain quality attributes, and provides a concise and efficient proof generation normal form in combination with weighted multiple signatures. On the premise of not depending on a centralized relay, a light client protocol keeps communication and storage complexity lower than a sub-linear level, and security threats such as Eclipse attacks and the like are effectively defended.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and more specifically, to a light client communication method, system, device, and storage medium based on a consensus committee. Background Technology

[0002] Blockchain can be viewed as an abstract, globally distributed ledger, enabling upper-layer application users to read and write data. However, the most basic requirement of "reading the ledger" in practical applications often implicitly requires users to run a local full node, which means executing the consensus protocol and maintaining a complete copy of the blockchain. With the rapid popularization of blockchain technology, more and more users are focusing on higher-level applications such as cryptocurrencies. However, application-layer terminal devices or digital wallets often have limited computing and storage resources, making it difficult to bear the continuous online and synchronization overhead of a full node.

[0003] Light clients, also known as light nodes, are a lightweight node type in blockchain networks. Compared to full nodes, light clients provide basic verification and interaction functions with lower resource overhead and storage requirements. They verify transactions by selectively downloading portions of the blockchain data and combining this with cryptographic proof mechanisms, significantly reducing storage and computational burdens. For example, a Bitcoin full node requires storing over 400GB of data, while a light client based on Simplified Payment Verification (SPV) only requires approximately 50MB of block header data. As a low-storage-cost node implementation, light clients act as crucial data verification and communication bridges in digital wallets and cross-chain interoperability mechanisms, greatly improving the accessibility and versatility of the blockchain.

[0004] Figure 1 The interaction flow of the light client is described. When a digital wallet initiates a transaction or queries its balance, it needs to request relevant data from the full node through the light client. The full node returns complete data to support the light client in completing verification. The light client ultimately completes the data verification and sends the result back to the wallet. The digital wallet, as the software implementation of the light client protocol, utilizes encryption technology and multi-factor authentication to protect user payment information and privacy, and completes data verification. In cross-chain scenarios, the light client relies on the consensus mechanism of the source chain to ensure data authenticity, and simultaneously acts as a verification module in the target chain to verify the legality of transactions on the source chain. Cross-chain account status (such as balance and assets) is updated efficiently by synchronously verifying block headers and state proofs.

[0005] The core challenge in designing light client protocols stems from the nature of blockchain verification: transaction validity depends on the determinism of the longest chain under network consensus. If a client lacks a trusted copy of the longest chain, it must rely on full nodes to forward transaction data. Taking SPV as an example, the light client only stores the block header and verifies transactions using Merkle proofs; its security assumption requires connecting to at least one honest full node. Eclipse attacks at the network layer further exacerbate security risks: attackers isolate the target node's network connection and inject forged chain data into the light client, distorting its perception of the chain state. Existing defenses largely rely on relay nodes forwarding chain states, assuming the light client trusts the honesty of most relay nodes. However, in a public blockchain environment, such strong trust assumptions are difficult to maintain.

[0006] Light client solutions vary significantly depending on the consensus mechanism. In Proof-of-Work (PoW) blockchains, light client protocols utilize probabilistic sampling and Merkel mountain commitment mechanisms to reduce communication complexity from linear to logarithmic levels. However, due to the difficulty of the fixed decentralized ledger competition process and the risks of hard forks, these protocols struggle to achieve backward compatibility. In Proof-of-Stake (PoS) blockchains, the efficiency of offline verification remains constrained because the validity of suffix blocks depends on a dynamically changing set of stake signatures.

[0007] Traditional light client protocols suffer from high storage and communication overhead, vulnerability to malicious full-node fraud, and

[0008] The impact of Eclipse attacks, and the issue that it only applies to specific consensus mechanisms (such as PoW or PoS, and the two are incompatible). Summary of the Invention

[0009] The technical problem to be solved by the present invention is to address the above-mentioned shortcomings of the prior art. The purpose of the present invention is to provide a light client communication method based on a consensus committee, which can solve the problems of large storage and communication overhead, susceptibility to malicious node attacks, and poor compatibility of consensus mechanisms in traditional light clients.

[0010] The second objective of this invention is to provide a lightweight client communication system based on a consensus committee.

[0011] The third objective of this invention is to provide a computer device.

[0012] The fourth objective of this invention is to provide a computer storage medium.

[0013] To achieve the first objective mentioned above, this invention provides a lightweight client communication method based on a consensus committee, comprising the following steps:

[0014] Step 1. Define blockchain security attributes. A secure blockchain has the following three basic attributes:

[0015] Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), we have This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1, and ° indicates a prefix relationship;

[0016] Chain quality: The stable chain output by any honest full node. In any k consecutive blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient;

[0017] Chain growth: Let C1 and C2 be the chains output by an honest full node in time slots s and s+ζ, respectively. Then we have This holds true, where τ∈(0,1] is the growth rate coefficient;

[0018] Step 2. Weighted multi-signature, define SG:={p i} i∈ [ 1,m [A] is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i Participation in joint signatures is possible, but the legitimacy of a joint signature depends on whether the total weight of the participants reaches a certain threshold.

[0019] Step 3. Define lightweight client properties, define B i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols:

[0020] 1) Initialization protocol Init(B0) → (st,π); 2) State update protocol Upd(st) → (st′,π); 3) State verification protocol VrfySt(st,st′,π) → b; 4) Query protocol Q(st,Tx) → (r,π); 5) Query verification protocol Vrfy(st,r,π) → b;

[0021] Step 4. Construct the system model, which includes: blockchain C, consensus committee V, full nodes participating in consensus competition, light client LC, and cryptographic assumptions;

[0022] Step 5. Construct an adversary model. The adversary can statically corrupt a certain proportion of the full nodes participating in consensus competition before the protocol begins, and use the controlled full nodes participating in consensus competition to carry out delay attacks.

[0023] Step 6. Build a general and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for light clients, enabling them to verify the determinism of on-chain data even in the absence of a trusted full node.

[0024] Step 7. Construct a consensus committee construction mechanism, a lightweight client query protocol, and a query verification protocol;

[0025] Step 8. Construct a consensus committee rotation mechanism to enhance the activity, decentralization level, and robustness of light client verification in the blockchain system, while preventing malicious participants from launching targeted attacks by controlling a specific consensus committee for a long period of time;

[0026] Step 9. Construct an incentive mechanism to make honest behavior the optimal strategy choice for validators.

[0027] As a further improvement, in step 2, in a (t,x) weighted multi-signature scheme, t represents the weight threshold, and x represents the total weight of the signature group, then the weight distribution W of SG is... SG satisfy:

[0028] (W SG :=(w1,w2,...,w m ))∧(∑W SG =x)

[0029] A valid weighted multisignature is composed of a subset Generate, its weight distribution W sg satisfy:

[0030] (W sg :=(w1,w2,...,w |sg| ))≥t.

[0031] Furthermore, in step 4, blockchain C satisfies the blockchain security attributes defined in step 1, and also satisfies the initialization protocol Init(B0)→(st,π) defined in the light client attributes;

[0032] The members of the consensus committee V consist of a group of full nodes that participate in the consensus competition to generate a series of blocks in blockchain C. They are responsible for observing the state query requests initiated by the light client LC and generating a proof π for the state. This proof π is used to verify the validity of the blockchain state st or transaction Tx.

[0033] Each full node participating in the consensus competition can independently generate its own public-private key pair (pk).i ,sk i In the light client protocol, this public-private key pair (pk) i ,sk i This is used to participate in weighted multi-signature and signature verification after becoming a member of the consensus committee;

[0034] The light client LC does not have the ability to store all block headers and handle high-load communication. The light client LC interacts with the full node to execute the Upd(), VrfySt(), Q() and Vrfy() functions to query the blockchain state.

[0035] The cryptographic assumption is a random oracle O hash The hash function Hash() is collision resistant.

[0036] Furthermore, in step 5, corrupting the full nodes participating in the consensus competition is insufficient to compromise the security properties of chain C, but an adversary can intercept the inputs and outputs of any light client LC.

[0037] Furthermore, in step 6, the proof generation process of the light client protocol has the following core characteristics: permissionless, chain-independent, and low-latency.

[0038] Furthermore, in step 7, the consensus committee construction mechanism assumes the current block height is n+1, and any light client LC can access block B. n+1 Then initiate the query protocol Q(st,Tx), at which point B will be... n+1 The previously generated x consecutive blocks (B n-x+1 ,...,B n-1 B n A full node participating in the consensus competition is defined as a consensus committee member. Each member then initializes proof generation parameters, including the threshold t and the consensus committee weight distribution, and each member v... i The weight is determined by the number of blocks produced;

[0039] The light client query protocol is as follows: when in the current block B n+1 After the consensus committee V is determined, the light client LC can initiate a query request Q(st,Tx) to the blockchain network. Upon receiving the request, the consensus committee members generate the query result and proof (r,π) based on the request.

[0040] The query verification protocol is that after obtaining (r,π), the light client LC updates the latest state by verifying the validity of π.

[0041] Furthermore, in step 8, the consensus committee re-election process is as follows: Let the current verification period Epoch be... e The consensus committee for V eThe consensus committee is in the current block B n+1 For a continuous period of time following its generation, the block state proof is continuously provided to the light client LC until a new consensus committee V is formed. e+1 They were formally elected.

[0042] To achieve the second objective mentioned above, this invention provides a lightweight client communication system based on a consensus committee, comprising:

[0043] The security attribute module is used to define the security attributes of the blockchain. A secure blockchain has the following three basic attributes: Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), they all have a common prefix. This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1; ° indicates prefix relation; chain quality: the stable chain output by any honest full node. In any consecutive k blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient; Chain growth: Let C1 and C2 be the values ​​of an honest full node in time slots s and s, respectively. The output chain then has This holds true, where τ∈(0,1] is the growth rate coefficient;

[0044] The signature module is used for weighted multi-signature, defining SG:={p i}i∈[ 1,m [A] is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i Participation in joint signatures is possible, but the legitimacy of a joint signature depends on whether the total weight of the participants reaches a certain threshold.

[0045] The Light Client Properties module is used to define light client properties, including B. i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols:

[0046] 1) Initialization protocol Init(B0) → (st,π); 2) State update protocol Upd(st) → (st′,π); 3) State verification protocol VrfySt(st,st′,π) → b; 4) Query protocol Q(st,Tx) → (r,π); 5) Query verification protocol Vrfy(st,r,π) → b;

[0047] The system model module is used to build the system model, which includes: blockchain C, consensus committee V, full nodes participating in consensus competition, light client LC, and cryptographic assumptions.

[0048] The adversary model module is used to construct an adversary model. The adversary can statically corrupt a certain proportion of the full nodes participating in the consensus competition before the protocol begins, and use the controlled full nodes participating in the consensus competition to carry out delay attacks.

[0049] The protocol module is used to build a general and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for light clients, enabling them to verify the determinism of on-chain data even in the absence of a trusted full node.

[0050] The mechanism module is used to build the consensus committee building mechanism, the light client query protocol, and the query verification protocol.

[0051] The rotation mechanism module is used to build a consensus committee rotation mechanism to enhance the activity, decentralization level and robustness of light client verification in the blockchain system, while preventing malicious participants from launching targeted attacks by controlling a specific consensus committee for a long time.

[0052] The incentive mechanism module is used to build incentive mechanisms that make honest behavior the optimal strategy choice for validators.

[0053] To achieve the third objective mentioned above, the present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned light client communication method based on a consensus committee.

[0054] To achieve the fourth objective mentioned above, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned light client communication method based on a consensus committee.

[0055] Beneficial effects

[0056] Compared with the prior art, the advantages of this invention are as follows:

[0057] This invention presents a universal and secure light client protocol that addresses the problems of high storage and communication overhead, vulnerability to malicious node attacks, and poor compatibility with consensus mechanisms inherent in traditional light clients. Based on chain quality attributes, the light client protocol designs a dynamic consensus committee election and weighted multi-signature mechanism to achieve permissionless, chain-independent, and low-latency proof generation. Simultaneously, an incentive mechanism ensures honest participation from validators, enhancing the system's security and usability. Attached Figure Description

[0058] Figure 1This is a framework diagram of the lightweight client protocol of the present invention;

[0059] Figure 2 This is a flowchart of the algorithm for the light client protocol of the present invention. Detailed Implementation

[0060] The present invention will be further described below with reference to specific embodiments shown in the accompanying drawings.

[0061] See Figures 1-2 A light client communication method based on a consensus committee includes the following steps 1 to 9:

[0062] Step 1. Define blockchain security attributes. A secure blockchain has the following three basic attributes:

[0063] 1) Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), we have This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1, and ° indicates a prefix relationship.

[0064] 2) Chain quality: The stable chain output by any honest full node. In any consecutive k blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient.

[0065] 3) Chain growth: Let C1 and C2 be the values ​​of an honest full node in time slots s and s, respectively. The output chain then has This holds true, where τ∈(0,1] is the growth rate coefficient.

[0066] Step 2. Weighted multi-signature, define SG:={p i} i∈[1,m] It is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i In a joint signature scheme, the legitimacy of the signature depends on whether the total weight of the participants reaches a specific threshold. Formally, in a (t,x) weighted multisignature scheme, where t represents the weight threshold and x represents the total weight of the signature group, the weight distribution W of SG is... SG satisfy:

[0067] (W SG :=(w1,w2,...,w m ))∧(∑W SG =x)

[0068] A valid weighted multisignature is composed of a subset Generate, its weight distribution W sg satisfy:

[0069] (W sg :=(w1,w2,...,w |sg| ))≥t

[0070] Weighted multi-signature has good compatibility and is applicable to almost all mainstream public blockchain protocols. In this invention, a signature group is formed by selecting a specific set of full nodes participating in consensus competition. This signature group is used to provide chain-independent transaction proofs for light clients. This method only requires the full nodes participating in consensus competition to have the basic ability to generate and verify signatures, thereby lowering the barrier to entry. When signature verification is implemented through smart contracts, its compatibility is even better.

[0071] Step 3. Define lightweight client properties, define B i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols:

[0072] 1) Initialization protocol Init(B0)→(st,π); LC takes the genesis block B0 as input, and through interaction with FN, initializes its state st and obtains a proof π to verify the correctness of the initialization.

[0073] 2) State update protocol Upd(st) → (st′, π); LC updates its state from st to st′ through interaction with FN. State refers to a continuous block header st:=(HB) in blockchain C. i ,HB i+1 ,...,HB n )) to reflect the latest view of C and obtain a proof of π.

[0074] 3) State verification protocol VrfySt(st,st′,π)→b; LC verification proves π, confirming that state st′ is correctly transformed from st, and outputs the result b∈{0,1}.

[0075] 4) Query Protocol Q(st,Tx)→(r,π); LC initiates a query on a transaction set Tx, where Tx contains a group of transactions to be queried (tx1,tx2,...), and each transaction involves a query type, such as the current account balance, the sender / receiver / amount of the transaction, etc. The client receives the query result r and proof π. If Tx is not in C, an error is returned.

[0076] 5) Query verification protocol Vrfy(st,r,π)→b; LC verification proves π, confirms the correctness of the query result r, and outputs the result b∈{0,1}.

[0077] Step 4. Construct the system model, which includes:

[0078] Blockchain C: Blockchain C satisfies the blockchain security attributes defined in step 1, and also satisfies the initialization protocol Init(B0)→(st,π) in the light client attributes. That is, C can generate the genesis block B0 through trusted initialization settings, and determine an initial consensus committee V1 in the subsequent x consecutive blocks. Then, the light client determines its initial state st by interacting with V1 and obtains an initial proof π to ensure the correctness of the initialization.

[0079] Consensus Committee V: The consensus committee consists of a group of full nodes that compete for consensus in generating a series of blocks in blockchain C. It is responsible for observing state query requests initiated by light clients and generating a proof π for that state. This proof is used to verify the validity of the blockchain state st or transaction Tx.

[0080] Full nodes participating in consensus competition: Similar to most public blockchain networks, full nodes participating in consensus competition can independently generate their own public-private key pairs (PK). i ,sk i In the light client protocol, this key is used to participate in weighted multi-signature and signature verification after becoming a consensus committee member. Furthermore, each full node participating in the consensus competition has a unique account address (ad). i The address is derived from its public key through an address generation mechanism similar to P2PKH.

[0081] Light Client (LC): Any resource-constrained node can be selected as an LC. Light client LCs do not have the ability to store all block headers or handle high-load communication. LCs interact with full nodes to execute functions such as Upd(), VrfySt(), Q(), and Vrfy() to query the blockchain state.

[0082] Cryptographic assumption: For random oracle O hash The hash function Hash() is collision resistant, and all digital signature schemes satisfy the existence unforgeability under chosen-message attack (EUF-CMA) security.

[0083] Step 5. Construct an adversary model. The adversary can statically corrupt a certain percentage of the full nodes participating in consensus competition before the protocol begins, and then use these controlled full nodes to launch delay attacks. Specifically, assume that there is a probabilistic polynomial time (PPT) adversary A during protocol execution, whose goal is to deceive the light client LC by forging transaction proofs. The adversary can statically corrupt a certain percentage of the full nodes participating in consensus competition before the protocol begins, and use these controlled full nodes to launch delay attacks, etc. However, according to the blockchain properties defined in Step 1 (common prefix, chain quality, and chain growth), under the condition of satisfying an honest majority, corrupting the full nodes participating in consensus competition is insufficient to compromise the security properties of chain C.

[0084] Assuming the light client in this protocol is honest, A can intercept any input and output of LC. For example, A can isolate LC from the blockchain network and send forged transactions and proofs to LC. Furthermore, all honest full nodes can reliably access the latest view of the blockchain.

[0085] Step 6. The light client interacts with the blockchain by downloading a portion of the blockchain data and using cryptographic proofs, suitable for resource-constrained devices. This invention constructs a universal and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for the light client, enabling it to verify the determinism of on-chain data even in the absence of trusted full nodes. This protocol dynamically constructs a consensus committee of full nodes participating in consensus competition based on the blockchain's chain quality attribute, ensuring that the proportion of full nodes honestly participating in consensus competition is at least μ in any k consecutive blocks on the main chain, thereby ensuring that the proportion of honest members in the consensus committee is not less than μ. The consensus committee is responsible for identifying the finally determined blocks on the main chain and providing proofs for state verification requests initiated by the light client. The generation of proofs relies on verification members collecting weighted multi-signatures that reach a threshold, with weights allocated according to the number of blocks mined by a single full node participating in consensus competition within k consecutive blocks. By verifying these proofs, the light client ensures the integrity and correctness of transactions from the genesis block to the signature block, effectively preventing malicious full nodes from forging transaction proofs, while reducing its own storage and communication overhead. To ensure the consensus committee remains active and prevents stagnation, it is updated periodically. Updates can be triggered statically (e.g., every second) or dynamically (driven by specific events). Ultimately, only active members who participate or contribute valid proofs are eligible for rewards, incentivizing their honest and continued participation.

[0086] The proof generation process of the light client protocol possesses the following core characteristics: permissionless, chain-independent, and low-latency. First, consensus committee members are randomly selected and periodically rotated by full nodes participating in the consensus competition through the underlying consensus protocol, without the need for trusted third-party coordination, ensuring permissionless access. Second, based on the universal property of chain quality, the protocol is compatible with all blockchain systems that satisfy this property (such as PoW, PoS, etc.), achieving chain independence. Finally, consensus committee members can quickly obtain the latest chain view and complete weighted multi-signature, while the light client independently confirms the final chain state in a trustless environment through non-interactive local verification. The light client protocol efficiently achieves the three major goals of storage, communication, and verification, and has good scalability, making it suitable for cross-chain interoperability and complex light client needs.

[0087] Step 7. In the system model, the light client generates an initial state `st` through a trusted initialization process. This invention also constructs a consensus committee construction mechanism, a light client query protocol, and a query verification protocol. The query protocol and query verification protocol are specific implementations of the state update protocol and state verification protocol in transaction query scenarios. When consecutive blocks are involved, they are extended to state query and state verification. The difference between the two is that state-related functions (based on block headers) mainly reflect the core capabilities of the light client, while transaction-related functions are their fine-grained manifestations and can be further extended to cross-chain scenarios. For the overall framework of the protocol and detailed algorithm descriptions, please refer to the respective documentation. Figure 1 and Figure 2 .

[0088] Consensus committee construction mechanism: The framework of the light client protocol, such as Figure 1 As shown. Assuming the current block height is n+1, any light client can access block B. n+1 Then, a query protocol Q(st, Tx) is initiated. At this point, the blockchain system will... n+1 The previously generated x consecutive blocks (B n-x+1 ,...,B n-1 B n The full nodes participating in the consensus competition are defined as members of the consensus committee. Each member then initializes the proof generation parameters, including the threshold t and the consensus committee weight distribution, and each member v... i The weight of B is determined by the number of blocks produced. Before publishing the query protocol, the lightweight client only needs to obtain B in advance. n+1The verification preparation can be completed by proving the decentralized accounting competition process of the full nodes participating in the consensus competition in the previous x consecutive blocks. It should be noted that among these consecutive x blocks, the full nodes participating in the consensus competition may be repeated. Therefore, the consensus committee actually consists of m < x members. The selection of the parameters (t, x) is determined according to the chain quality attribute. Specifically, chain quality means that in k or more consecutive blocks of C, the ratio of full nodes honestly participating in the consensus competition is at least μ. To utilize this attribute, the light client needs to satisfy the double constraint conditions of x > k and This design has configuration flexibility, and (t, x) allows for dynamic trade-offs between availability and security according to the characteristics of different public blockchains.

[0089] Light client query protocol: When the consensus committee V is determined in the current block B n+1 the light client can initiate a query request Q(st, Tx) to the blockchain network. After receiving the request, the members of the consensus committee generate query results and proofs (r, π) according to the request. Specifically, each member v i ∈V uses their respective private keys sk i to weight-sign the query result r and broadcast the signature over the network. Subsequently, v i collects the signatures of other members through the public consensus committee network (the public memory pool in EIP-4337). Define S sb as a set of multi-signatures collected by v i from V, and w sb as the total weight of S sb , that is, the sum of the weights corresponding to all signatures σ i ∈S sb . When the signature weight collected by v i satisfies w sb ≥t (where t is the threshold), a complete proof π:=(S sb , bv) can be constructed, where bv is a bit vector used to indicate which verifiers (by index) participated in the signature. Finally, v i broadcasts (r, π) to the network for the light client to perform query verification. [[ID=​​​​​​​​​​​​​i The correctness of S. Finally, verify S. sb The signature weight reaches the threshold t. If all the above steps pass, then π is proven to be valid, the light client completes the verification Vrfy(st,r,π), and updates the state or view.

[0091] It is important to note that the status or transaction queried by the light client must meet the following condition: the block it belongs to must be in the latest block B. n+1 Within the previous k blocks, only honest nodes in the consensus committee will generate the corresponding proof after confirming its validity. Typical parameter configurations are: Bitcoin typically uses k=6, while Ethereum uses k=12; the specific value can be estimated based on the common prefix parameter of different blockchains. This mechanism essentially provides a "consensus-level irreversibility" guarantee for transactions: only when a transaction receives sufficient confirmation depth in the blockchain can it be considered a stable and irreversible state, thus effectively resisting security risks that may arise from chain reorganization.

[0092] Similar to Ethereum's Beacon Chain, the consensus committee V e The proof provided to the light client for the current period can be defined as a "snapshot" of the next period. Therefore, the light client does not need to store the complete block header data before the current period, but only needs to save the proof of the current state.

[0093] In the adversary model, it is assumed that an attacker can intercept the communication channels of light clients, thereby preventing proofs or blockchain views from being transmitted to the light clients, making it impossible for them to verify the validity of the state or update the on-chain view in a timely manner. Based on the above premise, assuming the consensus committee remains secure and trustworthy, an attacker cannot forge proofs of a valid state. Therefore, light clients will not mistakenly identify unconfirmed states or non-final on-chain views as valid or final results.

[0094] Step 8. Construct a consensus committee rotation mechanism. Although the consensus committee's construction mechanism effectively ensures that the elected consensus committee maintains an honest majority, thereby ensuring system security, the long-term fixation of consensus committee members after selection may lead to insufficient decentralization, resulting in security and performance risks. Therefore, a dynamic rotation mechanism for the consensus committee is introduced to enhance the activity, decentralization level, and robustness of light client verification in the blockchain system, while preventing malicious actors from launching targeted attacks by controlling a specific consensus committee for an extended period.

[0095] Figure 1 The right side illustrates the process of a consensus committee re-election. Let the current verification period be Epoch. e The consensus committee for V e The consensus committee is in the current block Bn+1 For a continuous period of time following its generation, it continuously provides trusted and valid proof of block state to light clients until a new consensus committee V... e+1 The consensus committee is formally elected. To achieve dynamic management of the consensus committee, blockchain C is divided into several verification cycles. Each cycle is managed by the corresponding consensus committee, which is responsible for generating and maintaining the cross-chain state proof within that cycle, ensuring the continuity and security of the verification process.

[0096] The switching strategies for verification cycles are mainly divided into two categories: static switching rules and dynamic switching rules. Static rules are based on a pre-set fixed time interval or number of blocks (e.g., a reorganization is triggered every 256 cycles in the Ethereum synchronization committee mechanism). The cycle length parameter can be flexibly adjusted according to specific needs to balance decentralization and system performance. Dynamic rules, on the other hand, allow light clients to proactively initiate consensus committee switching requests based on actual use cases and security requirements. Specifically, light clients can initiate a consensus committee switching request in the new block B. n+y+x+1 Submit a change request transaction containing the new consensus committee version number and the corresponding block sequence public key set.

[0097] TxEpoch e+1 This is used to replace the current consensus committee.

[0098] To ensure the security and consistency of the consensus committee rotation process, this change request must be approved by the current consensus committee V. e The consensus committee confirmation process involves weighted multi-signature verification by its members. This process not only prevents malicious nodes from manipulating the switch of the consensus committee but also ensures a smooth transition between the old and new consensus committees, reducing the risk of system attacks. Furthermore, the weighted multi-signature-based consensus committee confirmation mechanism effectively reduces network load and improves the efficiency and reliability of node state synchronization.

[0099] Step 9. Construct an incentive mechanism to make honest behavior the optimal strategy for validators. In the design of the light client protocol, light clients generate transaction proofs through a consensus committee to ensure the security and trustworthiness of on-chain transactions. However, it is important to emphasize that if validators do not receive corresponding rewards for providing query services or generating state proofs, their rational choice may be inclined to refuse participation or engage in malicious behavior. Therefore, establishing an effective incentive mechanism is crucial, with the core objective of making honest behavior the optimal strategy for validators (i.e., reaching a Nash equilibrium). This incentive mechanism's design philosophy is highly consistent with mainstream blockchain networks such as Cosmos and Polkadot. Taking Cosmos as an example, its relay nodes obtain dual benefits by collecting transaction fees and staking Atom tokens, thereby effectively ensuring the stable operation and security of the network.

[0100] Validator behavior can be analyzed from two dimensions: first, behavior related to the decentralized ledger competition process, which is determined by the underlying blockchain's consensus mechanism. Its reward mechanism is independent of the light client verification process; all full nodes that successfully produce blocks and participate in the consensus competition directly receive Coinbase rewards issued by the system. Second, behavior related to voting, which directly relates to the generation of light client proofs and aims to incentivize consensus committee members to remain online and participate in the weighted multi-signature process. In practical applications, several widely adopted reward source schemes are available: these include validator fees that rely on the protocol to prevent data spoofing attacks, and ERC-20 tokens issued specifically for the protocol. These settings can be implemented through smart contracts. Reward distribution strictly follows the multi-signature weight principle; validators with higher signature weights receive more rewards. Only validators who actively participate in signing within the specified time window are eligible to share the proof fees for that period, while non-participants will only receive the basic decentralized ledger competition process rewards.

[0101] The light client protocol can also introduce a more granular reward and punishment mechanism to incentivize validators to respond to signature requests promptly, while penalizing potential Byzantine behavior, including by validators and transaction initiators. By flexibly adjusting the participation threshold, the protocol can tolerate a certain percentage of unexpected node failures. This design not only significantly improves the reliability of light client verification but also provides institutional guarantees for building a decentralized, highly secure client communication system.

[0102] A light client communication system based on a consensus committee includes:

[0103] The security attribute module is used to define the security attributes of the blockchain. A secure blockchain has the following three basic attributes: Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), they all have a common prefix. This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1; ° indicates prefix relation; chain quality: the stable chain output by any honest full node. In any consecutive k blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient; Chain growth: Let C1 and C2 be the values ​​of an honest full node in time slots s and s, respectively. The output chain then has This holds true, where τ∈(0,1] is the growth rate coefficient;

[0104] The signature module is used for weighted multi-signature, defining SG:={p i} i∈[1,m]It is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i Participation in joint signatures is possible, but the legitimacy of a joint signature depends on whether the total weight of the participants reaches a certain threshold.

[0105] The Light Client Properties module is used to define light client properties, including B. i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols:

[0106] 1) Initialization protocol Init(B0) → (st,π); 2) State update protocol Upd(st) → (st′,π); 3) State verification protocol VrfySt(st,st′,π) → b; 4) Query protocol Q(st,Tx) → (r,π); 5) Query verification protocol Vrfy(st,r,π) → b;

[0107] The system model module is used to build the system model, which includes: blockchain C, consensus committee V, full nodes participating in consensus competition, light client LC, and cryptographic assumptions.

[0108] The adversary model module is used to construct an adversary model. The adversary can statically corrupt a certain proportion of the full nodes participating in the consensus competition before the protocol begins, and use the controlled full nodes participating in the consensus competition to carry out delay attacks.

[0109] The protocol module is used to build a general and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for light clients, enabling them to verify the determinism of on-chain data even in the absence of a trusted full node.

[0110] The mechanism module is used to build the consensus committee building mechanism, the light client query protocol, and the query verification protocol.

[0111] The rotation mechanism module is used to build a consensus committee rotation mechanism to enhance the activity, decentralization level and robustness of light client verification in the blockchain system, while preventing malicious participants from launching targeted attacks by controlling a specific consensus committee for a long time.

[0112] The incentive mechanism module is used to build incentive mechanisms that make honest behavior the optimal strategy choice for validators.

[0113] A computer device includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned light client communication method based on a consensus committee.

[0114] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned light client communication method based on a consensus committee.

[0115] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention, and these will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. A lightweight client communication method based on a consensus committee, characterized in that, Includes the following steps: Step 1. Define blockchain security attributes. A secure blockchain has the following three basic attributes: Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), we have This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1, and ° indicates a prefix relationship; Chain quality: The stable chain output by any honest full node. In any k consecutive blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient; Chain growth: Let C1 and C2 be the values ​​of an honest full node in time slots s and s, respectively. The output chain then has This holds true, where τ∈(0,1] is the growth rate coefficient; Step 2. Weighted multi-signature, define SG:={p i } i∈ [ 1,m [A] is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i Participation in joint signatures is possible, but the legitimacy of a joint signature depends on whether the total weight of the participants reaches a certain threshold. Step 3. Define lightweight client properties, define B i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols: 1) Initialization protocol Init(B0) → (st,π); 2) State update protocol Upd(st) → (st′,π); 3) State verification protocol VrfySt(st,st′,π) → b; 4) Query protocol Q(st,Tx) → (r,π); 5) Query verification protocol Vrfy(st,r,π) → b; Step 4. Construct the system model, which includes: blockchain C, consensus committee V, full nodes participating in consensus competition, light client LC, and cryptographic assumptions; Step 5. Construct an adversary model. The adversary can statically corrupt a certain proportion of the full nodes participating in consensus competition before the protocol begins, and use the controlled full nodes participating in consensus competition to carry out delay attacks. Step 6. Build a general and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for light clients, enabling them to verify the determinism of on-chain data even in the absence of a trusted full node. Step 7. Construct a consensus committee construction mechanism, a lightweight client query protocol, and a query verification protocol; Step 8. Construct a consensus committee rotation mechanism to enhance the activity, decentralization level, and robustness of light client verification in the blockchain system, while preventing malicious participants from launching targeted attacks by controlling a specific consensus committee for a long period of time; Step 9. Construct an incentive mechanism to make honest behavior the optimal strategy choice for validators.

2. The lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 2, in a (t,x) weighted multi-signature scheme, t represents the weight threshold, and x represents the total weight of the signature group. Then, the weight distribution W of SG... SG satisfy: (W SG :=(w1,w2,...,w m ))∧(∑W SG =x) A valid weighted multisignature is composed of a subset Generate, its weight distribution W sg satisfy: (IN sg :=(w1,w2,...,w sg| ))≥t。 3. The lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 4, blockchain C satisfies the blockchain security properties defined in step 1, and also satisfies the initialization protocol Init(B0)→(st,π) in the light client properties definition; The members of the consensus committee V consist of a group of full nodes that participate in the consensus competition to generate a series of blocks in blockchain C. They are responsible for observing the state query requests initiated by the light client LC and generating a proof π for the state. This proof π is used to verify the validity of the blockchain state st or transaction Tx. Each full node participating in the consensus competition can independently generate its own public-private key pair (pk). i ,sk i In the light client protocol, this public-private key pair (pk) i ,sk i This is used to participate in weighted multi-signature and signature verification after becoming a member of the consensus committee; The light client LC does not have the ability to store all block headers and handle high-load communication. The light client LC interacts with the full node to execute the Upd(), VrfySt(), Q() and Vrfy() functions to query the blockchain state. The cryptographic assumption is a random oracle O hash The hash function Hash() is collision resistant.

4. The lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 5, corrupting the full nodes participating in the consensus competition is not enough to compromise the security properties of chain C, but an adversary can intercept the inputs and outputs of any light client LC.

5. The lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 6, the proof generation process of the light client protocol has the following core characteristics: permissionless, chain-independent, and low-latency.

6. The lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 7, the consensus committee construction mechanism is as follows: assuming the current block height is n+1, any light client LC can access block B. n+1 Then initiate the query protocol Q(st,Tx), at which point B will be... n+1 The previously generated x consecutive blocks (B n-x+1 ,...,B n-1 B n A full node participating in the consensus competition is defined as a consensus committee member. Each member then initializes proof generation parameters, including a threshold t and the consensus committee weight distribution, and each member v... i The weight is determined by the number of blocks produced; The light client query protocol is as follows: when in the current block B n+1 After the consensus committee V is determined, the light client LC can initiate a query request Q(st,Tx) to the blockchain network. Upon receiving the request, the consensus committee members generate the query result and proof (r,π) based on the request. The query verification protocol is that after obtaining (r,π), the light client LC updates the latest state by verifying the validity of π.

7. A lightweight client communication method based on a consensus committee according to claim 1, characterized in that, In step 8, the consensus committee re-election process is as follows: Let the current verification period be Epoch. e The consensus committee for V e The consensus committee is in the current block B n+1 For a continuous period of time following its generation, the block state proof is continuously provided to the light client LC until a new consensus committee V is formed. e+1 They were formally elected.

8. A lightweight client communication system based on a consensus committee, characterized in that, include: The security attribute module is used to define the security attributes of the blockchain. A secure blockchain has the following three basic attributes: Common prefix: For two chains C1 and C2, and any two honest full nodes in time slots s1 and s2 (satisfying s1≤s2), they all have a common prefix. This holds true, where k∈N are common prefix parameters. This indicates removing the last k blocks of C1; ° indicates prefix relation; chain quality: the stable chain output by any honest full node. In any k consecutive blocks, the proportion of malicious blocks does not exceed μ, where μ∈(0,1] is the chain quality coefficient; Chain growth: Let C1 and C2 be the chains output by an honest full node in time slots s and s+ζ, respectively, then we have This holds true, where τ∈(0,1] is the growth rate coefficient; The signature module is used for weighted multi-signature, defining SG:={p i } i∈[1,m] It is a signature group containing m participants. Weighted multi-signature allows signature group member p to... i According to their respective "weights" w i Participation in joint signatures is possible, but the legitimacy of a joint signature depends on whether the total weight of the participants reaches a certain threshold. The Light Client Properties module is used to define light client properties, including B. i For the i-th block of blockchain C, a complete light client protocol runs between the light client LC and a group of full nodes FN with C as input, and supports the following sub-protocols: 1) Initialization protocol Init(B0) → (st,π); 2) State update protocol Upd(st) → (st′,π); 3) State verification protocol VrfySt(st,st′,π) → b; 4) Query protocol Q(st,Tx) → (r,π); 5) Query verification protocol Vrfy(st,r,π) → b; The system model module is used to build the system model, which includes: blockchain C, consensus committee V, full nodes participating in consensus competition, light client LC, and cryptographic assumptions. The adversary model module is used to construct an adversary model. The adversary can statically corrupt a certain proportion of the full nodes participating in the consensus competition before the protocol begins, and use the controlled full nodes participating in the consensus competition to carry out delay attacks. The protocol module is used to build a general and secure light client protocol. The light client protocol is dedicated to generating valid proofs of transactions or states for light clients, enabling them to verify the determinism of on-chain data even in the absence of a trusted full node. The mechanism module is used to build the consensus committee building mechanism, the light client query protocol, and the query verification protocol. The rotation mechanism module is used to build a consensus committee rotation mechanism to enhance the activity, decentralization level and robustness of light client verification in the blockchain system, while preventing malicious participants from launching targeted attacks by controlling a specific consensus committee for a long time. The incentive mechanism module is used to build incentive mechanisms that make honest behavior the optimal strategy choice for validators.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements a light client communication method based on a consensus committee as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements a light client communication method based on a consensus committee as described in any one of claims 1-7.

Images