Complex asset chain up-chain and down-chain consistency guaranteeing method supporting multiple protocols

Abstract

The invention relates to a method for guaranteeing consistency between an upper link and a lower link of a complex asset chain supporting multiple protocols. The method comprises the following steps: establishing an account-asset relationship representation model of multi-ownership multi-dimensional complex assets; for a complex asset transaction, a verification node, an on-chain execution node, a shunting node and an off-chain node cooperate to perform on-chain and off-chain cooperative transaction execution, and the method comprises the following steps: a verification node group judges the legality of a transaction request; for a legal transaction request, the on-chain shunt node group and the off-chain execution node representative carry out the Stackelberg game according to the transaction income, and the transactions in the transaction pool are divided to the on-chain or off-chain execution nodes; the on-chain execution node and the off-chain execution node adjust conflict judgment granularity according to consistency requirements, and a linear consistency protocol or a sequential consistency protocol is selected to carry out on-chain and off-chain parallel execution on the transaction; and merging information of assets in the account-asset relationship representation model according to the on-chain and off-chain verified transaction execution conditions, thereby ensuring the integrity and consistency of the assets.

Description

Technical Field

[0001] The present invention relates to the technical field of complex asset chain transaction execution, and in particular to a complex asset chain consistency assurance method supporting multiple protocols. Background Art

[0002] Blockchain is a new type of data management technology that can effectively realize the trustworthiness and verifiability of multi-party data, with the characteristics of being distributed, tamper-proof, and highly transparent. 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 risen sharply. However, the computing and storage resources on the chain are limited, and the current blockchain technology is still difficult to achieve enterprise-level support capabilities for massive and complex asset transactions.

[0003] In order to reduce 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 guaranteed by hash verification, "optimistic concurrency" and other protocols. However, these protocols are mostly designed for token assets. The content ownership of token assets is relatively simple. For multi-ownership and multi-dimensional complex assets with complex content and ownership, the current blockchain technology is difficult to support its on-chain and off-chain consistency collaboration. The reason is: First, it cannot handle complex ownership in collaboration. Each multi-ownership and multi-dimensional complex asset has many stakeholders, and the stakeholders are related to specific asset attributes. How to decompose the asset ownership structure and carry out off-chain collaboration becomes a problem. For example, the optimistic concurrency protocol cannot accurately divide and combine off-chain asset behaviors according to 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. Consistency protocols based on different granularities are suitable for different scenarios. How to be compatible with multiple consistency protocols becomes a problem. For example, a single hash check can determine the overall consistency of an asset, but cannot accurately locate the location of a conflict. Lock-based version control can achieve fine-grained consistency, but its efficiency is much lower than hash checking.

[0004] Therefore, in the face of the transaction needs of multi-ownership, multi-dimensional and complex assets, the first thing to do is to achieve coordinated execution between on-chain and off-chain, breaking the efficiency expansion bottleneck of pure on-chain execution. Secondly, it is necessary to ensure data consistency in the on-chain and off-chain collaboration process, achieve compatible support for multiple types of consistency protocols, ensure data security, and finally reasonably balance and distribute on-chain and off-chain transactions to achieve further performance adaptation. 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 consistency between 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] Account ID j , account address addr j Means: Account j =(ID j ,addr j ).

[0013] 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:

[0014]

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

[0016] [(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;

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

[0018] 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:

[0019] 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.

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

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

[0022] Where V = {Account1, Account2, ... Account j ,......} is the vertex set of the hypergraph, Account j =(ID j ,addr j ) is a vertex in the vertex set;

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

[0024]

[0025] 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:

[0026] Among them, the on-chain node storage index is<key,value> The data is organized in the form of a key, where the account ID and the number of hyperedges dG(v) where the vertex v is located are stored, and the value is the hash address H(e i ), the asset's attribute state list List_State and the asset version number

[0027] Furthermore, 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.

[0028] Furthermore, the verification node group determines the transaction request Tx req The legality includes:

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

[0030] The asset attribute status list corresponding to the transaction request is "all normal" or the corresponding asset attribute status 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 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, including:

[0033] The calculation method of on-chain transaction income is:

[0034]

[0035] Among them, q on is the number of transactions executed on the chain, P(Q) is the price function of a single transaction, and α is the on-chain share ratio. Since off-chain transactions are delivered to the chain for verification, the on-chain share ratio is configured based on the contribution of the chain to the verification of off-chain delivered transactions. is the number of successful transactions delivered off-chain, c on is the cost of executing a single transaction on the chain, c on Use constant a to represent, c v Take constants b and q for the cost of verifying a single transaction on the chain off The total number of transactions executed off-chain;

[0036] The calculation method of off-chain transaction income is:

[0037] Among them, c off The cost of executing a single transaction off-chain is taken as a constant c;

[0038] The price function of a single transaction is P(Q) = M·Q, where Q is the total transaction volume on and off the chain. M is the price coefficient, M>0, M is a constant, M=M1+M2, M is determined by two basic factors M1 and M2. M1 is determined based on the relationship between the number of pending transactions in the current transaction pool and the number of transactions contained in the previous block, including:

[0039] 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 |Much larger than the number of transactions waiting to be processed in the transaction pool|Tx pool |, indicating that the current chain load is low, 0 <M1<1;

[0040] |Tx pool |<|Tx Bpre |≤β1|Tx pool |Time,|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 chain load, M1=1;

[0041] |Tx Bpre |≤|Tx pool |Time,|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 chain load is high, 1 <M1;

[0042] M2 is the ratio of the number of transactions contained in the previous block to the number of standard transactions in the block: M2 = |Tx Bpre | / |Tx Bstan |,|Tx Bpre | is the transaction number of the previous block, |Tx Bstan | is the standard transaction number of the block;

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

[0044]

[0045] The on-chain revenue function is:

[0046]

[0047] The off-chain revenue function is:

[0048]

[0049] 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:

[0050]

[0051] 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:

[0052]

[0053] The on-chain revenue function is q on Taking the derivative, the optimal transaction volume on the chain is:

[0054]

[0055] 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:

[0056]

[0057] Furthermore, the execution nodes on and off the chain execute transactions in parallel, including: the workflow engine contract is the transaction request Tx req 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;

[0058] 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;

[0059] 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 Tx req The asset attributes of the account jointly held in the transaction 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 account's transaction request Tx req The corresponding needs.

[0060] Furthermore, transaction verification methods include:

[0061] 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;

[0062] 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.

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

[0064] For complex asset transactions at the asset granularity level, the on-chain verification node group sends the verified transaction signature and MMPT tree to the submitting node; the submitting node will update the hypergraph in the off-chain storage node and the on-chain node storage index as soon as it receives the verification message from the on-chain verification node group, change the attribute state list List_State in the on-chain node storage index to all normal, increase the version number of the corresponding hypergraph by one, and the submitting node packages the transaction on the chain and updates the MMPT tree;

[0065] For complex asset transactions with asset attribute granularity, an off-chain storage node group is added to merge asset information according to the asset version number after the transaction is completed, and the off-chain hypergraph G is updated.

[0066] In a second aspect, the present invention provides a device for implementing a method for ensuring consistency between on-chain and off-chain complex assets supporting multiple protocols, comprising: at least one processing unit, the processing unit being connected to a storage unit via a bus unit, the storage unit storing 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 is implemented.

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

[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] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

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

[0074] Figure 2 A flowchart of a complex asset transaction at an asset granularity or an asset attribute granularity provided in an embodiment of the present invention, in which a verification node, an on-chain execution node, a submission node, and an off-chain node cooperate to perform on-chain and off-chain collaborative transaction execution;

[0075] Figure 3 An architectural diagram of complex asset transactions at asset granularity or asset attribute granularity provided in an embodiment of the present invention, in which verification nodes, on-chain execution nodes, submission nodes, and off-chain nodes cooperate to perform collaborative transaction execution on and off the chain;

[0076] Figure 4 A schematic diagram of an MMPT tree provided in an embodiment of the present invention;

[0077] Figure 5 A schematic diagram of an apparatus for implementing a method for ensuring on-chain and off-chain consistency of complex assets supporting multiple protocols provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0078] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0079] In order 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 a stakeholder of asset ownership.

[0081] Multi-ownership, multi-dimensional complex assets: digital assets with at least one dimension of asset attributes that can belong to different accounts (holding accounts or using accounts).

[0082] Asset attributes: Assets can be divided into multiple dimensions, independent of each other, and non-interfering classifications that describe the specific content of the assets, such as the ID card, age, and gender of an electronic ID card.

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

[0084] Linear consistency: Transactions related to multi-ownership, multi-dimensional, complex assets are distributed from the on-chain to the off-chain for collaborative execution. Before the transaction is executed, the asset should have the same starting 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 pre-distribution order on the chain. Therefore, after the transaction is executed, the asset should reach a completely consistent and deterministic state between the off-chain and on-chain. For example, transactions related to a certain asset Z satisfy the order of Tx1>Tx2>Tx3, and each off-chain node executes the transaction in this order. The result after execution should be completely consistent with the expected transaction result on the chain. At this time, the asset Z on the chain and off-chain is consistent.

[0085] Sequential consistency: Transactions related to multi-ownership, multi-dimensional, and complex assets are distributed from the chain to the off-chain for coordinated execution. Before the transaction is executed, the asset should have the same starting state on the chain and off-chain. However, after the transaction is distributed to the off-chain, the transaction order observed by different off-chain nodes is not the same, and it is also different from the pre-distribution order on the chain. However, the change in transaction order does not bring about a change in the transaction execution result, that is, the sum of the states achieved by the assets off-chain after the transaction is executed is exactly the same as the expected state on the chain. This is achieved by reasonably handling conflicts in asset ownership and attributes in transactions. For example, transactions Tx1, Tx2, and Tx3 regarding asset Z will all change the content of Z. In order to avoid asset inconsistency after the transaction is executed off-chain, potential conflicts should be resolved. Suppose the execution result of transaction Tx1 related to a certain 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. After execution, the status of assets on and off the chain remains consistent.

[0086] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0087] Example 1

[0088] like Figure 1 As shown, the technology of the present invention realizes a method for ensuring consistency of complex assets on-chain and off-chain that supports multiple protocols, which is applied to the massive transaction execution scenarios of multi-ownership 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, 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. 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 multi-ownership multi-dimensional complex assets by the blockchain system, and to ensure the data consistency of multi-ownership multi-dimensional complex assets in the on-chain and off-chain collaborative execution process. The data consistency includes linear consistency and sequential consistency, and finally the expansion of blockchain performance is realized through the trusted collaborative execution of on-chain and off-chain.

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

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

[0091] 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 are divided into verification nodes, on-chain execution nodes, diversion nodes and submission nodes according to the on-chain node sorting.

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

[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: normal state, represented by the number 1, which indicates that the asset attribute is readable and writable; locked state, represented by the number 0, which indicates that the asset attribute is unreadable and unwritable: State∈{0,1}. The state set of 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 multi-ownership multi-dimensional complex assets and the subsequent operations that can be performed. There are three types of attribute state lists List_State∈{List_State1, List_State2, List_State3}, List_State1 indicates that all are normal [1,1,1,...,1], List_State2 indicates that all are locked [0,0,0,...,0], and List_State3 indicates that part is normal and part is locked [1,0,1,...,0]. The attribute state list provides corresponding locking and readable and writable states for asset granularity or asset attribute granularity. The control of linear consistency or sequential consistency in the transaction process is achieved by using the legitimacy verification of the attribute state list, the locking and readable and writable states provided by the attribute state list, and the one-time readable and writable state authorization of the asset attribute granularity to only allow the modification of the corresponding asset attribute once.

[0104] An account-asset relationship representation model for multi-ownership multi-dimensional complex assets is established, which is divided into two parts: on-chain and off-chain. The account-asset relationship representation model is compatible with the relationship between accounts and assets that represent multi-ownership one-dimensional assets. Off-chain hypergraphs are used to organize the relationship between account assets. Account information is stored in the hypergraph vertices, asset information is stored in the hypergraph hyperedges, and the hypergraphs 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. In the account-asset relationship representation model of the present invention, the on-chain nodes all store the on-chain node storage index, and the off-chain hypergraph is stored to organize the ownership relationship of the account-asset and store the specific content of the asset. In the present invention, all accounts on the chain can view each other's asset content and are all accounts using 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 authority to collaboratively read and write asset content.

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

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

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

[0108] E={Hedge1,Hedge2,...Hedge i ,......} is the hyperedge set of the hypergraph, and the hyperedge:

[0109]

[0110] The node storage index on the chain is represented as:

[0111] Among them, the on-chain node storage index is<key,value> The data is organized in the form of a key, where the account ID and the number of hyperedges where the vertex v is located (the number of assets held by the account) dG(v) are stored, and the value stores the hash address H(e) of the hyperedge where the vertex is located (the assets held by the account). i ), the asset's attribute state list List_State and the asset version number

[0112] The node storage index on the chain itself is not tamper-proof. The vertex-hyperedge correspondence in the node storage index on the chain is designed as an MMPT tree and stored in the block, such as Figure 4 As shown, 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. Whenever the situation of the account holding assets changes or the version of the assets changes, the value of the leaf node of the MMPT tree changes, and the root node hash will be inconsistent with the leaf node content hash for tamper-proofing.

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

[0114] S21, the on-chain verification node group determines the legitimacy 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 reqReq_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 , stripping off the necessary information and sending 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, the transaction corresponding to the transaction request that has passed the legality judgment is placed in the transaction pool for processing. The transaction is marked with the unique identifier of the asset changed by the transaction. i / The ID of the asset attribute that was changed by the transaction i_y, the Hash address corresponding to the changed asset is Cha_asset i_y , transaction ID Tx_Id, transaction party signature set Sign + and asset version number express:

[0124]

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

[0126] S221, the on-chain diversion node group and the off-chain execution node representative analyze the number of pending transactions in the transaction pool according to the resource balancing module, and configure the selling price coefficient M according to the number, M>0, M is a constant, M=M1+M2, and M is determined by two basic factors M1 and M2.

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

[0128] During the specific implementation process, the on-chain and off-chain nodes are regarded as a system as a whole. If the transaction is successful, both parties will gain benefits separately. The on-chain needs to verify its own transactions and those delivered off-chain. The on-chain share ratio is configured based on the on-chain contribution to the verification of off-chain delivered transactions.

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

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

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

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

[0133] The price function of a single transaction is P(Q) = M·Q, where Q is the total transaction volume on and off the chain, which is less than the pending transaction volume. M is the selling price coefficient, M > 0, M is a constant, M = M1 + M2, M is determined by two basic factors M1 and M2. M1 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] configured 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 greater 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 < M1 < 1, such as M1 = 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 greater than the number of transactions waiting to be processed in the transaction pool |Tx pool |, the current on-chain load is medium, M1 = 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 < M1, such as M1 = 1.1;

[0137] M2 is the ratio of the number of transactions in the previous block to the standard number of transactions in the block: M2 = |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, |Tx Bstan | value depends on the actual situation and serves as a measure of the load standard size. When the number of transactions in the previous block |Tx Bpre | is greater than the standard number of transactions in the block |Tx Bstan |, M2 > 1, indicating that the current node load is relatively large, and the consumption of resources such as computing is high, so the transaction fee will also be adjusted upwards accordingly; when the number of transactions in the previous block |Tx Bpre | is less than the standard number of transactions in the block |TxBstan |, the current block's 1>M2>0, that is, the current node load is small, the computing resources are low, and each node is idle, which will reduce transaction fees.

[0138] c on =∑(BaseFee·gasAmount), BaseFee is the unit price of transaction meta-operation consumption, gasAmount is the number of transaction meta-operations. Within a limited time period, the block size is constant, and the unit price consumed by all transaction meta-operations in the block is consistent. The execution of transactions 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 the same, and the average number of all transaction meta-operations within the limited time period is taken, then c on It can be represented by the constant a.

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

[0140] c v = b;

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

[0142] c off =c.

[0143] The number of transactions successfully delivered off-chain is The total number of transactions executed off-chain is q off .Right now The transaction is executed off-chain and submitted to the chain for verification successfully. A transaction failed to pass the on-chain verification after being executed off-chain, regardless of whether the reason for failure was insufficient off-chain computing power or a problem with the off-chain network that resulted in failure to reach off-chain consensus. Then, assuming that the success rate of off-chain transaction execution is λ, that is:

[0144]

[0145] The on-chain revenue function is:

[0146]

[0147] The off-chain revenue function is:

[0148]

[0149] 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:

[0150]

[0151] 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:

[0152]

[0153] The on-chain revenue function is q on Taking the derivative, the optimal transaction volume on the chain is:

[0154]

[0155] 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:

[0156]

[0157] At this point, the transaction equilibrium point between on-chain and off-chain is reached, that is, under the corresponding optimal on-chain and off-chain total transaction volume, the on-chain and off-chain obtain the maximum benefits respectively, and the on-chain and off-chain as a whole obtain the maximum benefits. The total transaction volume between on-chain and off-chain is calculated as:

[0158]

[0159] Substituting the optimal transaction volume on the chain and off the chain into the profit function on the chain and off the chain respectively, we can get their respective profits:

[0160]

[0161] S23, the execution nodes on the chain and off the chain execute the transaction in parallel;

[0162] S231, workflow engine contract is transaction request Tx req 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.

[0163] S232, for transactions conducted on the chain after game decision-making, 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.

[0164] S233, for transactions conducted off-chain after game decision, each off-chain execution node in the multi-person off-chain channel will execute the transaction request Tx req The asset attributes of the account jointly held in the transaction 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 account's transaction request Tx req The corresponding needs.

[0165] S24, on-chain and off-chain transaction signatures, the verification node group verifies the transaction based on the transaction signature.

[0166] S241, the on-chain transaction is completed, and 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 transaction verification methods include:

[0167] 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.

[0168] S242, the off-chain transaction is completed, and the off-chain execution node group in the multi-person off-chain channel sends signatures to the on-chain verification node group respectively. The submitted signatures form a set of signatures for verification. The transaction verification method of the off-chain execution node group includes: after the off-chain transaction execution is completed, 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, and the submitted signatures constitute a set of signatures. The verification node group receives the complete set of signatures of multiple sets of off-chain execution nodes and caches them, wherein the latest set of signatures is set with a tag to indicate that the signature will not be updated again; the verification node group configures the maximum number limit of signatures of multiple indirect transactions for each off-chain execution node based on the on-chain workflow engine contract, and takes the time of packaging and producing blocks on the chain as the counting starting reference, and 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 produced; before the mth block on the chain is produced, the off-chain execution nodes submit the signatures of multiple indirect transactions respectively, and 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 for the previous set of signatures, and if the previous set of signatures passes the verification, the corresponding off-chain transaction result is determined, and so on.

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

[0170] S31, the on-chain verification node group sends the verified transaction signature and MMPT tree to the submitting node;

[0171] S32: The submitting node does not have to wait until the block is packaged to update the off-chain data. The submitting node will update the hypergraph in the off-chain storage node as soon as it receives the message that the on-chain verification node group has passed the verification.

[0172] S33, the submitting node updates the on-chain node storage index as soon as possible, changes the attribute state list List_State in the on-chain node storage index from List_State2 to List_State1, increases the version number of the corresponding hypergraph by one, packages the transaction on the chain, and updates the MMPT tree.

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

[0174] When the granularity of the transaction request is asset attributes, the asset merging rules are as follows: When the attribute state list List_State changes from List_State1 to List_State3 and then to List_State2, it means that the asset attribute has been modified once. At this time, the asset needs to merge multi-dimensional asset attributes. The submitting node finds the same asset version number from the transaction, 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 changes the storage index of the node on the chain and the content of the hypergraph G off-chain accordingly: 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 increase the asset version number by one, update the holding account list List_holders to the latest List_holders', and update List_State2 to List_State1. S34 merges the latest asset attribute specific content asset' of each dimension of the asset Asset and updates it into the latest asset Asset'. When merging, the modification time and content are distinguished by the asset version number. Assets with the same version number are merged together. Hyperedges / hypergraphs with larger version numbers occur later than those with smaller version numbers and have newer content.

[0175] When the granularity of the transaction request is an asset, asset merging means that the asset is replaced with the old one based on the version number, and does not involve merging multiple dimensions into a complete asset. In this case, only S32 and S33 are required, and S34 is not required.

[0176] In this application, when an on-chain transaction or a set of off-chain transactions modifies the attributes of a certain dimension of an asset and signs it, 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. Asset attributes of different dimensions of an asset can be modified in parallel by its co-holding accounts, and the modification results of different attributes are independent of each other. Asset holding accounts can modify different assets or asset attributes they hold in parallel, and the modification results of different attributes are independent of each other. Under the same asset version number, the attributes that have been modified most recently by the transaction will be merged together to form a complete asset.

[0177] An example of sequential consistency:

[0178] In the medical context, the digital asset "Medical Institution Practice License ML" (electronic) has joint holding accounts of the Ministry of Health DH, the Centers for Disease Control and Prevention DPC, and the Drug Administration DA, and its joint use 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 conditions" numbered "1" and "validity period of practice license" numbered "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's practice license ML from "normal business" to "suspended for rectification". The Food and Drug Administration DA requests to modify the content of the attribute 2 "validity period of practice license" of the medical institution's practice license ML from "10 years" to "5 years".

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

[0181] Tx req DA={Req_rw_ML_2,addr p The attribute number of the asset requested to be read or written, the account address of the requested transaction, and the account signature in DA, SigReqDA} 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 requesting the transaction, the Ministry of Health DH and the Drug Administration DA, have the right to hold the asset medical institution practice license ML, and have the authority to modify the attributes of the medical institution practice license ML, and that the resource attribute 1 of the medical institution practice license ML is in a "normal" state and can be modified by the holding account, and the resource attribute 2 of the medical institution practice license ML is in a "normal" state and can be modified by the holding account.

[0183] S214, the data access control contract changes the status of 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 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 will Tx req DH, Tx req The transaction corresponding to DA is added to the transaction pool and waits for diversion and execution.

[0185] S221, there are many pending transactions in the transaction pool, M1=1.1, M2=1.25.

[0186] S222, for legitimate transaction requests, the on-chain diversion node group determines their respective transaction income based on the transaction costs and selling prices on and off the chain, and performs a Stackelberg game on the allocated transaction volume based on the transaction income of both chains, and divides the transactions in the transaction pool to the execution nodes on or off the chain. Tx req DH is executed on the 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. The specific content of the resource attribute 1 of the medical institution practice license ML is stored by the hash address H(e) in the on-chain node storage index. ML ) anchored 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 the resource attribute 2 of the medical institution practice license ML is stored by the hash address H(e) in the on-chain node storage index. ML ) anchored and found in the off-chain storage node.

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

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

[0192] S31, both transaction results are verified by the verification node group through consensus and sent to the submitting node.

[0193] S32, the resource attribute 1 of the medical institution practice license ML in the off-chain hypergraph G is changed from "normal operation" to "suspended for rectification", and the resource attribute 2 of the medical institution practice license ML is changed from "10 years" to "5 years".

[0194] S33, the status of resource attribute 1 of the medical institution practice license ML in the on-chain node storage index is changed from "locked" to "normal", and the status of resource attribute 2 is changed from "locked" to "normal", and the resource version number is increased by one; a new MMPT tree leaf node is added to record the change of the version number of the medical institution practice license ML.

[0195] S34, the resource version number of the medical institution practice license ML is increased 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 transaction involving the medical institution practice license ML remains linearly consistent after being executed by the on-chain and off-chain collaborative transaction system. req DH and Tx req The order of DA, and whether Tx req DA first or Tx req DH comes first, and there are no transaction results related to the medical institution practice license ML in the block. The asset unique identification, asset specific content, attribute status list, transaction ID list, asset version number, and account-asset correspondence of the asset medical institution practice license ML on and off the chain are consistent.

[0197] Example of linearizability:

[0198] In the medical context, the digital asset "Medical Institution Practice License ML" (electronic) has joint holding accounts of the Ministry of Health DH, the Centers for Disease Control and Prevention DPC, and the Drug Administration DA, and its joint use 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 conditions" 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 medical institution practice license ML from "normal operation, 10 years" to "normal operation, 15 years".

[0200] S212, transaction request Tx req DPA={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 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 account Center for Disease Control and Prevention DPA requesting the transaction has the right to hold the asset medical institution practice license ML, has the authority 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 the 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 medical institution practice license ML from "normal operation, 10 years" to "suspension 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, so M1=0.9 and M2=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 by the hash address 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 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.

[0216] S213, the verification node group calls the data access control contract to determine that the account Ministry of Health DH requesting the transaction has the right to hold the asset medical institution practice license ML, has the authority 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 will Tx req The transaction corresponding to DH is added to the transaction pool and waits for diversion and execution.

[0219] S221, there are few pending transactions in the transaction pool, and M1=0.9 and M2=0.8 are obtained.

[0220] S222, determined by the game between the on-chain and off-chain parties, Tx req DH is performed 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 stored in the on-chain storage node index by the hash address H(e ML ) anchored and found in the off-chain storage node.

[0223] S242, the off-chain execution node group submits the transaction results and signatures to the verification node group.

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

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

[0226] 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 leaf node of the MMPT tree is added to record the change of the resource version number of the medical institution practice license ML.

[0227] After this process, the transactions involving the medical institution practice license ML are executed by the on-chain and off-chain collaborative transaction systems to maintain the same order. req DPA>Tx req The order of DH. The asset unique identifier, asset specific content, attribute status list, transaction ID list, asset version number, and account-asset correspondence of the asset medical institution practice license ML on the chain and off the chain are consistent.

[0228] Example 2

[0229] See also Figure 5 As shown, an embodiment of the present invention provides a device for implementing a method for ensuring consistency between a complex asset chain and off-chain assets supporting multiple protocols, including: at least one processing unit, the processing unit is connected to a storage unit via a bus unit, the storage unit is a computer-readable storage medium, and 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 consistency between a complex asset chain and off-chain assets supporting multiple protocols in an embodiment of the present invention. The processing unit implements the above-mentioned method for ensuring consistency between a complex asset chain and off-chain 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 for multi-ownership, multi-dimensional, complex assets through off-chain hypergraphs and on-chain node storage indexes;

[0231] 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;

[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 only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, structures or units, which can be electrical, mechanical or other forms.

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

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

[0243] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may 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 the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for ensuring the consistency of complex assets on and off the chain that supports multiple protocols, which is applied to the massive transaction execution scenarios 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. 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 used to cooperate with the off-chain nodes 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 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; 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.

2. According to the method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols as described in claim 1, It 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 j , account address addr j Means: Account j =(ID j ,addr j ). 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: The asset attributes of multi-ownership, multi-dimensional and complex assets are expressed as follows: [(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; Each asset attribute has two states: normal state, represented by the number 1, which means that the asset attribute is readable and writable; locked state, represented by the number 0, which means that the asset attribute is unreadable and writable: State∈{0,1}, the state set of asset attributes constitutes the attribute state list List_State, where the asset attribute state list is used to control the transaction conflict granularity, and provides locking and readable and writable state 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: G={V,E,Ver G }; Where V = {Account 1 ,Account 2 ,......Account j ,......} is the vertex set of the hypergraph, Account j =(ID j ,addr j ) is a vertex in the vertex set; E={Hedge 1 ,Hedge 2 ,......Hedge i ,......} 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 a key, where the account ID and the number of hyperedges dG(v) where the vertex v is located are stored, and the value is the hash address H(e i ), the asset's attribute state list List_State and the asset version number 3. According to the method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols as described in claim 2, It 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, It is characterized in that Verification node group determines transaction request Tx req 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, It 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: Among them, q on is the number of transactions executed on the chain, P(Q) is the price function of a single transaction, and α is the on-chain share ratio. Since off-chain transactions are delivered to the chain for verification, the on-chain share ratio is configured based on the contribution of the chain to the verification of off-chain delivered transactions. is the number of successful transactions delivered off-chain, c on is the cost of executing a single transaction on the chain, c on Use constant a to represent, c v Take constants b and q for the cost of verifying a single transaction on the chain off The total number of transactions executed off-chain; The calculation method of off-chain transaction income is: Among them, c off The cost of executing a single transaction off-chain is taken as a constant c; The price function of a single transaction is P(Q) = M·Q, where Q is the total transaction volume on and off the chain. M is the selling price coefficient, M>0, M is a constant, M=M 1 +M 2 , M consists of two basic factors M 1 and M 2 Decision, M. 1 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 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 | Far greater than the number of transactions waiting to be processed in the transaction pool Tx pool |, indicating that the current chain load is low, 0 <M 1 <1; |Tx pool |<|Tx Bpre |≤β 1 Tx pool |Time,|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 |, the current chain load, M 1 =1; |Tx Bpre \≤|Tx pool |Time,|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 chain load is high, 1 <M 1 ; M 2 M is the ratio of the number of transactions in the previous block to the number of standard transactions in the block: 2 =|Tx Bpre | / Tx Bstan \,|Tx Bpre | is the transaction number of the previous block, |Tx Bstan | is the standard transaction number of the block; Assume that the success rate of off-chain transaction execution is λ, that is: 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: The on-chain revenue function is q on 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, It is characterized in that The execution nodes on and off the chain execute transactions in parallel, including: The workflow engine contract is the transaction request Tx req 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 Tx req The asset attributes of the account jointly held in the transaction 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 account's transaction request Tx req The corresponding needs.

7. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1, It 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. The method for ensuring consistency between complex assets on-chain and off-chain supporting multiple protocols according to claim 1, It is characterized in that According to the complex asset transaction execution of the verified asset granularity or asset attribute granularity on the chain 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: For complex asset transactions at the asset granularity level, the on-chain verification node group sends the verified transaction signature and MMPT tree to the submitting node; the submitting node will update the hypergraph in the off-chain storage node and the on-chain node storage index as soon as it receives the verification message from the on-chain verification node group, change the attribute status list in the on-chain node storage index to all normal, increase the version number of the corresponding hypergraph by one, and the submitting node packages the transaction on the chain and updates the MMPT tree; For complex asset transactions with asset attribute granularity, an off-chain storage node group is added to merge asset information according to the asset version number after the transaction is completed, and the off-chain hypergraph G is updated.

9. A device for implementing a method for ensuring consistency between complex assets on-chain and off-chain that supports multiple protocols. It is 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-8 is implemented.

10. A computer-readable storage medium storing a computer program, It is 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 8 is implemented.

Images