Blockchain system on-chain off-chain data trusted interaction method and device
Patent Information
- Application Number
- CN202510169763.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-02-17
- Publication Date
- 2026-08-18
AI Technical Summary
现有区块链解决方案的关键限制之一是其可扩展性，特别是无需权限许可的区块链系统
Smart Images
Figure CN122597067A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of blockchain and cloud service technology, and in particular to a method and apparatus for trusted on-chain and off-chain data interaction in a blockchain system. Background Technology
[0002] This section is intended to provide background or context for the embodiments of the invention set forth in the claims. The description herein is not an admission that it is prior art simply because it is included in this section.
[0003] Blockchain is a distributed ledger that provides highly available services and data integrity. One of the key limitations of existing blockchain solutions is their scalability, especially for permissionless blockchain systems. Generally speaking, blockchain system performance (i.e., throughput and latency) decreases significantly as the number of nodes increases.
[0004] To improve the scalability of blockchains, a solution has been proposed that builds on top of the first-layer on-chain protocol (also known as Layer 1 or main chain protocol) and implements a second-layer off-chain protocol (also known as Layer 2). This approach involves moving some workloads off-chain to improve the overall performance of the blockchain. Its main advantage is that it does not require modification of the original on-chain protocol to enhance the scalability of the blockchain.
[0005] Balancing the workload of on-chain and off-chain protocols to achieve optimal performance of the blockchain system has become a pressing issue that needs to be addressed in the current blockchain system for trusted interaction between on-chain and off-chain data. Summary of the Invention
[0006] This invention provides a method for trusted on-chain and off-chain data interaction in a blockchain system, which can balance the workload of on-chain / off-chain protocols to achieve optimal performance of the blockchain system. The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The method is applied to any committee node of any committee, including:
[0007] Based on the transaction request sent by the user, determine the event triggered by the committee node, and add the transaction request to the event transaction list corresponding to the event. The event includes cross-committee events and intra-committee events.
[0008] After each cross-committee event's transaction execution conditions are met, the event transaction list corresponding to the cross-committee event is determined as the target transaction list. A target transaction request is then determined based on this list, submitted, and executed within the committee. The relevant account for the target transaction request is locked. The committee is designated as the source committee, and a first cross-committee request message is sent to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message, which is then sent to the source committee and the target committee respectively. Upon receiving the second cross-committee message, either the first sub-transaction request or the second sub-transaction request in the second cross-committee message is executed.
[0009] After each transaction execution condition of an event within the committee is met, the event transaction list corresponding to the event within the committee is determined as the target transaction list. The target transaction request is determined based on the target transaction list and submitted and executed within the committee.
[0010] This invention also provides a trusted on-chain / off-chain data interaction device in a blockchain system, capable of balancing the workload of on-chain / off-chain protocols to achieve optimal performance of the blockchain system. The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The device is applied to any committee node of any committee and includes:
[0011] The transaction request receiving module is used to determine the event triggered by the committee node based on the transaction request sent by the user, and add the transaction request to the event transaction list corresponding to the event, wherein the event includes cross-committee events and intra-committee events;
[0012] The cross-committee processing module, after each transaction execution condition of a cross-committee event is met, determines the event transaction list corresponding to the cross-committee event as the target transaction list, calls the cross-committee processing module to determine the target transaction request based on the target transaction list, submits and executes the target transaction request within the committee; locks the relevant account for the target transaction request; uses the committee as the source committee, sends a first cross-committee request message to all consensus nodes in the on-chain system, so that the consensus nodes divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message and send it to the source committee and the target committee respectively; upon receiving the second cross-committee message, executes the first sub-transaction request or the second sub-transaction request in the second cross-committee message;
[0013] The committee processing module is used to determine the event transaction list corresponding to the committee event as the target transaction list after each transaction execution condition of the committee event is met, determine the target transaction request based on the target transaction list, and submit and execute the target transaction request within the committee.
[0014] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described method for trusted on-chain and off-chain data interaction in the blockchain system.
[0015] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for trusted on-chain and off-chain data interaction in a blockchain system.
[0016] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for trusted on-chain and off-chain data interaction in the blockchain system.
[0017] In this embodiment of the invention, the blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The method is applied to any committee node of any committee and includes: determining the event triggered by the committee node based on a transaction request sent by a user, and adding the transaction request to the event transaction list corresponding to the event, wherein the event includes cross-committee events and intra-committee events; after each transaction execution condition of a cross-committee event is met, determining the event transaction list corresponding to the cross-committee event as a target transaction list, determining a target transaction request based on the target transaction list, and submitting and executing the target transaction request within the committee. The process involves: locking the relevant account for the target transaction request; designating the committee as the source committee and sending a first cross-committee request message to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, generating a second cross-committee message which is then sent to the source committee and the target committee respectively. Upon receiving the second cross-committee message, either the first or second sub-transaction request is executed. After each transaction execution condition for an event within the committee is met, the event transaction list corresponding to the event within the committee is determined as the target transaction list. Based on this target transaction list, the target transaction request is determined, submitted, and executed within the committee. Through these steps, cross-committee processes can be executed through both on-chain and off-chain systems after each cross-committee event's transaction execution condition is met; conversely, after each on-chain event's transaction execution condition is met, on-chain processes can be executed directly in the off-chain system. This allows for optimal performance of the blockchain system by balancing on-chain and off-chain workloads. Furthermore, this solution utilizes a committee-based approach to achieve lightweight off-chain processing, making it suitable for computationally constrained environments such as the Internet of Things (IoT). Attached Figure Description
[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:
[0019] Figure 1 This is a flowchart of a trusted on-chain and off-chain data interaction method in a blockchain system according to an embodiment of the present invention;
[0020] Figure 2 This is a schematic diagram of the cross-committee transaction process in an embodiment of the present invention;
[0021] Figure 3 This is a schematic diagram of the intra-committee transaction process in an embodiment of the present invention;
[0022] Figure 4 This is a flowchart of the rental management process in an embodiment of the present invention;
[0023] Figure 5 This is a schematic diagram of the structure of the on-chain and off-chain data trusted interaction device in the blockchain system according to an embodiment of the present invention;
[0024] Figure 6 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation
[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.
[0026] First, the terminology involved in this invention will be explained.
[0027] Common coin: This method achieves a consensus mechanism with random coin tossing, ensuring that each honest node tosses the same value. This embodiment of the invention assumes that the common coin toss returns a proof σ. In practice, a threshold signature algorithm can be used to implement σ.
[0028] Digital signature: Signing a message to make it unforgeable. A certain number of signatures with a certain threshold is called a quorum certificate (QC).
[0029] Hash: Calculate a hash digest of a message. This embodiment of the invention assumes the implementation of a collision-free hash function.
[0030] Vector clocks: Vector clocks determine the order of events, but there is no global overall order. This embodiment of the invention assumes that on-chain nodes maintain a vector clock to coordinate cross-committee transactions.
[0031] Atomic broadcast (ABC): A fundamental primitive in distributed computing, in a system of multiple processes using atomic broadcast, all correct processes will receive the same message in the same order.
[0032] Figure 1This is a flowchart of a trusted on-chain and off-chain data interaction method in a blockchain system according to an embodiment of the present invention. The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The method is applied to any committee node of any committee, including:
[0033] Step 101: Based on the transaction request sent by the user, determine the event triggered by the committee node, and add the transaction request to the event transaction list corresponding to the event. The event includes cross-committee events and intra-committee events.
[0034] Step 102: After each cross-committee event transaction execution condition is met, the event transaction list corresponding to the cross-committee event is determined as the target transaction list. A target transaction request is determined based on the target transaction list, submitted and executed within the committee. The relevant account for the target transaction request is locked. The committee is designated as the source committee, and a first cross-committee request message is sent to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message which is then sent to the source committee and the target committee respectively. Upon receiving the second cross-committee message, the first sub-transaction request or the second sub-transaction request in the second cross-committee message is executed.
[0035] Step 103: After each transaction execution condition of an event within the committee is met, the event transaction list corresponding to the event within the committee is determined as the target transaction list. The target transaction request is determined based on the target transaction list and submitted and executed within the committee.
[0036] In this embodiment of the invention, after each transaction execution condition for a cross-committee event is met, the cross-committee process can be executed through both the on-chain and off-chain systems; while after each transaction execution condition for an intra-committee event is met, the intra-committee process can be executed directly on the off-chain system; thus, the optimal performance of the blockchain system can be achieved by balancing the on-chain and off-chain workloads; in addition, this solution is based on a committee-based method to achieve lightweight off-chain implementation, making this solution suitable for computationally constrained environments such as the Internet of Things (IoT).
[0037] Each step is described in detail below.
[0038] The embodiments of this invention assume a semi-synchronous network, and the blockchain system can use an account model or a UTXO model.
[0039] Each committee consists of a set of committee nodes, each with its own fault model and executing a dedicated protocol.
[0040] In research on blockchain scalability, a blockchain system comprises two layers: an on-chain system and an off-chain system, also known as the main chain system and the off-chain system. In this embodiment of the invention, it is assumed that the on-chain system contains n consensus nodes, of which at most f are Byzantine fault nodes. The off-chain system has multiple committees C1, C2, ..., each containing m committee nodes and at most t Byzantine fault nodes.
[0041] The embodiments of the present invention use To represent the consensus nodes in an on-chain system, the on-chain system is treated as a black box, assuming its consensus nodes execute the Atomic Broadcast (ABC) protocol. Off-chain systems assume all committee nodes know the identities of other committee nodes within the same committee, using... Let denot i in Cj be a committee node. Any two committee nodes communicate through a certified channel. A public key infrastructure is assumed, where each committee node has a publicly verifiable public key. Each committee has a leader node, whose identity is known to all committee nodes during blockchain system initialization.
[0042] In off-chain system committee nodes, an intra-committee transaction refers to a transaction assigned to only one committee, while a cross-committee transaction refers to a transaction involving more than one committee. Without loss of generality, this embodiment of the invention considers a cross-committee transaction involving only two committees at a time, namely the source committee and the target committee. The cross-committee transaction request is first submitted to the source committee, and the transaction is ultimately divided into two sub-transaction requests, which are delivered to the two committees for execution respectively.
[0043] In the on-chain nodes, each leader can propose a maximum of a preset number of blocks, and this period can be defined as a lease period. Each off-chain system committee node monitors its local event transaction queue (similar to the traditional BFT protocol) and sets a timer.
[0044] Vector clocks are used in cross-committee trading processes to manage the order of each committee, enabling low latency and fast confirmation of cross-committee transactions.
[0045] In this embodiment of the invention, each node needs to maintain the following local variables locally:
[0046] Local round lseq: that is, local sequence, represents the highest sequence that has recently achieved consensus locally, initialized to 1;
[0047] Global sequence (gseq): representing the latest highest-level sequence that has reached consensus globally, initialized to 1;
[0048] Committee vector clock G: for any node on the chain It maintains a set of vector clocks Gi = {g1, g2, ...} for all committees in the off-chain layer. The length of Gi, |Gi|, is the total number of off-chain committees. Gi[j] = gj represents the vector clock of off-chain committee Cj, and each Cj only maintains its own clock gj.
[0049] Highest Quota Certificate (hQC): The committee node stores the certificate of the current quorum, which is the highest quorum certificate. It is initialized to empty.
[0050] Transaction queue Q: The transaction queue to be processed in the blockchain system. In this embodiment of the invention, different triggered events correspond to different event transaction lists.
[0051] In step 101, based on the transaction request sent by the user, the event triggered by the committee node is determined, and the transaction request is added to the event transaction list corresponding to the event. The event includes cross-committee events and intra-committee events.
[0052] The list of event transactions is stored locally on the leader node of the committee.
[0053] In one embodiment, the transaction request includes a transaction message identifier Request, a user identifier c, an index e of the source committee, a timestamp ts, and transaction content o;
[0054] Based on the transaction request sent by the user, determine the event triggered by the committee node, including: determining the committee involved in the transaction request based on the transaction content in the transaction request;
[0055] If the transaction request involves only one committee, the event triggered by the committee node is determined to be an in-committee event;
[0056] Otherwise, the event triggered by the committee node is determined to be a cross-committee event, and the committee node is designated as the source committee, while other committees involved in the transaction request are designated as target committees.
[0057] Specifically, for any node in committee Ce Received a transaction request tx = (Request, c, e, ts, o) from the user client.
[0058] if The triggered event is an intra-committee event. The transaction request (tx) is added to the event transaction list corresponding to the intra-committee event. The triggered event is a cross-committee event, and the transaction request tx is added to the event transaction list corresponding to the cross-committee event.
[0059] In step 102, after each transaction execution condition of a cross-committee event is met, the event transaction list corresponding to the cross-committee event is determined as the target transaction list. A target transaction request is determined based on the target transaction list, submitted and executed within the committee. The relevant account for the target transaction request is locked. The committee is designated as the source committee, and a first cross-committee request message is sent to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message which is then sent to the source committee and the target committee respectively. Upon receiving the second cross-committee message, either the first sub-transaction request or the second sub-transaction request in the second cross-committee message is executed.
[0060] Step 102 pertains to the cross-committee transaction process. Figure 2 This is a schematic diagram of the cross-committee transaction process in an embodiment of the present invention. Figure 2 The inter-committee transaction process involves intra-committee transaction processes, the sending of the first inter-committee request, and inter-committee processing. Specifically, determining the target transaction request based on the target transaction list, and submitting and executing the target transaction request within the committee, constitutes the intra-committee transaction process. Figure 3 This is a schematic diagram of the intra-committee transaction process in an embodiment of the present invention, wherein P0, P1, P2, and P3 are committee nodes.
[0061] In one embodiment, determining a target transaction request based on the target transaction list, submitting and executing the target transaction request within the committee includes:
[0062] If the committee node is the responsible node, it generates a local message based on the target transaction list and sends it to all committee nodes of the committee;
[0063] After receiving a local message from the responsible node, a reply message is sent to the responsible node. Based on the quorum certificate in the local message, the target block is determined, the target transaction requests in the target block are obtained, and all target transaction requests are submitted and executed in sequence.
[0064] If the committee node is the responsible node, after receiving the same reply message of the first number mt, the local highest quorum certificate of the committee is updated according to the signature of the quorum in all reply messages.
[0065] Specifically, if It is the responsible node in the committee Ce and needs to generate local messages.
[0066] In one embodiment, generating a local message based on the target transaction list includes:
[0067] When the target transaction queue is not empty, take a batch of transaction requests from the target transaction queue to form a transaction request set b, and increment the current local round lseq by 1.
[0068] Based on the transaction request set, a local message is generated, which includes the local message identifier Local, the committee index e, the current local round lseq, the global round gseq, the transaction request set b, and the highest quorum certificate hQC.
[0069] Specifically, A batch of transaction requests is intercepted and formed into a transaction request set b. Then, a local message (Local, e, lseq, gseq, b, hQC) is sent to all committee nodes in committee Ce.
[0070] If the committee node is not the leader node, after receiving a local message from the leader node, it sends a reply message to the leader node. The leader node receives mt identical reply messages (Rep,e,h,σj), where σj is the signature of mt quorum members; based on the quorum signatures in all reply messages, it packages all signatures into a quorum certificate to update the committee's local highest quorum certificate hQC.
[0071] In one embodiment, after receiving a local message from the responsible node, a reply message is sent to the responsible node. Based on the quorum certificate in the local message, the target block is determined, the target transaction requests in the target block are obtained, and all target transaction requests are submitted and executed sequentially, including:
[0072] After receiving a local message from the responsible node, check whether the quorum certificate qc in the local message conflicts with the highest local quorum certificate hQC, and check whether the global round number in the local message is equal to the round number in the quorum certificate in the local message plus 1;
[0073] If so, update the local highest quorum certificate hQC to the quorum certificate in the local message, and update the local round lseq to the round in the quorum certificate in the local message; at the same time, back up the local message, and calculate the first hash value h based on the hash value of the quorum certificate in the local message, the index e of the committee, the current local round, the global round, and the transaction request set; h = Hash(e,ls,gs,b,Hash(qc)); Hash(qc) is the hash of qc;
[0074] Send a reply message (Rep, e, h, σi) to the responsible node. The reply message includes the identifier Rep, the index e of the committee to which it belongs, the first hash value h, and the quorum certificate σi of the first hash value h.
[0075] Retrieve the highest block in the quorum certificate qc in the local message and all uncommitted parent blocks in the quorum certificate qc in the local message as the target block;
[0076] Obtain the target transaction requests in the target block, and submit and execute all target transaction requests in sequence.
[0077] In one embodiment, locking the relevant account for the target transaction request includes:
[0078] If the committee node is not the responsible node, upon receiving a local message, it sets the availability certificate ac to a digital signature of the hash of all transaction requests for the first number of mt.
[0079] After all target transaction requests have been submitted, lock all accounts associated with the target transaction requests.
[0080] exist After completing the above steps, send the first cross-committee request message (X-Com-Req, e, d, txa, ac) to all nodes on the chain, where X-Com-Req is the first cross-committee request message, e is the source committee Ce (i.e., The index of the committee to which it belongs, d is the index of the target committee Cd, and ac is the digital signature of mt Hash(txa);
[0081] In one embodiment, the first cross-committee request message includes an identifier of the first cross-committee request message, an index e of the source committee, an index d of the target committee, a target transaction request, and an availability certificate ac;
[0082] consensus nodes of on-chain systems The transaction request in the first cross-committee request message is divided into a first sub-transaction request and a second sub-transaction request. A second cross-committee message is then generated and sent to the source committee and the target committee respectively, including:
[0083] The consensus node of the on-chain system determines whether the first cross-committee request message meets the first condition. The first condition is that the digital signature in the first cross-committee request message is valid, and the index e of the source committee and the index d of the target committee are correct.
[0084] If so, update the vector clock of the source committee and the vector clock of the target committee;
[0085] The transaction request in the first cross-committee request message is divided into a first sub-transaction request and a second sub-transaction request.
[0086] Based on the first sub-transaction request and the second sub-transaction request, a second cross-committee message is generated and sent to the source committee and the target committee respectively. The second cross-committee message includes an identifier of the second cross-committee message, the first sub-transaction request, the second sub-transaction request, the vector clock of the source committee, the vector clock of the target committee, and a digital signature of the hash value of the transaction request of a first quantity mt.
[0087] The above embodiments are for consensus nodes of any on-chain system. Determine whether the first cross-committee request message satisfies the first condition. If so, update the vector clock Gi[e] = Gi[e] + 1 of the source committee and the vector clock Gi[e] = Gi[e] + 1 of the target committee. Then, divide txa into the first sub-transaction request txe and the second sub-transaction request txd, and send cross-committee messages (X-Com, txe, txd, Gi[e], Gi[d], ac) to Ce and Cd respectively.
[0088] In one embodiment, upon receiving a second cross-committee message, executing either the first sub-transaction request or the second sub-transaction request in the second cross-committee message includes:
[0089] Upon receiving the second, f+1, identical cross-committee message from the consensus nodes of the on-chain system, the following operations are performed:
[0090] If the committee node belongs to the source committee, and if the vector clock of the source committee in the second cross-committee message is equal to the local vector clock of the source committee plus 1, then execute the first sub-transaction request, unlock the relevant account of the first sub-transaction request, and update the local vector clock of the source committee to the vector clock of the source committee in the second cross-committee message.
[0091] If the committee node belongs to the target committee, and if the target committee's vector clock in the second cross-committee message is equal to the target committee's local vector clock plus 1, then execute the second sub-transaction request to update the target committee's local vector clock to the target committee's vector clock in the second cross-committee message.
[0092] Specifically, for any node in the source committee Ce Or nodes in the target committee Cd When f+1 identical second cross-committee messages (X-Com, txe, txd, Gi[e], Gi[d], ac) are received from the on-chain system, the following operations are performed: For If Gi[e] equals the local gseq plus 1, then execute txe to unlock the txe-related account and update the local gseq = Gi[e]; for If Gi[d] equals the local gseq plus 1, then execute txd to update the local gseq = Gi[d].
[0093] In step 103, after each transaction execution condition of an event within the committee is met, the event transaction list corresponding to the event within the committee is determined as the target transaction list, the target transaction request is determined according to the target transaction list, and the target transaction request is submitted and executed within the committee.
[0094] Step 103 is the intra-committee trading process, which is the same as the intra-committee trading process in step 102, and will not be described again here.
[0095] In addition, this invention also proposes a lease management process to handle situations where the committee may have erroneous nodes exceeding a threshold, thereby threatening transaction security or activity.
[0096] Figure 4 This is a flowchart of the rental management process in an embodiment of the present invention. In one embodiment, the method further includes:
[0097] Step 401, (for any off-chain system committee node) If a predetermined number of target block transaction requests have been executed, but the committee's timer has not expired, a checkpoint request is submitted to all consensus nodes on the chain. The checkpoint request (Checkpoint, e, i, v, s, hQC) includes the checkpoint identifier Checkpoint, the committee index e, the current lease period v, the committee node identifier i, the hash s of the status of the committee's local transaction requests, and the highest quorum certificate hQC.
[0098] Step 402: If the timer of the committee expires, submit a view switching request to all consensus nodes on the chain. The view switching request (Blame, e, i, v, hQC) includes the identifier Blame of the view switching request, the index e of the committee, the identifier i of the committee node, the lease period v of this round, and the highest quorum certificate hQC.
[0099] Step 403: Stop participating in consensus among all committees until a second number f+1 lease request messages are received from the consensus nodes of the on-chain system. The lease request message (Lease,e,gseq,v') includes the identifier Lease, the index e of the committee, the global round gseq, and the lease period v' of the current round.
[0100] Step 404: Based on the second number of lease request messages f+1, determine whether to continue participating in the consensus among committee members.
[0101] In one embodiment, the method further includes:
[0102] (for any consensus node in an on-chain system) During each lease period, if the consensus node of the on-chain system has received the third number of 2t+1 view switching requests, it enters the next lease period and increments the current lease period by 1 (i.e., v' = v+1), and sends a lease request (Lease, e, gseq, v') to all committee nodes of all committees.
[0103] If the consensus node of the on-chain system has received the same checkpoint request for a third time (2t+1), the lease term will continue for the current round (i.e., v' = v), and a lease request (Lease, e, gseq, v') will be sent to all committee nodes of all committees.
[0104] In one embodiment, determining whether to continue participating in the consensus process among committee members based on a second number of lease request messages of f+1 includes:
[0105] If the current lease term v' in the lease request message is equal to the current lease term v (v' = v), update the current lease term to the current lease term v = v' in the lease request message, and continue to participate in the consensus among committee members;
[0106] If the current lease period v' in the lease request message is greater than the current lease period v (v'>v), obtain all view switching requests for the current lease period (at least mt), set the highest quorum certificate hQC to the quorum certificate qc with the highest block height in the view switching request, set the local round lseq to the round in the quorum certificate c with the highest block height in the view switching request, and continue to participate in the consensus among committees.
[0107] This invention also proposes a trusted on-chain and off-chain data interaction device in a blockchain system. Its principle is similar to that of the trusted on-chain and off-chain data interaction method in a blockchain system, and will not be described in detail here.
[0108] Figure 5 This is a schematic diagram of an on-chain and off-chain data trusted interaction device in a blockchain system according to an embodiment of the present invention. The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The device is applied to any committee node of any committee and includes:
[0109] The transaction request receiving module 501 is used to determine the event triggered by the committee node based on the transaction request sent by the user, and add the transaction request to the event transaction list corresponding to the event, wherein the event includes cross-committee events and intra-committee events;
[0110] The cross-committee processing module 502 is used to determine the event transaction list corresponding to the cross-committee event as the target transaction list after each transaction execution condition of the cross-committee event is met, call the cross-committee processing module 503, determine the target transaction request according to the target transaction list, submit and execute the target transaction request within the committee; lock the relevant account of the target transaction request; use the committee as the source committee, send a first cross-committee request message to all consensus nodes of the on-chain system, so that the consensus nodes divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message and send it to the source committee and the target committee respectively; after receiving the second cross-committee message, execute the first sub-transaction request or the second sub-transaction request in the second cross-committee message;
[0111] The cross-committee processing module 503 is used to determine the event transaction list corresponding to the event within the committee as the target transaction list after each transaction execution condition of the event within the committee is met, determine the target transaction request according to the target transaction list, and submit and execute the target transaction request within the committee.
[0112] In one embodiment, the transaction request includes an identifier for the transaction message, a user identifier, an index of the source committee, a timestamp, and transaction content;
[0113] The transaction request receiving module is used to: determine the committee involved in the transaction request based on the transaction content in the transaction request;
[0114] If the transaction request involves only one committee, the event triggered by the committee node is determined to be an in-committee event;
[0115] Otherwise, the event triggered by the committee node is determined to be a cross-committee event, and the committee node is designated as the source committee, while other committees involved in the transaction request are designated as target committees.
[0116] In one embodiment, the committee processing module is used for:
[0117] If the committee node is the responsible node, it generates a local message based on the target transaction list and sends it to all committee nodes of the committee;
[0118] After receiving a local message from the responsible node, a reply message is sent to the responsible node. Based on the quorum certificate in the local message, the target block is determined, the target transaction requests in the target block are obtained, and all target transaction requests are submitted and executed in sequence.
[0119] If the committee node is the responsible node, after receiving the first number of identical reply messages, the local highest quorum certificate of the committee is updated according to the signatures of the quorum in all reply messages.
[0120] In one embodiment, the committee processing module is used for:
[0121] When the target transaction queue is not empty, take a batch of transaction requests from the target transaction queue to form a transaction request set b, and increment the current local round lseq by 1.
[0122] Based on the transaction request set, a local message is generated, which includes a local message identifier, the committee's index e, the current local round, the global round, the transaction request set, and the highest quorum certificate.
[0123] In one embodiment, the committee processing module is used for:
[0124] After receiving a local message from the responsible node, check whether the quorum certificate qc in the local message conflicts with the highest local quorum certificate hQC, and check whether the global round number in the local message is equal to the round number in the quorum certificate in the local message plus 1;
[0125] If so, update the local highest quorum certificate hQC to the quorum certificate in the local message, and update the local round lseq to the round in the quorum certificate in the local message; at the same time, back up the local message, and calculate the first hash value h based on the hash value of the quorum certificate in the local message, the index e of the committee, the current local round, the global round, and the transaction request set;
[0126] Send a reply message (Rep,e,h,σi) to the responsible node. The reply message includes the identifier of the reply message, the index of the committee to which it belongs, the first hash value, and the quorum certificate σi of the first hash value.
[0127] Retrieve the highest block in the quorum certificate in the local message and all uncommitted parent blocks in the quorum certificate in the local message as the target block;
[0128] Obtain the target transaction requests in the target block, and submit and execute all target transaction requests in sequence.
[0129] In one embodiment, the cross-committee processing module is used for:
[0130] If the committee node is not the responsible node, upon receiving a local message, it sets the availability certificate ac to a digital signature of the hash of all transaction requests for the first number of mt.
[0131] After all target transaction requests have been submitted, lock all accounts associated with the target transaction requests.
[0132] In one embodiment, the first cross-committee request message includes an identifier of the first cross-committee request message, an index e of the source committee, an index d of the target committee, a target transaction request, and an availability certificate;
[0133] The cross-committee processing module is used for:
[0134] The consensus node of the on-chain system determines whether the first cross-committee request message meets the first condition. The first condition is that the digital signature in the first cross-committee request message is valid, and the index e of the source committee and the index d of the target committee are correct.
[0135] If so, update the vector clock of the source committee and the vector clock of the target committee;
[0136] The transaction request in the first cross-committee request message is divided into a first sub-transaction request and a second sub-transaction request.
[0137] Based on the first sub-transaction request and the second sub-transaction request, a second cross-committee message is generated and sent to the source committee and the target committee respectively. The second cross-committee message includes an identifier of the second cross-committee message, the first sub-transaction request, the second sub-transaction request, the vector clock of the source committee, the vector clock of the target committee, and a digital signature of the hash value of the transaction request of a first quantity mt.
[0138] In one embodiment, the cross-committee processing module is used for:
[0139] Upon receiving the second, f+1, identical cross-committee message from the consensus nodes of the on-chain system, the following operations are performed:
[0140] If the committee node belongs to the source committee, and if the vector clock of the source committee in the second cross-committee message is equal to the local vector clock of the source committee plus 1, then execute the first sub-transaction request, unlock the relevant account of the first sub-transaction request, and update the local vector clock of the source committee to the vector clock of the source committee in the second cross-committee message.
[0141] If the committee node belongs to the target committee, and if the target committee's vector clock in the second cross-committee message is equal to the target committee's local vector clock plus 1, then execute the second sub-transaction request to update the target committee's local vector clock to the target committee's vector clock in the second cross-committee message.
[0142] In one embodiment, the device further includes a rental management module 504, used for:
[0143] If a preset number of target block transaction requests have been executed, but the committee's timer has not expired, a checkpoint request is submitted to all consensus nodes on the chain. The checkpoint request includes the checkpoint request identifier, the committee index, the current lease period, the committee node identifier, the hash of the status of the committee's local transaction requests, and the highest quorum certificate.
[0144] If the committee's timer expires, it submits a view switching request to all consensus nodes on the chain. The view switching request includes the identifier of the view switching request, the index of the committee, the committee node identifier, the lease period for this round, and the maximum quorum certificate.
[0145] Stop participating in consensus among all committees until a second number of lease request messages are received from consensus nodes on the chain, the lease request message including the identifier of the lease request message, the index of the committee, the global round, and the lease period of the current round;
[0146] Based on the second number of lease request messages, determine whether to continue participating in the consensus-building process among committee members.
[0147] In one embodiment, the lease management module 504 is further configured to:
[0148] During each lease period, if the consensus node of the on-chain system has received the third number of 2t+1 view switching requests, it enters the next lease period and increments the current lease period by 1, and sends a lease request to all committee nodes of all committees.
[0149] If the consensus node of the on-chain system has received the same checkpoint request for a third time (2t+1), it will continue to lease the lease for the current lease period and send the lease request to all committee nodes of all committees.
[0150] In one embodiment, the lease management module 504 is further configured to:
[0151] If the current lease term in the lease request message is equal to the current lease term, update the current lease term to the current lease term in the lease request message, and continue to participate in the consensus among committee members;
[0152] If the current lease period in the lease request message is longer than the current lease period, retrieve all view switching requests for the current lease period, set the highest quorum certificate to the quorum certificate with the highest block height in the view switching request, set the local round number lseq to the round number in the quorum certificate with the highest block height in the view switching request, and continue to participate in the consensus among committee members.
[0153] In summary, in the method and apparatus proposed in this invention, the blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The method is applied to any committee node of any committee and includes: determining an event triggered by the committee node based on a transaction request sent by a user, and adding the transaction request to the event transaction list corresponding to the event, wherein the event includes cross-committee events and intra-committee events; after each transaction execution condition of a cross-committee event is met, determining the event transaction list corresponding to the cross-committee event as a target transaction list, determining a target transaction request based on the target transaction list, and submitting and executing it within the committee. The process involves: 1) Requesting a target transaction; 2) Locking the relevant account for the target transaction request; 3) Using the committee as the source committee, sending a first cross-committee request message to all consensus nodes in the on-chain system, causing the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generating a second cross-committee message which is then sent to the source committee and the target committee respectively; 4) Upon receiving the second cross-committee message, executing either the first or second sub-transaction request in the second cross-committee message; 5) After each transaction execution condition of an event within the committee is met, determining the event transaction list corresponding to the event within the committee as the target transaction list, determining the target transaction request based on the target transaction list, and submitting and executing the target transaction request within the committee. Through these steps, cross-committee processes can be executed through both on-chain and off-chain systems after each transaction execution condition of a cross-committee event is met; and after each transaction execution condition of an event within the committee is met, the process within the committee can be executed directly in the off-chain system; thus, optimal performance of the blockchain system is achieved by balancing on-chain and off-chain workloads; furthermore, this solution is based on a committee-based approach to achieve lightweight off-chain processing, making it suitable for computationally constrained environments such as the Internet of Things (IoT).
[0154] This invention also provides a computer device. Figure 6 This is a schematic diagram of a computer device in an embodiment of the present invention. The computer device 600 includes a memory 610, a processor 620, and a computer program 630 stored in the memory 610 and executable on the processor 620. When the processor 620 executes the computer program 630, it implements the on-chain and off-chain data trusted interaction method in the above-mentioned blockchain system.
[0155] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for trusted on-chain and off-chain data interaction in a blockchain system.
[0156] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described method for trusted on-chain and off-chain data interaction in the blockchain system.
[0157] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0158] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0159] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0160] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0161] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for trusted on-chain and off-chain data interaction in a blockchain system, characterized in that, The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The method is applied to any committee node of any committee, including: Based on the transaction request sent by the user, determine the event triggered by the committee node, and add the transaction request to the event transaction list corresponding to the event. The event includes cross-committee events and intra-committee events. After each cross-committee event's transaction execution conditions are met, the event transaction list corresponding to the cross-committee event is determined as the target transaction list. A target transaction request is then determined based on this list, submitted, and executed within the committee. The relevant account for the target transaction request is locked. The committee is designated as the source committee, and a first cross-committee request message is sent to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and generate a second cross-committee message, which is then sent to the source committee and the target committee respectively. Upon receiving the second cross-committee message, either the first sub-transaction request or the second sub-transaction request in the second cross-committee message is executed. After each transaction execution condition of an event within the committee is met, the event transaction list corresponding to the event within the committee is determined as the target transaction list. The target transaction request is determined based on the target transaction list and submitted and executed within the committee.
2. The method as described in claim 1, characterized in that, The transaction request includes the transaction message identifier, user identifier, source committee index, timestamp, and transaction content; Based on the transaction request sent by the user, determine the event triggered by the committee node, including: determining the committee involved in the transaction request based on the transaction content in the transaction request; If the transaction request involves only one committee, the event triggered by the committee node is determined to be an in-committee event; Otherwise, the event triggered by the committee node is determined to be a cross-committee event, and the committee node is designated as the source committee, while other committees involved in the transaction request are designated as target committees.
3. The method as described in claim 1, characterized in that, Based on the target transaction list, target transaction requests are determined, submitted to the committee, and executed, including: If the committee node is the responsible node, it generates a local message based on the target transaction list and sends it to all committee nodes of the committee; After receiving a local message from the responsible node, a reply message is sent to the responsible node. Based on the quorum certificate in the local message, the target block is determined, the target transaction requests in the target block are obtained, and all target transaction requests are submitted and executed in sequence. If the committee node is the responsible node, after receiving the first number of identical reply messages, the local highest quorum certificate of the committee is updated according to the signatures of the quorum in all reply messages.
4. The method as described in claim 3, characterized in that, Based on the target transaction list, generate local messages, including: When the target transaction queue is not empty, a batch of transaction requests is taken from the target transaction queue to form a transaction request set, and the current local round number is incremented by 1. Based on the transaction request set, a local message is generated, which includes a local message identifier, the index of the committee, the current local round, the global round, the transaction request set, and the highest quorum certificate.
5. The method as described in claim 3, characterized in that, Upon receiving a local message from the responsible node, a reply message is sent to the responsible node. Based on the quorum certificate in the local message, the target block is determined, the target transaction requests in the target block are obtained, and all target transaction requests are submitted and executed sequentially, including: Upon receiving a local message from the responsible node, check whether the quorum certificate in the local message conflicts with the highest local quorum certificate, and check whether the global round number in the local message is equal to the round number in the quorum certificate in the local message plus 1; If so, update the local highest quorum certificate to the quorum certificate in the local message, and update the local round to the round in the quorum certificate in the local message; at the same time, back up the local message, and calculate the first hash value based on the hash value of the quorum certificate in the local message, the index of the committee, the current local round, the global round, and the transaction request set; A reply message is sent to the responsible node, the reply message including the identifier of the reply message, the index of the committee to which it belongs, the first hash value, and the quorum certificate of the first hash value; Retrieve the highest block in the quorum certificate in the local message and all uncommitted parent blocks in the quorum certificate in the local message as the target block; Obtain the target transaction requests in the target block, and submit and execute all target transaction requests in sequence.
6. The method as described in claim 4, characterized in that, The accounts associated with the target transaction request are locked, including: If the committee node is not the responsible node, upon receiving a local message, it sets the availability certificate to a digital signature of the hash of the first number of all transaction requests. After all target transaction requests have been submitted, lock all accounts associated with the target transaction requests.
7. The method as described in claim 1, characterized in that, The first cross-committee request message includes the identifier of the first cross-committee request message, the index of the source committee, the index of the target committee, the target transaction request, and the availability certificate; The consensus nodes of the on-chain system divide the transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, and then generate a second cross-committee message which is sent to the source committee and the target committee respectively, including: The consensus node of the on-chain system determines whether the first cross-committee request message meets the first condition. The first condition is that the digital signature in the first cross-committee request message is valid, and the index of the source committee and the index d of the target committee are correct. If so, update the vector clock of the source committee and the vector clock of the target committee; The transaction request in the first cross-committee request message is divided into a first sub-transaction request and a second sub-transaction request. Based on the first sub-transaction request and the second sub-transaction request, a second cross-committee message is generated and sent to the source committee and the target committee respectively. The second cross-committee message includes an identifier of the second cross-committee message, the first sub-transaction request, the second sub-transaction request, the vector clock of the source committee, the vector clock of the target committee, and a digital signature of the hash value of the transaction request of a first quantity mt.
8. The method as described in claim 1, characterized in that, Upon receiving the second cross-committee message, execute either the first sub-transaction request or the second sub-transaction request in the second cross-committee message, including: Upon receiving the second number of identical second cross-committee messages from the consensus nodes of the on-chain system, the following operations are performed: If the committee node belongs to the source committee, and if the vector clock of the source committee in the second cross-committee message is equal to the local vector clock of the source committee plus 1, then execute the first sub-transaction request, unlock the relevant account of the first sub-transaction request, and update the local vector clock of the source committee to the vector clock of the source committee in the second cross-committee message. If the committee node belongs to the target committee, and if the target committee's vector clock in the second cross-committee message is equal to the target committee's local vector clock plus 1, then execute the second sub-transaction request to update the target committee's local vector clock to the target committee's vector clock in the second cross-committee message.
9. The method as described in claim 1, characterized in that, Also includes: If a preset number of target block transaction requests have been executed, but the committee's timer has not expired, a checkpoint request is submitted to all consensus nodes on the chain. The checkpoint request includes the checkpoint request identifier, the committee index, the current lease period, the committee node identifier, the hash of the status of the committee's local transaction requests, and the highest quorum certificate. If the committee's timer expires, it submits a view switching request to all consensus nodes on the chain. The view switching request includes the identifier of the view switching request, the index of the committee, the committee node identifier, the lease period for this round, and the maximum quorum certificate. Stop participating in consensus among all committees until a second number of lease request messages are received from consensus nodes on the chain, the lease request message including the identifier of the lease request message, the index of the committee, the global round, and the lease period of the current round; Based on the second number of lease request messages, determine whether to continue participating in the consensus-building process among committee members.
10. The method as described in claim 9, characterized in that, Also includes: During each lease period, if the consensus node of the on-chain system has received the third number of view switching requests, it enters the next lease period and increments the current lease period by 1, and sends a lease request to all committee nodes of all committees; If the consensus node of the on-chain system has received a third number of identical checkpoint requests, the lease term will continue, and the lease request will be sent to all committee nodes of all committees.
11. The method as described in claim 9, characterized in that, Based on the second number of lease request messages, determine whether to continue participating in the committee's consensus process, including: If the current lease term in the lease request message is equal to the current lease term, update the current lease term to the current lease term in the lease request message, and continue to participate in the consensus among committee members; If the current lease period in the lease request message is longer than the current lease period, retrieve all view switching requests for the current lease period, set the highest quorum certificate to the quorum certificate with the highest block height in the view switching request, set the local round to the round in the quorum certificate with the highest block height in the view switching request, and continue to participate in the consensus among committee members.
12. A trusted on-chain and off-chain data interaction device in a blockchain system, characterized in that, The blockchain system includes an on-chain system and an off-chain system. The on-chain system includes multiple consensus nodes, and the off-chain system includes multiple committees, each committee including multiple committee nodes. The device is applied to any committee node of any committee, including: The transaction request receiving module is used to determine the event triggered by the committee node based on the transaction request sent by the user, and add the transaction request to the event transaction list corresponding to the event, wherein the event includes cross-committee events and intra-committee events; The cross-committee processing module is used to determine the event transaction list corresponding to the cross-committee event as the target transaction list after each transaction execution condition is met. It then calls the cross-committee processing module to determine the target transaction request based on the target transaction list, submits and executes the target transaction request within the committee, locks the relevant account for the target transaction request, uses the committee as the source committee, and sends a first cross-committee request message to all consensus nodes in the on-chain system. This causes the consensus nodes to divide the target transaction request in the first cross-committee request message into a first sub-transaction request and a second sub-transaction request, generate a second cross-committee message, and send it to the source committee and the target committee respectively. Upon receiving the second cross-committee message, it executes either the first sub-transaction request or the second sub-transaction request in the second cross-committee message. The cross-committee processing module is used to determine the event transaction list corresponding to the event within the committee as the target transaction list after each transaction execution condition of the event within the committee is met, determine the target transaction request based on the target transaction list, and submit and execute the target transaction request within the committee.
13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 11.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.
15. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 11.