A Method for Ensuring the Consistency of Complex Assets Supporting Multiple Protocols between On-chain and Off-chain

Abstract

The present invention relates to a method for ensuring the consistency of complex assets supporting multiple protocols on and off the chain. This application establishes an account-asset relationship representation model for multi-ownership and multi-dimensional complex assets; for complex asset transactions, verification nodes, on-chain execution nodes, shunt nodes, and off-chain nodes cooperate to perform collaborative transaction execution on and off the chain, including: the verification node group determines the legality of the transaction request; for legal transaction requests, the on-chain shunt node group and the off-chain execution node representatives conduct a Stackelberg game based on the transaction benefits, and divide the transactions in the transaction pool among the on-chain or off-chain execution nodes; the on-chain and off-chain execution nodes adjust the conflict determination granularity according to the consistency requirements, and select the linear consistency or sequential consistency protocol to perform parallel execution between the on-chain and off-chain transactions; according to the execution status of the on-chain and off-chain verified transactions, the information of the assets in the account-asset relationship representation model is merged to ensure the integrity and consistency of the assets.

Description

Technical Field

[0001] The present invention relates to the technical field of complex asset on-chain and off-chain transaction execution, and in particular to a method for ensuring the consistency of complex assets on-chain and off-chain that supports multiple protocols. Background Art

[0002] Blockchain has the characteristics of being distributed, immutable, and highly transparent, and is a new type of data management technology that can effectively realize the trust and verifiability of multi-party data. In recent years, emerging applications based on blockchain technology have gradually penetrated into all walks of life. The digital assets that blockchain needs to process and store have become richer in content and form, and the efficiency requirements for blockchain to process complex assets have also increased linearly. However, the computing and storage resources on the chain are limited, and the current blockchain technology is still difficult to achieve enterprise-level support for massive complex asset transactions.

[0003] To relieve the storage and transaction execution pressure on the chain, an off-chain channel is designed to transfer part of the storage and transaction execution pressure to the off-chain through the off-chain channel. The data consistency in the on-chain and off-chain collaboration process is ensured through protocols such as hash verification and "optimistic concurrency". However, most of these protocols are designed for token assets. The content ownership of token assets is relatively simple and single. For multi-rights and multi-dimensional complex assets with complex content and ownership, the current blockchain technology is difficult to support the on-chain and off-chain consistency collaboration. The reasons are as follows: First, it is unable to handle the complex ownership in collaboration. Each multi-rights and multi-dimensional complex asset has many stakeholders, and the stakeholders are associated with specific asset attributes. How to decompose the ownership structure of the asset and carry out off-chain collaboration has become a problem. For example, the optimistic concurrency protocol cannot accurately split and combine off-chain asset behaviors according to the asset ownership, resulting in large-scale conflicts that hinder the operation of the protocol. Second, the consistency control requirements are diverse. Assets have more fine-grained consistency control units such as multi-dimensional attributes. Based on different granularity consistency protocols applicable to different scenarios, how to be compatible with multiple consistency protocols has become a problem. For example, a single hash verification can determine the consistency of the overall asset, but it cannot accurately locate the conflict position. The version control based on locks can achieve fine-grained consistency, but the efficiency is much lower than that of hash verification.

[0004] Therefore, in the face of the transaction requirements of multi-rights and multi-dimensional complex assets, first, it is necessary to achieve the collaborative execution of on-chain and off-chain, break through the efficiency expansion bottleneck of pure on-chain execution. Second, it is necessary to ensure the data consistency in the on-chain and off-chain collaboration process, achieve the compatibility support for multiple types of consistency protocols, and ensure data security. Finally, it is necessary to reasonably balance and distribute the transactions between on-chain and off-chain to achieve further performance adaptability. Summary of the Invention

[0005] In order to solve the above technical problems or at least partially solve the above technical problems, the present invention provides a method for ensuring the consistency of complex assets on-chain and off-chain that supports multiple protocols.

[0006] In the first aspect, the present invention provides a method for ensuring consistency of complex assets on and off the chain supporting multiple protocols, which is applied to a massive transaction execution scenario of multi-ownership multi-dimensional complex assets in an on-chain and off-chain collaborative transaction system of a blockchain. The on-chain and off-chain collaborative transaction system is composed of on-chain nodes and off-chain nodes with computing and storage functions. In the on-chain and off-chain collaborative transaction system, the on-chain nodes are sorted according to the available resources of the on-chain nodes and the resource requirements of the blockchain, and the on-chain nodes are divided into verification nodes, on-chain execution nodes, diversion nodes and submission nodes according to the on-chain node sorting, and the off-chain nodes are cooperated to realize the transaction of multi-ownership multi-dimensional complex assets, including:

[0007] An account-asset relationship representation model for multi-ownership, multi-dimensional, complex assets is established through off-chain hypergraphs and on-chain node storage indexes. The account-asset relationship representation model includes an attribute status list, which provides corresponding locking and readable and writable states for asset granularity or asset attribute granularity. The legitimacy of the attribute status list is verified, and the locking and readable and writable states provided by the attribute status list, as well as the one-time readable and writable state authorization of the asset attribute granularity, only allow the modification of the corresponding asset attribute once to achieve linear consistency or sequential consistency control during the transaction process;

[0008] For complex asset transactions at the asset granularity or asset attribute granularity, verification nodes, on-chain execution nodes, diversion nodes and off-chain nodes cooperate to perform on-chain and off-chain collaborative transactions, including: accounts with multi-ownership and multi-dimensional complex asset-related permissions initiate transaction requests Tx to the on-chain and off-chain collaborative transaction system through the client req ; Verify the node group to determine the transaction request Tx req The legitimacy of the transaction pool is verified, and the verification includes verifying the attribute status list of the asset provided by the account-asset relationship representation model; for legal transaction requests, the on-chain diversion node group and the off-chain execution node representatives carry out the Stackelberg game based on the on-chain and off-chain transaction benefits, and divide the transactions in the transaction pool to the on-chain or off-chain execution nodes; the on-chain and off-chain execution nodes select the linear consistency or sequential consistency protocol based on the consistency requirements to carry out on-chain and off-chain parallel execution of the transaction;

[0009] The information of assets in the account-asset relationship representation model is merged based on the execution of complex asset transactions at the verified asset granularity or asset attribute granularity on the chain and off the chain to ensure asset integrity and consistency.

[0010] Furthermore, the account-asset relationship representation model of multi-ownership and multi-dimensional complex assets is established through the off-chain hypergraph and the on-chain node storage index, including:

[0011] Constructing accounts, representations of multi-ownership, multi-dimensional complex assets:

[0012] The account is represented by the account ID j , and the account address addr j : Account j = (ID j , addr j ).

[0013] The multi - ownership multi - dimensional complex asset is represented by the asset unique identifier e i , the asset attribute content, the attribute status list List_State, the transaction ID list List_Tx, and the asset version number and the list of holding accounts List_holders:

[0014]

[0015] The asset attributes of the multi - ownership multi - dimensional complex asset are represented as:

[0016] [(e i_1 , asset i_1 ), (e i_2 , asset i_2 ), ……, (e i_x , asset i_x )], where e i_x represents the asset attribute number, and asset i_x represents the asset attribute content corresponding to the asset attribute number;

[0017] Each asset attribute has two states, the normal state, represented by the number 1, and the normal state means that the asset attribute is readable and writable; the locked state, represented by the number 0, and the locked state means that the asset attribute is not readable and not writable: State ∈ {0, 1}, and the state set of the asset attributes constitutes the attribute status list List_State. Among them, the attribute status list of the asset is used to control the transaction conflict granularity and provide the locked and readable - writable state control to achieve linear consistency or sequential consistency;

[0018] Based on the representations of the account and the multi - ownership multi - dimensional complex asset, a relationship representation model of the account - asset of the multi - ownership multi - dimensional complex asset is established, where:

[0019] Under the chain, a hyper - graph is used to organize the relationship between accounts and assets. The account information exists in the vertices of the hyper - graph, and the asset information exists in the hyper - edges of the hyper - graph.

[0020] The off - chain hyper - graph is represented as:

[0021] G = {V, E, Ver G};

[0022] Among them, V = {Account 1, Account 2 ,...... Account j ,......} is the vertex set of the hypergraph, and the account Account j = (ID j , addr j ) is the vertex in the vertex set;

[0023] E = {Hedge 1 , Hedge 2 ,...... Hedge i ,......} is the hyperedge set of the hypergraph, and the hyperedge

[0024]

[0025] The Hash address of the off-chain asset is anchored on the chain, and the on-chain node storage index is configured on the chain. The on-chain node storage index is expressed as:

[0026] Among them, the on-chain node storage index organizes data in the form of <key, value>. The key stores the account ID and the number of hyperedges dG(v) where the vertex v is located. The value stores the Hash address H(e i ) of the hyperedge where the vertex is located, the list of attribute statuses List_State of the asset, and the asset version number

[0027] Furthermore, the correspondence between the vertices and hyperedges in the on-chain node storage index is designed to be stored in the block as an MMPT tree. In the MMPT tree, the leaf nodes are associated with the accounts involved in the assets. The leaf nodes contain the asset Hash address, the list of attribute statuses of the asset, and the asset version number The upper-level branch nodes of the leaf nodes record the hashes of the corresponding leaf nodes, and the root node records the hashes of the corresponding branch nodes.

[0028] Furthermore, the verification node group determines the legitimacy of the transaction request Tx req as follows:

[0029] The account signature in the transaction request passes the verification;

[0030] The list of attribute statuses of the asset corresponding to the transaction request is "all normal" or the attribute status of the corresponding asset is "normal";

[0031] In the on-chain node storage index, whether the account has the right to hold the asset.

[0032] Furthermore, the on-chain shunt node group and the off-chain execution nodes determine their respective trading revenues based on the on-chain and off-chain transaction costs and selling prices, and perform a Stackelberg game on the allocated trading volume based on the trading revenues of both. Dividing the transactions in the transaction pool among the on-chain or off-chain execution nodes includes:

[0033] The calculation method of on-chain trading revenue is:

[0034]

[0035] Among them, q on is the number of on-chain executed transactions, P(Q) is the selling price function of a single transaction, α is the on-chain sharing ratio. Since off-chain transactions are delivered to the on-chain for verification, the on-chain sharing ratio is configured based on the contribution of the on-chain to the verification of off-chain delivered transactions. is the number of successfully delivered off-chain transactions, c on is the cost of executing a single on-chain transaction, c on is represented by the constant a, c v is the cost of verifying a single on-chain transaction, taking the constant b, q off is the total number of off-chain executed transactions;

[0036] The calculation method of off-chain trading revenue is:

[0037] Among them, c off is the cost of executing a single off-chain transaction, taking the constant c;

[0038] The selling price function of a single transaction P(Q) = M·Q, where Q is the total trading volume of on-chain and off-chain M is the selling price coefficient, M > 0, M is a constant, M = M 1 + M 2 , M is determined by two basic factors M 1 and M 2 decides, M 1 Determined according to the relationship between the number of pending transactions in the current transaction pool and the number of transactions included in the previous block includes:

[0039] Configure not less than 2 to the first threshold β 1 , |Tx Bpre | > β 1 |Tx pool |, when |Tx Bpre | > β 1 |Tx pool | represents the number of transactions in the previous block |Tx Bpre | is much larger than the number of waiting transactions in the transaction pool |Tx pool |, indicating that the current on-chain load is low, 0 < M 1 < 1;

[0040] |Tx pool |<|Tx Bpre |≤β 1 |Tx pool |When, |Tx pool |<|Tx Bpre |≤β 1 |Tx pool |represents the number of transactions in the previous block |Tx Bpre |slightly larger than the number of transactions waiting to be processed in the transaction pool |Tx pool |, in the current on-chain load, M 1 = 1;

[0041] |Tx Bpre |≤|Tx pool |When, |Tx Bpre |≤|Tx pool |represents the number of transactions in the previous block |Tx Bpre |less than or equal to the number of transactions waiting to be processed in the transaction pool |Tx pool |, the current on-chain load is high, 1 < M 1 ;

[0042] M 2 is the ratio of the number of transactions included in the previous block to the standard number of transactions in the block: M 2 = |Tx Bpre | / |Tx Bstan |, |Tx Bpre |is the number of transactions in the previous block, |Tx Bstan |is the standard number of transactions in the block;

[0043] Let the success rate of off-chain transaction execution be λ, that is:

[0044]

[0045] The on-chain revenue function is then:

[0046]

[0047] The off-chain revenue function is then:

[0048]

[0049] The off-chain revenue function is differentiated with respect to to obtain the relationship between the off-chain optimal transaction volume and the number of on-chain executed transactions:

[0050]

[0051] Substituting the relationship between the off-chain optimal transaction volume and the number of on-chain executed transactions into the on-chain revenue function gives:

[0052]

[0053] The on-chain revenue function with respect to q on is differentiated, and the optimal on-chain trading volume is:

[0054]

[0055] Substituting the optimal on-chain trading volume into the relationship between the optimal off-chain trading volume and the number of on-chain executed transactions, the optimal off-chain trading volume is obtained:

[0056]

[0057] Furthermore, the on-chain and off-chain execution nodes execute transactions in parallel respectively, including: the workflow engine contract opens a multi-person off-chain channel for the set of account addresses involved in the transaction request Tx req and sets off-chain execution nodes in the multi-person off-chain channel;

[0058] For transactions decided to be conducted on-chain through game theory, the on-chain execution nodes obtain the specific asset attribute content from off-chain according to the Hash address of the multi-ownership multi-dimensional complex assets, execute the transactions and sign;

[0059] For transactions decided to be conducted off-chain through game theory, each off-chain execution node in the multi-person off-chain channel executes multiple indirect transactions and signs for the asset attribute content jointly held by the accounts involved in the transaction request Tx req and each indirect transaction has a signature of the entire set of execution nodes. After all indirect transactions, the final transaction result meets the corresponding requirements in the transaction request Tx req in.

[0060] Furthermore, the transaction verification methods include:

[0061] After the on-chain execution node group completes the transaction, it attaches its respective signatures. The on-chain execution node group sends the transaction result and signatures to the on-chain verification node group for verification, and the verification node group approves the transaction results with the sum of signatures of more than 2 / 3 of the on-chain execution nodes being consistent;

[0062] The off-chain transaction execution is completed. The off-chain execution node groups in the multi-person off-chain channel respectively send indirect transaction signatures to the on-chain verification node group. The submitted signatures form a set of signatures. The verification node group receives the complete sets of signatures from multiple groups of off-chain execution nodes and caches them. The latest set of signatures is set with a tag to indicate that the signature will not be updated anymore. The verification node group configures a maximum quantity limit for the signatures of multiple indirect transactions of each off-chain execution node based on the on-chain workflow engine contract, and uses the on-chain block packaging time as the starting reference for counting. The quantity of indirect transactions does not exceed the maximum quantity limit. The on-chain verification node group reaches a consensus on the latest set of signatures of all relevant off-chain execution nodes before the m-th block is produced on the chain. Before the m-th block is produced on the chain, the off-chain execution nodes respectively submit the signatures of multiple indirect transactions. When the latest set of signatures and the transaction execution result pass the verification, it indicates that the off-chain execution is successful; otherwise, it will look for the previous set of signature sets forward. If the previous set of signatures passes the verification, the corresponding off-chain transaction result will be recognized, and so on.

[0063] Furthermore, according to the complex asset transaction execution situation of the verified asset granularity or asset attribute granularity on and off the chain, the information of the assets in the account-asset relationship representation model is merged to ensure the integrity and consistency of the assets, including:

[0064] For complex asset transactions with asset granularity, the on-chain verification node group sends the verified transaction signatures and the MMPT tree to the submission node; the submission node will update the hypergraph in the off-chain storage node and the on-chain node storage index in the first time after receiving the message that the on-chain verification node group has passed the verification, change the attribute status list List_State in the on-chain node storage index to all normal, increment the version number of the corresponding hypergraph by one, the submission node packages the transaction onto the chain, and updates the MMPT tree;

[0065] For complex asset transactions with asset attribute granularity, add that the off-chain storage node group merges the asset information according to the asset version number after the transaction ends and updates the off-chain hypergraph G.

[0066] In a second aspect, the present invention provides a device for implementing a method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols, including: at least one processing unit, the processing unit is connected to a storage unit through a bus unit, the storage unit stores a computer program, and when the computer program is executed by the processing unit, the method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols as described above is implemented.

[0067] In a third aspect, the present invention provides a computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols as described above is implemented.

[0068] The above technical solution provided by the embodiment of the present invention has the following advantages compared with the prior art:

[0069] The present invention provides a method for ensuring the consistency of complex assets on and off the chain that supports multiple protocols, establishes a collaborative transaction system on and off the blockchain chain, and establishes an account-asset relationship representation model for multi-ownership multi-dimensional complex assets. This account-asset relationship representation model is compatible with the account-asset relationship that represents multi-ownership one-dimensional assets. The relationship between accounts and assets is organized using a hypergraph off the chain, with account information stored in vertices and asset information in hyperedges, which are stored in off-chain storage nodes. The hash address of the off-chain asset is anchored on the chain, and the on-chain node storage index is configured on the chain to make a legality judgment on the transaction request. The attribute status list of the account-asset relationship representation model provides corresponding locking and readable and writable status for asset granularity or asset attribute granularity. The attribute status list provides corresponding locking and readable and writable status for asset granularity or asset attribute granularity. The legitimacy verification of the attribute status list, the locking and readable and writable status provided by the attribute status list, and the one-time readable and writable status authorization of the asset attribute granularity only allow the modification of the corresponding asset attribute once to realize the control of linear consistency or sequential consistency in the transaction process; ensure the consistency of the initial state, transaction content, and transaction order of the collaboration between the asset chain and the chain, realize the final consistency between the asset chain and the chain, and support the customization of consistency conflict judgment rules of different granularities such as adjustment of the overall asset and multi-dimensional attributes, and realize multiple consistency protocols such as linear consistency and sequential consistency. Realize efficient execution of transactions and deterministic transfer of assets, and finally complete the trusted expansion of the blockchain system.

[0070] An account with multi-ownership, multi-dimensional, complex asset-related permissions initiates a transaction request. The transaction request is judged for legitimacy on the chain, and is divided into on-chain or off-chain execution according to the Stackelberg game idea, and submitted to the chain to update the asset-related information on the chain and off-chain. The legitimacy judgment of the transaction request includes the verification of the status of the attribute status list, which aims to avoid transaction conflicts, eliminate dependencies between transactions, and make the results of each transaction independent and unaffected within a certain period of time, while also ensuring that there are no read-write conflicts in assets. In addition, this application quantifies the transaction load and revenue on and off the chain to ensure that transactions are uniquely distributed to designated execution nodes on or off the chain, and at the same time achieves adaptive optimization of the overall efficiency of the system by balancing bilateral loads. Compared with the existing on-chain-off-chain collaborative transaction scheme, the present invention better meets the transaction needs of multi-ownership stakeholders, with higher throughput and lower latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0071] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0072] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0073] Figure 1 It is a flowchart of a method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols provided by an embodiment of the present invention;

[0074] Figure 2 It is a flowchart for the collaborative transaction execution on-chain and off-chain by the verification node, on-chain execution node, submission node, and off-chain node for complex asset transactions at the asset granularity or asset attribute granularity provided by an embodiment of the present invention;

[0075] Figure 3 It is an architecture diagram for the collaborative transaction execution on-chain and off-chain by the verification node, on-chain execution node, submission node, and off-chain node for complex asset transactions at the asset granularity or asset attribute granularity provided by an embodiment of the present invention;

[0076] Figure 4 It is a schematic diagram of the MMPT tree provided by an embodiment of the present invention;

[0077] Figure 5 It is a schematic diagram of a device for implementing a method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols provided by an embodiment of the present invention. Detailed implementation manners

[0078] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0079] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, some concepts involved in this application are explained below.

[0080] Account: An account on the blockchain is the stakeholder of asset ownership.

[0081] Multi-ownership multi-dimensional complex assets: Digital assets with at least one dimension of asset attributes and belonging to different accounts (holding accounts or using accounts).

[0082] Asset attributes: Classifications that can be divided into multiple dimensions within an asset, are independent of each other, and do not affect each other, describing the specific content of the asset, such as the ID card ID, age, and gender of an electronic ID card.

[0083] Operations on asset attributes: The operations of an account (asset ownership stakeholder) on the content of asset attributes include: read operation and read-write operation: Op ∈ {r, rw}, where r represents the read operation and rw represents the read-write operation.

[0084] Linear consistency: The relevant transactions of multi-ownership multi-dimensional complex assets are distributed from the chain to off-chain for collaborative execution. Before the transaction execution, the asset should have the same initial state on the chain and off-chain. At the same time, the transaction order observed at any off-chain node should be the same as the order before distribution on the chain. Therefore, after the transaction execution ends, the asset should reach a completely consistent and deterministic state between off-chain and on-chain. For example, for a transaction related to an asset Z that satisfies the order Tx1 > Tx2 > Tx3, each off-chain node executes the transaction in this order, and the execution result should be exactly the same as the expected transaction result on the chain. At this time, the asset Z on the chain and off-chain is consistent.

[0085] Sequential consistency: The relevant transactions of multi-ownership multi-dimensional complex assets are distributed from the chain to off-chain for collaborative execution. Before the transaction execution, the asset should have the same initial state on the chain and off-chain. However, after the transaction is distributed to off-chain, the transaction orders observed by different off-chain nodes are not the same, and they are also not the same as the order before distribution on the chain. However, the change in the transaction order does not bring about a change in the transaction execution result, that is, the sum of the states reached by the asset off-chain after the transaction execution is exactly the same as the expected state on the chain. This is achieved by reasonably handling the asset ownership and attribute conflicts in the transaction. For example, transactions Tx1, Tx2, and Tx3 related to an asset Z will all change the content of Z. To avoid asset inconsistency after the transaction is executed off-chain, potential conflicts should be resolved. Suppose the execution result of a transaction Tx1 related to an asset Z affects Tx2 and Tx3, but Tx2 and Tx3 do not affect each other's results. Then the transaction order received by the off-chain node can be Tx1 > Tx2 > Tx3 or Tx1 > Tx3 > Tx2 or Tx1 > Tx2 = Tx3, and the state of the asset on the chain and off-chain remains consistent after execution.

[0086] It should be noted that in this article, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the said element.

[0087] Embodiment 1

[0088] As Figure 1 shown, the technical solution of the present invention realizes a method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols, which is applied to the massive transaction execution scenario of multi-ownership and multi-dimensional complex assets in the on-chain and off-chain collaborative transaction system of the blockchain. The on-chain and off-chain collaborative transaction system consists of on-chain nodes and off-chain nodes with computing and storage functions. The on-chain and off-chain collaborative transaction system consists of on-chain nodes and off-chain nodes with computing and storage functions. In the on-chain and off-chain collaborative transaction system, according to the available resources of the on-chain nodes and the resource requirements of the blockchain, the on-chain nodes are sorted, and the on-chain nodes are divided into verification nodes, on-chain execution nodes, shunt nodes and submission nodes according to the on-chain node sorting. The off-chain nodes include off-chain execution nodes and off-chain storage nodes. The purpose of the present invention is to realize the on-chain and off-chain collaborative execution of the blockchain system for multi-ownership and multi-dimensional complex assets, and ensure the data consistency of multi-ownership and multi-dimensional complex assets during the on-chain and off-chain collaborative execution process. The data consistency includes linear consistency and sequential consistency, and finally the performance of the blockchain is extended through the trusted collaborative execution on-chain and off-chain.

[0089] The method for ensuring the on-chain and off-chain consistency of complex assets supporting multiple protocols of the present invention includes:

[0090] S1, establishing an on-chain and off-chain collaborative transaction system, and establishing an account-asset relationship representation model of multi-ownership and multi-dimensional complex assets through the hypergraph off-chain and the on-chain node storage index on-chain.

[0091] In the on-chain and off-chain collaborative transaction system, according to the available resources of the on-chain nodes and the resource requirements of the blockchain, the on-chain nodes are sorted, and the on-chain nodes are divided into verification nodes, on-chain execution nodes, shunt nodes and submission nodes according to the on-chain node sorting.

[0092] Specifically, according to the available resources of the on-chain nodes and the resource requirements of the blockchain, the following formula is used to calculate the descending ranking of the on-chain nodes:

[0093]

[0094] It represents the total available resources of the three types of nodes on the chain. This formula can be used to intuitively measure the current load of a node on the chain and the node role it can play. i ,i=1,2,3 represents the nodes on the chain The current available resources include three types of resources: CPU, bandwidth, and memory. i ,i=1,2,3 represents the resource (CPU, bandwidth, memory) requirements on the corresponding blockchain.

[0095] The top 20% of the on-chain nodes in descending order are selected as verification nodes, the top 21%-80% of the on-chain nodes are selected as execution nodes, and the remaining on-chain nodes are selected as diversion nodes and submission nodes. There is generally one submission node.

[0096] The account-asset relationship representation model for multi-ownership, multi-dimensional, complex assets is established through the off-chain hypergraph and the on-chain node storage index, including:

[0097] Constructing accounts, representations of multi-ownership, multi-dimensional complex assets:

[0098] Account ID j , account address addr j Means: Account j =(ID j ,addr j ).

[0099] Multi-ownership, multi-dimensional, complex assets are uniquely identified by assets i , asset attribute content, attribute state list List_State, transaction ID list List_Tx, asset version number And the holding account list List_holders represents:

[0100]

[0101] The asset attributes of multi-ownership, multi-dimensional and complex assets are expressed as follows:

[0102] [(e i_1 ,asset i_1 ),(e i_2 ,asset i_2 ),……,(e i_x ,asset i_x )], where e i_x Indicates the asset attribute number, asset i_x Indicates the asset attribute content corresponding to the asset attribute number.

[0103] Each asset attribute has two states, the normal state, represented by the number 1, where the normal state indicates that the asset attribute is readable and writable; the locked state, represented by the number 0, where the locked state indicates that the asset attribute is neither readable nor writable: State ∈ {0, 1}. The set of states of the asset attributes constitutes the attribute state list List_State. The attribute state list is used to determine the current state of the asset attributes of the multi-ownership multi-dimensional complex assets and the subsequent operations that can be performed. There are a total of three types of attribute state lists List_State ∈ {List_State 1 ,List_State 2 ,List_State 3}, List_State 1 represents all normal [1, 1, 1,..., 1], List_State 2 represents all locked [0, 0, 0,..., 0], List_State 3 partially normal and partially locked [1, 0, 1,..., 0]. The attribute state list provides the corresponding locked and readable / writable states for the asset granularity or the asset attribute granularity. Using the legality verification of the attribute state list, the locked and readable / writable states provided by the attribute state list, and the one-time readable / writable state authorization for the asset attribute granularity only allow one modification of the corresponding asset attribute to achieve the control of linear consistency or sequential consistency during the transaction process.

[0104] Establish an account-asset relationship representation model for multi-ownership multi-dimensional complex assets, which is divided into two parts: on-chain and off-chain. The account-asset relationship representation model can compatibly represent the relationship between accounts and assets of multi-ownership one-dimensional assets. Off-chain, a hypergraph is used to organize the relationship between account assets. Account information exists in the vertices of the hypergraph, and asset information exists in the hyperedges of the hypergraph. The hypergraph is stored in the off-chain storage node. On-chain, the Hash address of the off-chain asset is anchored, and an on-chain node storage index is configured on-chain for the legality judgment of transaction requests. In the account-asset relationship representation model of the present invention, on-chain nodes all store the on-chain node storage index, and the off-chain stores the hypergraph to organize the ownership association relationship between accounts and assets and store the specific content of the assets. In the present invention, on-chain accounts can all view the asset content of each other, and they are all the using accounts of on-chain assets, but only the holding account can modify the asset content. Corresponding to the off-chain hypergraph, the holding account corresponds to the vertex, and the held asset corresponds to the hyperedge. Multiple vertices on the same hyperedge mean that these holding accounts jointly hold the asset and have the permission to collaboratively read and write the asset content.

[0105] The off-chain hypergraph is represented as:

[0106] G = {V, E, Ver G};

[0107] where, V = {Account1 , Account 2 ,...... Account j ,......} is the vertex set of the hypergraph, Account j = (ID j , addr j ) is the vertex in the vertex set;

[0108] E = {Hedge 1 , Hedge 2 ,...... Hedge i ,......} is the hyperedge set of the hypergraph, hyperedge:

[0109]

[0110] The storage index of the nodes on the chain is expressed as:

[0111] Among them, the storage index of the nodes on the chain organizes data in the form of <key, value>. The account ID and the number of hyperedges dG(v) where the vertex v is located (the amount of assets held by the account) are stored in key, and the Hash address H(e i ), the attribute status list List_State of the asset, and the asset version number

[0112] The storage index of the nodes on the chain itself does not have anti-tampering property. The corresponding relationship between vertices and hyperedges in the storage index of the nodes on the chain is designed as an MMPT tree and stored in the block, as Figure 4 shown. In the MMPT tree, the leaf nodes are associated with the accounts involved in the assets. The leaf nodes contain the asset Hash address, the attribute status list of the asset, and the asset version number The upper-level branch nodes of the leaf nodes record the hashes of the corresponding leaf nodes, and the root node records the hashes of the corresponding branch nodes. Whenever the situation of the assets held by the account changes or the version of the asset changes, the value of the leaf node of the MMPT tree changes, and the root node hash will be inconsistent with the content hash of the leaf node for anti-tampering.

[0113] S2. For complex asset transactions at the asset granularity or asset attribute granularity, the verification nodes, on-chain execution nodes, submission nodes, and off-chain nodes cooperate to perform on-chain and off-chain collaborative transaction execution. In the specific implementation process, as Figure 2 and Figure 3 shown, it includes:

[0114] S21. The on-chain verification node group judges the legality of the transaction request initiated by the client;

[0115] S211, an account with multi-ownership, multi-dimensional, complex asset-related permissions initiates a transaction request Tx to the on-chain and off-chain collaborative transaction system through the client req .

[0116] Transaction request Tx req Req_Op_e is the unique identifier of the asset being read or written / the number of the asset attribute being read or written. i / Req_Op_e i_x , account address set Requesting an account signature SigReq means:

[0117]

[0118] Transaction requests include: transaction requests at asset granularity and transaction requests at asset attribute granularity. Transaction requests at asset granularity must ultimately achieve linear consistency, and transaction requests at asset attribute granularity must ultimately achieve sequential consistency.

[0119] S212, the workflow engine contract receives a transaction request Tx from the client req , strip off the necessary information and send it to the verification node group.

[0120] S213, the verification node group calls the data access control contract to determine the transaction request Tx req The legitimacy of the transaction includes: verifying the validity of the request account signature SigReq, the asset attribute status list corresponding to the transaction request is "all normal" or the corresponding asset attribute status is "normal"; judging the account address set The account's permissions on multi-ownership, multi-dimensional, complex assets, that is, whether the account in the transaction request has the right to hold the asset in the on-chain node storage index.

[0121] The legitimacy judgment can only be completed when more than 2 / 3 of the verification nodes in the chain group are judged to be legitimate; in addition, the legitimacy judgment is also divided into different specific methods according to different consistency protocols. Two examples will be given later: 1. Legality judgment at the asset granularity, corresponding to linear consistency. 2. Legality judgment at the asset attribute granularity, corresponding to sequential consistency.

[0122] S214, transaction request Tx of client account req After passing the legality judgment, the data access control contract changes the corresponding asset attribute status in the on-chain node storage index from "normal" to "locked". Specifically, when the granularity of the transaction request is assets, the data access control contract modifies the attribute status list of the assets corresponding to the on-chain node storage index from all normal to all locked. When the granularity of the transaction request is a certain dimension attribute of an asset, the data access control contract modifies the status of the asset attribute corresponding to the on-chain node storage index from "1" to "0".

[0123] S215, put the transaction corresponding to the transaction request that has passed the legality judgment into the transaction pool for waiting to be processed. The transaction uses the unique identifier e of the asset with transaction changes i / the number of the asset attributes with transaction changes i_y , the Hash address Cha_asset corresponding to the asset with changes i_y , the transaction ID Tx_Id, the set of transaction party signatures Sign + and the asset version number It means:

[0124]

[0125] S22, the two parties on-chain and off-chain conduct a Stackelberg game based on the transaction revenue for the allocated trading volume, and divide the transactions in the transaction pool among the on-chain or off-chain execution nodes;

[0126] S221, the on-chain shunt node group and the off-chain execution node representatives analyze the number of transactions to be processed in the transaction pool according to the resource balance module, and configure the selling price coefficient M according to the number, M>0, M is a constant, M = M 1 +M 2 , M is determined by two basic factors M 1 and M 2 .

[0127] S222, the on-chain shunt node group determines its own transaction revenue based on the on-chain and off-chain transaction costs and selling prices, conducts a Stackelberg game based on the transaction revenues of both parties for the allocated trading volume, and divides the transactions in the transaction pool among the on-chain or off-chain execution nodes.

[0128] In the specific implementation process, regard the on-chain and off-chain nodes as a system as a whole, then both parties of the successful transaction obtain revenues. The on-chain needs to verify the transactions delivered by itself and the off-chain. For the contribution of the on-chain to the verification of the off-chain delivered transactions, configure the on-chain sharing ratio.

[0129] Then the calculation method of the on-chain transaction revenue is:

[0130] Among them, q on is the number of on-chain executed transactions, P(Q) is the single-transaction selling price function, α is the on-chain sharing ratio, is the number of successfully delivered off-chain transactions, c on is the cost of executing a single on-chain transaction, c v is the cost of verifying a single off-chain transaction on-chain, q off is the total number of off-chain executed transactions;

[0131] The calculation method of the off-chain transaction revenue is:

[0132] Among them, c off is the cost of executing a single off-chain transaction;

[0133] The selling price function of a single transaction is P(Q) = M·Q, where Q is the total on-chain and off-chain transaction volume, which is less than the volume of transactions to be processed. M is the selling price coefficient, M > 0, M is a constant, M = M 1 +M 2 , M is determined by two basic factors M 1 and M 2 , and M 1 is determined according to the relationship between the number of transactions to be processed in the current transaction pool and the number of transactions included in the previous block, including:

[0134] When the configuration is not less than 2 to the first threshold β 1 , |Tx Bpre | > β 1 |Tx pool |, when |Tx Bpre | > β 1 |Tx pool | represents the number of transactions in the previous block |Tx Bpre | is much larger than the number of transactions waiting to be processed in the transaction pool |Tx pool |, indicating that the current on-chain load is low, 0 < M 1 < 1, such as M 1 = 0.9;

[0135] |Tx pool | < |Tx Bpre | ≤ β 1 |Tx pool |, when |Tx pool | < |Tx Bpre | ≤ β 1 |Tx pool | represents the number of transactions in the previous block |Tx Bpre | is slightly larger than the number of transactions waiting to be processed in the transaction pool |Tx pool |, the current on-chain load is medium, M 1 = 1;

[0136] |Tx Bpre | ≤ |Tx pool |, when |Tx Bpre | ≤ |Tx pool | represents the number of transactions in the previous block |Tx Bpre | is less than or equal to the number of transactions waiting to be processed in the transaction pool |Tx pool |, the current on-chain load is high, 1 < M 1 , such as M 1 = 1.1;

[0137] M 2 is the ratio of the number of transactions in the previous block to the standard number of transactions in the block: M 2 = |Tx Bpre | / |Tx Bstan |, where Tx Bpre | is the number of transactions in the previous block, and Tx Bstan | is the standard number of transactions in the block. The value of Tx Bstan is determined according to the actual situation and serves to measure the size of the load standard. When the number of transactions Tx Bpre in the previous block is greater than the standard number of transactions Tx Bstan in the block, M 2 > 1, indicating that the current node load is relatively large, the consumption of resources such as computing is high, and then the transaction fee will be increased accordingly. When the number of transactions Tx Bpre in the previous block is less than the standard number of transactions Tx Bstan in the block, for the current block, 1 > M 2 > 0, that is, the current node load is relatively small, the consumption of computing resources is low, and each node is idle, so the transaction fee will be decreased.

[0138] c on = ∑(BaseFee · gasAmount). BaseFee is the unit price consumed by the meta-operations of the transaction, and gasAmount is the number of meta-operations of the transaction. Within a limited time period, the block size is constant, the unit price consumed by all meta-operations in the block is the same, and the execution of the transaction is mainly based on read and write operations. Based on the similarity of the content and number of meta-operations in the smart contracts involved in different transactions, the number of meta-operations of each transaction is taken to be the same, and the average value of the number of meta-operations of all transactions within the limited time period is taken, then c on can be represented by the constant a.

[0139] Regarding the cost of verifying a transaction on the chain as a constant b, that is:

[0140] c v = b;

[0141] The cost of executing a transaction off-chain is the constant c, that is:

[0142] c off = c.

[0143] The number of transactions successfully delivered off-chain is while the total number of transactions executed off-chain is q off . That is transactions are executed off-chain and submitted for successful verification on the chain, A deal is executed off-chain and submitted for on-chain verification but fails, regardless of whether the failure is due to insufficient off-chain computing power or a situation in the off-chain network that prevents off-chain consensus from being reached. Then, assuming the success rate of off-chain transaction execution is λ, that is:

[0144]

[0145] The on-chain revenue function is then:

[0146]

[0147] The off-chain revenue function is then:

[0148]

[0149] The off-chain revenue function with respect to is differentiated, and the relationship between the off-chain optimal transaction volume and the number of transactions executed on-chain is obtained:

[0150]

[0151] Substituting the relationship between the off-chain optimal transaction volume and the number of transactions executed on-chain into the on-chain revenue function gives:

[0152]

[0153] The on-chain revenue function with respect to q on is differentiated, and the on-chain optimal transaction volume is:

[0154]

[0155] Substituting the on-chain optimal transaction volume back into the relationship between the off-chain optimal transaction volume and the number of transactions executed on-chain gives the off-chain optimal transaction volume:

[0156]

[0157] At this point, the on-chain and off-chain transaction equilibrium points are reached. That is, in the case of the corresponding optimal total on-chain and off-chain transaction volumes, the on-chain and off-chain respectively obtain the maximum revenue, and the on-chain and off-chain as a whole obtain the maximum revenue. The total on-chain and off-chain transaction volume is calculated as:

[0158]

[0159] Substituting the on-chain and off-chain optimal transaction volumes into the on-chain and off-chain revenue functions respectively, the respective revenues can be obtained:

[0160]

[0161] S23. The on-chain and off-chain execution nodes execute transactions in parallel respectively;

[0162] S231. The workflow engine contract opens a multi - person off - chain channel for the set of account addresses involved in the transaction request Tx req and sets up off - chain execution nodes within the multi - person off - chain channel.

[0163] S232. For transactions to be executed on the chain after game - theoretic decision - making, the on - chain execution nodes obtain the specific asset attribute content from off - chain according to the Hash address of the multi - ownership multi - dimensional complex assets, execute the transaction and sign it.

[0164] S233. For transactions to be executed off - chain after game - theoretic decision - making, each off - chain execution node within the multi - person off - chain channel performs multiple indirect transactions on the asset attribute content jointly held by the accounts involved in the transaction request Tx req and signs them. Each indirect transaction has a signature of the entire set of execution nodes. After all indirect transactions, the final transaction result meets the corresponding requirements in the transaction request Tx req for the accounts.

[0165] S24. Signatures for on - chain and off - chain transactions. The verification node group verifies the transaction based on the transaction's signature.

[0166] S241. After the on - chain transaction ends, the on - chain execution node group sends the transaction result and signature to the on - chain verification node group for verification. The on - chain execution node group's transaction verification methods include:

[0167] After the on - chain execution node group completes the transaction, it attaches its respective signatures. The on - chain execution node group sends the transaction result and signature to the on - chain verification node group for verification. The verification node group approves the transaction result with the sum of signatures of more than 2 / 3 of the on - chain execution nodes being consistent.

[0168] S242. The off-chain transaction ends. The off-chain execution node groups in the multi-person off-chain channel respectively send signatures to the on-chain verification node group, and the submitted signatures form a set of signatures for verification. The off-chain transaction verification method of the off-chain execution node group includes: when the off-chain transaction execution ends, the off-chain execution node groups in the multi-person off-chain channel respectively send indirect transaction signatures to the on-chain verification node group, and the submitted signatures form a set of signatures. The verification node group receives the complete sets of signatures of multiple off-chain execution nodes and caches them. The latest set of signatures is set with a tag to indicate that the signature will not be updated anymore; the verification node group configures a maximum quantity limit for the signatures of multiple indirect transactions of each off-chain execution node based on the on-chain workflow engine contract, and uses the on-chain block packaging time as the starting reference for counting. The quantity of indirect transactions does not exceed the maximum quantity limit; the on-chain verification node group reaches a consensus on the latest set of signatures of all relevant off-chain execution nodes before the m-th block is produced on the chain; before the m-th block is produced on the chain, the off-chain execution nodes respectively submit the signatures of multiple indirect transactions. When the latest set of signatures and the transaction execution result pass the verification, it indicates that the off-chain execution is successful; otherwise, it will look for the previous set of signature sets forward. If the previous set of signatures passes the verification, the corresponding off-chain transaction result will be recognized, and so on.

[0169] S3. Merge the information of the assets in the account-asset relationship representation model according to the on-chain and off-chain transaction execution situations, and merge the assets according to the transaction results to ensure the integrity and consistency of the assets, including:

[0170] S31. The on-chain verification node group sends the transaction signatures to be verified and the MMPT tree to the submission node;

[0171] S32. The submission node does not have to wait until the block is packaged and produced to update the off-chain data. The submission node will update the hypergraph in the off-chain storage node immediately after receiving the message that the on-chain verification node group has passed the verification.

[0172] S33. The submission node updates the on-chain node storage index immediately, changes the attribute status list List_State in the on-chain node storage index from List_State2 to List_State1, increments the version number of the corresponding hypergraph by one, the submission node packages the transaction onto the chain, and updates the MMPT tree.

[0173] S34. The off-chain storage node group merges the assets after the transaction ends and updates the off-chain hypergraph G.

[0174] When the granularity of the transaction request is the asset attribute, the asset merging rule is as follows: When the attribute status list List_State changes from List_State 1 to List_State 3 and then changes to List_State 2When it indicates that the asset attribute has been modified once, the asset needs to merge multi-dimensional asset attributes at this time. The submission node finds the same asset version number from the transaction, and finds the hyperedge of the hypergraph stored off-chain based on the asset Hash address on the chain, that is, all the information of the asset, and correspondingly changes the storage index of the on-chain node and the content of the off-chain hypergraph G: S32, S33, and S34 all retain the asset unique identifier and attribute number. S32, update the specific content of the asset attribute asset to the latest specific content of the asset attribute asset' according to the transaction information. S33, supplement all transaction IDs during the version number update to the transaction ID list List_Tx. S32, S33, and S34 all increment the asset version number by one, update the list of holding accounts List_holders to the latest List_holders', and update List_State 2 to List_State 1 . S34 merges the latest specific content of the asset attribute asset' of each dimension of the asset Asset and updates it to the latest asset Asset'. When merging, the modification time and content are distinguished by the asset version number. The hyperedges / hypergraphs with the same asset version number are merged together. The hyperedge / hypergraph with a larger version number has a later occurrence time and newer content than the one with a smaller version number.

[0175] When the granularity of the transaction request is an asset, asset merging means that the asset is replaced by the new one according to the version number, and does not involve the merging of multiple dimensions into a complete asset. At this time, only S32 and S33 are required, and S34 is not required.

[0176] In this application, after a certain dimension of the asset attribute is modified and signed in one on-chain transaction or a set of off-chain transactions, the asset version number will be incremented by one; in one change of the asset version number, each attribute of the asset can be modified at most once. The asset attributes of different dimensions of the asset can be modified in parallel by its co-holding accounts, and the modification results of different attributes are independent of each other. The asset holding account can modify different assets or asset attributes it holds in parallel, and the modification results of different attributes are independent of each other. Under the same asset version number, the attributes that are newly modified by the transaction will be merged together to form a complete asset.

[0177] Example of sequential consistency:

[0178] In the medical context, the digital asset "Medical Institution Practice License ML" (electronic), its co-holding accounts are the Ministry of Health DH, the Centers for Disease Control and Prevention DPC, and the Drug Administration DA, and its co-using accounts are the clinic C and the patient P. The Medical Institution Practice License ML has multiple dimensions of attributes, such as two dimensions, "Business Status" with the number "1" and "Validity Period of Practice License" with the number "2".

[0179] S211, the Ministry of Health DH initiates a transaction request from the client, requesting to modify the content of the asset attribute 1 "Business Status" of the medical institution practice license ML from "Normal Business" to "Suspended for Rectification". The Drug Administration DA requests to modify the content of the attribute 2 "Validity Period of Practice License" of the medical institution practice license ML from "10 years" to "5 years".

[0180] S212, the transaction request Tx req DH = {Req_rw_ML_1, addr p DH, SigReqDH},

[0181] Tx req DA = {Req_rw_ML_2, addr p DA, SigReqDA} The attribute number of the asset requested to be read and written, the account address of the requested transaction, and the account signature are sent to the verification node group via the workflow engine contract.

[0182] S213, the verification node group calls the data access control contract to determine that the accounts of the Ministry of Health DH and the Drug Administration DA requesting the transaction have the right to hold the medical institution practice license ML, have the permission to modify the attributes of the medical institution practice license ML, and the resource attribute 1 of the medical institution practice license ML is in the "Normal" state and can be modified by the holding account, and the resource attribute 2 of the medical institution practice license ML is in the "Normal" state and can be modified by the holding account.

[0183] S214, the data access control contract changes the status of the resource attribute 1 of the corresponding medical institution practice license ML in the on-chain node storage index from "Normal" to "Locked", and the on-chain node storage index attribute status list changes from "11" to "01". The data access control contract changes the status of the attribute 2 of the corresponding medical institution practice license ML in the on-chain node storage index from "Normal" to "Locked", and the on-chain node storage index attribute status list changes from "01" to "00".

[0184] S215, the verification node group adds the Tx req DH, Tx req DA corresponding transactions to the transaction pool to wait for shunting and execution.

[0185] S221, there are many pending transactions in the transaction pool, M 1 = 1.1, M 2 = 1.25.

[0186] S222. For a legal transaction request, the on-chain shunt node group determines their respective trading revenues based on the on-chain and off-chain transaction costs and selling prices, conducts a Stackelberg game on the allocated trading volume based on the two trading revenues, and divides the transactions in the transaction pool among the on-chain or off-chain execution nodes, Tx req DH is executed on-chain, Tx req DA is executed off-chain.

[0187] S231. The workflow engine contract opens a multi-person off-chain channel.

[0188] S232. The on-chain execution node group executes the transaction and signs it. The specific content of Resource Attribute 1 of the Medical Institution Practice License ML is anchored by the Hash address H(e ML ) and found in the off-chain storage node.

[0189] S233. The off-chain execution node group in the multi-person off-chain channel executes the transaction and signs it. The specific content of Resource Attribute 2 of the Medical Institution Practice License ML is anchored by the Hash address H(e ML ) and found in the off-chain storage node.

[0190] S241. The on-chain execution node group submits the transaction result and signature to the verification node group.

[0191] S242. The off-chain execution node group submits the transaction result and signature to the verification node group. Here, S241 and S242 can be executed in parallel without distinguishing the order of start or end of the two transactions.

[0192] S31. The verification node group passes the consensus verification on both transaction results and sends them to the submission node.

[0193] S32. In the off-chain hypergraph G, Resource Attribute 1 of the Medical Institution Practice License ML is changed from "Normal operation" to "Suspended for rectification", and Resource Attribute 2 of the Medical Institution Practice License ML is changed from "10 years" to "5 years".

[0194] S33. In the on-chain node storage index, the status of Resource Attribute 1 of the Medical Institution Practice License ML is changed from "Locked" to "Normal", the status of Resource Attribute 2 is changed from "Locked" to "Normal", and the resource version number is incremented by one; a new MMPT leaf node is added to record the change in the version number of the Medical Institution Practice License ML.

[0195] S34. The resource version number of the Medical Institution Practice License ML is incremented by one, the attribute status is changed from "00" to "11", and Resource Attribute 1 and Resource Attribute 2 are merged into a complete asset.

[0196] After this process, the results of transactions involving the Medical Institution Practice License ML executed by the on-chain and off-chain collaborative trading system remain linearly consistent. There is no distinction between Tx req DH and Tx req DA in the order at on-chain or off-chain nodes, and regardless of whether Tx req DA comes first or Tx req DH comes first, the trading results related to the Medical Institution Practice License ML within the block, the unique asset identifier, the specific asset content, the attribute status list, the trading ID list, the asset version number, and the account-asset correspondence of the Medical Institution Practice License ML assets on-chain and off-chain are consistent.

[0197] Example of linear consistency:

[0198] In a medical context, the digital asset "Medical Institution Practice License ML" (electronic), its co-holding accounts are the Ministry of Health DH, the Center for Disease Control and Prevention DPC, and the Drug Administration DA, and its co-using accounts are the clinic C and the patient P. The Medical Institution Practice License ML has multiple dimensions of attributes, such as two dimensions, "Business Status" numbered "1" and "Validity Period of Practice License" numbered "2".

[0199] S211, the Center for Disease Control and Prevention DPC initiates a transaction request from the client, requesting to modify the content of the held asset Medical Institution Practice License ML from "Normal operation, 10 years" to "Normal operation, 15 years".

[0200] S212, the transaction request Tx req DPA = {Req_rw_ML,addr p The unique identifier of the asset requested to be read and written, the account address of the requested transaction, and the account signature in DPA,SigReqDPA are sent to the verification node group via the workflow engine contract.

[0201] S213, the verification node group calls the data access control contract to determine that the requesting transaction account, the Center for Disease Control and Prevention DPA, has the right to hold the asset Medical Institution Practice License ML, has the permission to modify the Medical Institution Practice License ML, and the attribute status list of the Medical Institution Practice License ML is in the "All normal" state and can be modified by the holding account.

[0202] S214, the data access control contract changes the attribute status list in the on-chain node storage index on-chain from "11" to "00".

[0203] S211, the Ministry of Health DH initiates a transaction request from the client, requesting to modify the content of the held asset Medical Institution Practice License ML from "Normal operation, 10 years" to "Suspended for rectification, 5 years".

[0204] S212, transaction request Tx req DH={Req_rw_ML,addr p The unique identifier of the asset requested to be read or written, the account address of the requested transaction, and the account signature in DH, SigReqDH} are sent to the verification node group via the workflow engine contract.

[0205] S213, the verification node group calls the data access control contract and determines that the account DH requesting the transaction has the right to hold the asset medical institution practice license ML and has the authority to modify the medical institution practice license ML, but the attribute status list of the medical institution practice license ML is in the "all locked" state and cannot be modified by the holding account temporarily.

[0206] S215, the verification node group will Tx req The transactions corresponding to DPA are added to the transaction pool and wait for diversion and execution.

[0207] S221, there are few pending transactions in the transaction pool, take M 1 =0.9, M 2 =0.8.

[0208] S222, determined by the game between the on-chain and off-chain parties, Tx req DPA is executed on-chain.

[0209] S232, the on-chain execution node group executes the transaction and signs. The specific content of the medical institution practice license ML is stored in the on-chain storage node index H (e ML ) anchored and found in the off-chain storage node.

[0210] S241, the on-chain execution node group submits the transaction results and signatures to the verification node group.

[0211] S31, the transaction result is verified by the verification node group through consensus and sent to the submitting node.

[0212] S32, the medical institution practice license ML in the off-chain hypergraph G is changed from "normal operation, 10 years" to "normal operation, 15 years", and the resource version number of the medical institution practice license ML is increased by one.

[0213] S33, the attribute status list of the medical institution practice license ML in the on-chain storage node index is changed from "00" to "11", and the resource version number is increased by one; a new MMPT tree leaf node is added to record changes such as the version number of the medical institution practice license ML.

[0214] S211, the Ministry of Health DH initiates a transaction request from the client, requesting to modify the content of the medical institution practice license ML from "normal operation, 10 years" to "suspension for rectification, 5 years".

[0215] S212, Transaction Request Tx req DH = {Req_rw_ML, addr p The unique identifier of the asset for which read / write is requested, the account address of the requested transaction, and the account signature in DH, SigReqDH are sent to the verification node group via the workflow engine contract.

[0216] S213, The verification node group calls the data access control contract to determine whether the account DH of the requested transaction has the right to hold the asset Medical Institution Practice License ML, has the permission to modify the Medical Institution Practice License ML, and the attribute status list of the Medical Institution Practice License ML is in the "all normal" state and can be modified by the holding account.

[0217] S214, The data access control contract changes the attribute status list in the on-chain storage node index from "11" to "00".

[0218] S215, The verification node group adds the transaction corresponding to Tx req DH to the transaction pool and waits for shunting and execution.

[0219] S221, There are few transactions to be traded in the transaction pool, and M 1 = 0.9, M 2 = 0.8.

[0220] S222, The on-chain and off-chain parties decide through game theory that Tx req DH is executed off-chain.

[0221] S231, The workflow engine contract opens a multi-person off-chain channel.

[0222] S233, The off-chain execution node group in the multi-person off-chain channel executes the transaction and signs it. The specific content of the Medical Institution Practice License ML is anchored by the Hash address H(e ML ) in the on-chain storage node index and found in the off-chain storage node.

[0223] S242, The off-chain execution node group submits the transaction result and signature to the verification node group.

[0224] S31, The transaction result is verified by the verification node group through consensus and sent to the submission node.

[0225] S32, In the off-chain hypergraph G, the Medical Institution Practice License ML is modified from "Normal operation, 10 years" to "Suspended for rectification, 5 years", and the resource version number of the Medical Institution Practice License ML is incremented by one.

[0226] S33. In the list of attribute statuses of the medical institution practice license ML in the on-chain storage node index, change "00" to "11", and increment the resource version number by one; add a leaf node to the MMPT tree to record the change in the resource version number of the medical institution practice license ML.

[0227] After this process, the results of transactions involving the medical institution practice license ML are consistent in order after being executed by the on-chain and off-chain collaborative transaction system. There is a Tx at the on-chain or off-chain node. req DPA > Tx req The order of DH. The unique asset identifier, specific asset content, list of attribute statuses, list of transaction IDs, asset version number, and account-asset correspondence of the asset medical institution practice license ML on the chain and off the chain are the same.

[0228] Embodiment 2

[0229] Refer to Figure 5 As shown, the embodiment of the present invention provides a device for implementing a method for ensuring on-chain and off-chain consistency of complex assets supporting multiple protocols, including: at least one processing unit, the processing unit is connected to the storage unit through a bus unit, and the storage unit, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the software programs, computer-executable programs, and modules corresponding to a method for ensuring on-chain and off-chain consistency of complex assets supporting multiple protocols in the embodiment of the present invention. The processing unit realizes the above method for ensuring on-chain and off-chain consistency of complex assets supporting multiple protocols by running the software programs, computer-executable programs, and modules stored in the storage unit, including:

[0230] Establish an account-asset relationship representation model of multi-ownership multi-dimensional complex assets through an off-chain hypergraph and an on-chain node storage index.

[0231] For complex asset transactions at the asset granularity or asset attribute granularity, the verification node, on-chain execution node, shunt node, and off-chain node cooperate to perform on-chain and off-chain collaborative transaction execution, including: an account with permissions related to multi-ownership multi-dimensional complex assets initiates a transaction request Tx to the on-chain and off-chain collaborative transaction system through the client. req ; The verification node group judges the legitimacy of the transaction request Tx. req ; For a legitimate transaction request, the on-chain shunt node group and off-chain execution node representatives determine their respective transaction revenues based on the on-chain and off-chain transaction costs and selling prices, perform a Stackelberg game on the allocated trading volume based on the two transaction revenues, and divide the transactions in the transaction pool among the on-chain or off-chain execution nodes; the on-chain and off-chain execution nodes execute the transactions in parallel.

[0232] The information of assets in the account-asset relationship representation model is merged based on the verified transaction execution on and off the chain, and the assets are merged based on the transaction results to ensure asset integrity and consistency.

[0233] Of course, the computer program stored in the storage unit of the device for implementing the on-chain and off-chain consistency assurance method for complex assets supporting multiple protocols provided by an embodiment of the present invention is not limited to the method operations described above, and can also execute related operations in the on-chain and off-chain consistency assurance method for complex assets supporting multiple protocols provided by any embodiment of the present invention.

[0234] Example 3

[0235] An embodiment of the present invention provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program. When the computer program is executed, the method for ensuring consistency between on-chain and off-chain complex assets supporting multiple protocols is implemented, including:

[0236] Establish an account-asset relationship representation model for multi-ownership, multi-dimensional, complex assets through off-chain hypergraphs and on-chain node storage indexes;

[0237] For complex asset transactions at the asset granularity or asset attribute granularity, verification nodes, on-chain execution nodes, diversion nodes and off-chain nodes cooperate to perform on-chain and off-chain collaborative transactions, including: accounts with multi-ownership and multi-dimensional complex asset-related permissions initiate transaction requests Tx to the on-chain and off-chain collaborative transaction system through the client req ; Verify the node group to determine the transaction request Tx req The legitimacy of the transaction; for legitimate transaction requests, the on-chain diversion node group and the off-chain execution node representatives determine their respective transaction income based on the transaction costs and selling prices on the chain and off-chain, and make a Stackelberg game based on the transaction income of both for the allocated transaction volume, and divide the transactions in the transaction pool to the on-chain or off-chain execution nodes; the on-chain and off-chain execution nodes execute transactions in parallel respectively;

[0238] The information of assets in the account-asset relationship representation model is merged based on the verified transaction execution on and off the chain, and the assets are merged based on the transaction results to ensure asset integrity and consistency.

[0239] A computer-readable storage medium provided in an embodiment of the present invention stores a computer program which is not limited to the method operations described above, but can also execute related operations in a complex asset chain and off-chain consistency assurance method supporting multiple protocols provided in any embodiment of the present invention.

[0240] In the embodiments provided by the present invention, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling, direct coupling, or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of structures or units can be in electrical, mechanical, or other forms.

[0241] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0242] In addition, in each embodiment of the present invention, the functional units can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0243] The above are only the specific embodiments of the present invention, enabling those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for ensuring consistency between on-chain and off-chain complex assets supporting multiple protocols, which is applied to the massive transaction execution scenario of multi-ownership and multi-dimensional complex assets in the on-chain and off-chain collaborative transaction system of the blockchain. The on-chain and off-chain collaborative transaction system is composed of on-chain nodes and off-chain nodes with computing and storage functions. In the on-chain and off-chain collaborative transaction system, the on-chain nodes are sorted according to the available resources of the on-chain nodes and the resource requirements of the blockchain. The on-chain nodes are divided into verification nodes, on-chain execution nodes, diversion nodes and submission nodes according to the on-chain node sorting, and the off-chain nodes are cooperated to realize the transaction of multi-ownership and multi-dimensional complex assets. It is characterized in that include: An account-asset relationship representation model for multi-ownership, multi-dimensional, complex assets is established through off-chain hypergraphs and on-chain node storage indexes. The account-asset relationship representation model includes an attribute status list, which provides corresponding locking and readable and writable states for asset granularity or asset attribute granularity. The legitimacy of the attribute status list is verified, and the locking and readable and writable states provided by the attribute status list, as well as the one-time readable and writable state authorization of the asset attribute granularity, only allow the modification of the corresponding asset attribute once to achieve linear consistency or sequential consistency control during the transaction process; For complex asset transactions at the asset granularity or asset attribute granularity, verification nodes, on-chain execution nodes, diversion nodes and off-chain nodes cooperate to perform on-chain and off-chain collaborative transactions, including: accounts with multi-ownership and multi-dimensional complex asset-related permissions initiate transaction requests to the on-chain and off-chain collaborative transaction system through the client ; Verify the transaction request The legitimacy of the transaction pool is verified, and the verification includes verifying the attribute status list of the asset provided by the account-asset relationship representation model; for legal transaction requests, the on-chain diversion node group and the off-chain execution node representatives carry out the Stackelberg game based on the on-chain and off-chain transaction benefits, and divide the transactions in the transaction pool to the on-chain or off-chain execution nodes; the on-chain and off-chain execution nodes select the linear consistency or sequential consistency protocol based on the consistency requirements to carry out on-chain and off-chain parallel execution of the transaction; According to the execution of complex asset transactions at the verified asset granularity or asset attribute granularity on or off the chain, the asset information in the account-asset relationship representation model is merged to ensure asset integrity and consistency, including: for complex asset transactions at the asset granularity, the on-chain verification node group sends the verified transaction signature and MMPT tree to the submission node; the submission node will update the hypergraph in the off-chain storage node and the on-chain node storage index as soon as it receives the message that the verification has passed from the on-chain verification node group, change the attribute status list in the on-chain node storage index to all normal, increase the corresponding hypergraph version number by one, and the submission node packages the transaction on the chain and updates the MMPT tree; for complex asset transactions at the asset attribute granularity, an off-chain storage node group is added to merge the asset information according to the asset version number after the transaction is completed, and update the off-chain hypergraph G.

2. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1 is characterized in that: The account-asset relationship representation model for multi-ownership, multi-dimensional, complex assets is established through the off-chain hypergraph and the on-chain node storage index, including: Constructing accounts, representations of multi-ownership, multi-dimensional complex assets: Account ID , account address express: ; Complex assets with multiple ownership and dimensions are uniquely identified by assets , asset attribute content, attribute status list , transaction ID list , asset version number and a list of holding accounts express: ； The asset attributes of multi-ownership, multi-dimensional, complex assets are expressed as follows: ,in, Indicates the asset attribute number, Indicates the asset attribute content corresponding to the asset attribute number; Each asset attribute has two states: normal state, represented by the number 1, indicating that the asset attribute is readable and writable; locked state, represented by the number 0, indicating that the asset attribute is neither readable nor writable: , the state set of asset attributes constitutes the attribute state list , where the attribute status list of the asset is used to control the transaction conflict granularity, and provides locking and readable and writable status control to achieve linear consistency or sequential consistency; Based on the representation of accounts, multi-ownership and multi-dimensional complex assets, an account-asset relationship representation model of multi-ownership and multi-dimensional complex assets is established, where: The relationship between account assets is organized using a hypergraph off-chain. Account information is stored in the vertices of the hypergraph, and asset information is stored in the hyperedges of the hypergraph. The off-chain hypergraph is represented as: ； in, is the vertex set of the hypergraph, account is a vertex in the vertex set; is the hyperedge set of the hypergraph, and the hyperedge ; The chain anchors the hash address of the off-chain asset, and configures the on-chain node storage index on the chain. The on-chain node storage index is expressed as: ; Among them, the on-chain node storage index is<key,value> The data is organized in the form of key, which stores the account ID and vertex Hyperedge number , value stores the hash address of the hyperedge where the vertex is located , a list of asset's property states and asset version number .

3. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 2 is characterized in that: The correspondence between the vertex hyperedges in the on-chain node storage index is designed as an MMPT tree and stored in the block. In the MMPT tree, the leaf node is associated with the asset-related account. The leaf node contains the asset hash address, the asset's attribute status list and the asset version number. , the parent branch node of the leaf node records the hash of the corresponding leaf node, and the root node records the hash of the corresponding branch node.

4. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1 is characterized in that: Verification node group determines transaction request The legality includes: The signature verification of the requested account in the transaction request is passed; The asset attribute status list corresponding to the transaction request is "all normal" or the status of a certain attribute of the corresponding asset is "normal"; In the on-chain node storage index, whether the account in the transaction request has the right to hold the asset.

5. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1 is characterized in that: For legitimate transaction requests, the on-chain diversion node group and the off-chain execution node representatives conduct Stackelberg games based on the on-chain and off-chain transaction benefits, and divide the transactions in the transaction pool into on-chain or off-chain execution nodes, including: The calculation method of on-chain transaction income is: ， in, is the number of transactions executed on the chain, is the selling price function of a single transaction, The on-chain share ratio is configured based on the on-chain contribution to the verification of off-chain delivered transactions, since off-chain transactions are delivered to the on-chain for verification. The number of successful transactions delivered off-chain. is the cost of executing a single transaction on the chain, Use constant express, Take a constant for the cost of verifying a single transaction on the chain , The total number of transactions executed off-chain; The calculation method of off-chain transaction income is: ,in, The cost of executing a single transaction off-chain, taken as a constant ; Single transaction price function ,in, The total transaction volume on and off the chain ; is the selling price coefficient, , is a constant, , Two basic factors and Decide, The relationship between the number of pending transactions in the current transaction pool and the number of transactions contained in the previous block is determined as follows: Configure no less than 2 to the first threshold , hour, Represents the number of transactions in the previous block Much larger than the number of transactions waiting to be processed in the transaction pool , indicating that the current chain load is low, ; hour, Represents the number of transactions in the previous block Slightly larger than the number of transactions waiting to be processed in the transaction pool , the current chain load, ; hour, Represents the number of transactions in the previous block Less than or equal to the number of transactions waiting to be processed in the transaction pool , the current chain load is high, ; It is the ratio of the number of transactions contained in the previous block to the number of standard transactions in the block: , is the number of transactions in the previous block, is the standard transaction number of the block; Assume that the success rate of off-chain transaction execution is ,Right now: ； The on-chain revenue function is: ； The off-chain revenue function is: ， Off-chain revenue function Taking the derivative, we get the relationship between the optimal off-chain transaction volume and the number of transactions executed on the chain: ； Substituting the relationship between the optimal off-chain transaction volume and the number of transactions executed on the chain into the on-chain revenue function, we get: ； On-chain revenue function Taking the derivative, the optimal transaction volume on the chain is: ； The relationship between the best transaction volume on the chain and the number of transactions executed on the chain is the best transaction volume off the chain: 。 6. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1 is characterized in that: The execution nodes on and off the chain execute transactions in parallel, including: The workflow engine contract is a transaction request The account address set involved in the multi-person off-chain channel is used to open an off-chain execution node in the multi-person off-chain channel; For transactions conducted on the chain through game decisions, the on-chain execution node obtains the specific asset attribute content from the off-chain according to the hash address of multi-ownership and multi-dimensional complex assets, executes the transaction and signs it; For transactions conducted off-chain through game decisions, each off-chain execution node in the multi-person off-chain channel will process the transaction request. The asset attributes of the account jointly held are involved in multiple indirect transactions and signed. Each indirect transaction has a signature of all the executing node groups. After all the indirect transactions, the final transaction result satisfies the transaction request of the account. The corresponding needs.

7. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1 is characterized in that: Transaction verification methods include: After the on-chain execution node group completes the transaction, they attach their respective signatures and send the transaction results and signatures to the on-chain verification node group for verification. The verification node group recognizes the transaction results that are consistent with the signatures of more than 2 / 3 of the on-chain execution nodes; After the off-chain transaction is executed, the off-chain execution node group in the multi-person off-chain channel sends the indirect transaction signature to the on-chain verification node group respectively. The submitted signatures form a set of signatures. The verification node group receives the complete set of signatures of multiple groups of off-chain execution nodes and caches them. The latest set of signatures is marked with a tag to indicate that the signature will not be updated again; the verification node group configures the maximum number limit for the signatures of multiple indirect transactions of each off-chain execution node based on the on-chain workflow engine contract, and uses the time of packaging and block generation on the chain as the counting starting reference. The number of indirect transactions does not exceed the maximum number limit; the on-chain verification node group consensuses the latest set of signatures of all relevant off-chain execution nodes before the mth block is generated; before the mth block on the chain is generated, the off-chain execution nodes submit the signatures of multiple indirect transactions respectively. When the latest set of signatures and the transaction execution results pass the verification, it means that the off-chain execution is successful; otherwise, it will look forward to find the previous set of signatures. If the previous set of signatures passes the verification, the corresponding off-chain transaction result is determined, and so on.

8. A device for implementing a method for ensuring consistency between complex assets on-chain and off-chain that supports multiple protocols, characterized in that: include: At least one processing unit, the processing unit is connected to a storage unit via a bus unit, the storage unit stores a computer program, and when the computer program is executed by the processing unit, the method for ensuring consistency between on-chain and off-chain complex assets supporting multiple protocols as described in any one of claims 1-7 is implemented.

9. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for ensuring on-chain and off-chain consistency of complex assets supporting multiple protocols as described in any one of claims 1 to 7 is implemented.

Images