CN113610643A

CN113610643A - Chain structure processing method, transaction data processing device, data verification method, data verification device and medium

Info

Publication number: CN113610643A
Application number: CN202110931943.6A
Authority: CN
Inventors: 郑杰骞
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-08-13
Filing date: 2021-08-13
Publication date: 2021-11-05
Also published as: WO2023015840A1

Abstract

The disclosed embodiment provides a chain structure processing method, a transaction data processing method, a data verification method, a device and a medium, wherein the chain structure is a license chain, the license chain comprises transaction data of a UTXO model and transaction data of a balance model, and the chain structure processing method comprises the following steps: the UTXO model performs a transfer-in transaction to the balance model, and/or the balance model performs a transfer-out transaction to the UTXO model. The transaction data processing method comprises the following steps: carrying out circulation of the token of the UTXO model and the balance model of the license chain to obtain data of a transfer-in transaction and/or data of a transfer-out transaction; merging a plurality of pieces of off-system verification data belonging to a permit chain of the same alliance chain into ledger data of the alliance chain, wherein the off-system verification data comprises one or more of the following: the data of the transfer-in transaction, the data of the transfer-out transaction and the transaction data of the UTXO model.

Description

Chain structure processing method, transaction data processing device, data verification method, data verification device and medium

Technical Field

The embodiments of the present disclosure relate to, but not limited to, the field of computer data processing technologies, and in particular, to a method for processing a chain structure, a method for processing transaction data, a method for verifying data, an apparatus for verifying data, and a computer-readable storage medium.

Background

In order to enable a plurality of independent private chain systems to form an alliance, tokens (tokens) issued by the alliance can be commonly circulated, and Transaction data of a private chain UTXO (Unspent Transaction Outputs) model can be merged into an alliance chain account book.

Disclosure of Invention

The following is a summary of the subject matter described in detail herein. This summary is not intended to limit the scope of the claims.

Provided herein are a processing method, a transaction data processing method, a data verification method, a storage medium, and a computer apparatus of a chain structure.

In one aspect, an embodiment of the present disclosure provides a processing method for a chain structure, where the chain structure is a license chain, and the license chain includes transaction data of a UTXO model and transaction data of a balance model, and the processing method includes:

the UTXO model carries out a transfer-in transaction to the balance model, and/or

The balance model performs a roll-out transaction to the UTXO model.

In another aspect, an embodiment of the present disclosure further provides a transaction data processing method in a chain structure, where the chain structure is a license chain, and the license chain includes transaction data of a UTXO model and transaction data of a balance model, and the transaction data processing method includes:

realizing the circulation of the token of the UTXO model and the balance model of the permit chain by adopting any one of the chain structure processing methods to obtain data of a transfer-in transaction and/or data of a transfer-out transaction;

merging a plurality of pieces of off-system verification data of permit chains belonging to the same alliance chain into ledger data of the alliance chain, wherein the off-system verification data of the permit chains comprises one or more of the following: the data of the transfer-in transaction, the data of the transfer-out transaction and the transaction data of the UTXO model.

In yet another aspect, an embodiment of the present disclosure further provides a chain structure transaction processing method for use in a chain-crossing transaction between the first license chain and the second license chain, where the first license chain uses a first algorithm, and the second license chain uses a second algorithm, and the chain structure transaction processing method includes:

when the first license chain and the second license chain are in cross-chain transaction, certification data with equal first amount represented by a first generation element coefficient of the first and second algorithm, and a first and second peterson commitment of the first and second algorithm output in cross-chain are generated.

In yet another aspect, an embodiment of the present disclosure further provides a data verification method for a chain structure, where the chain structure is a license chain, and the license chain includes transaction data of a UTXO model and transaction data of a balance model, and the data verification method includes:

a verifier outside the license chain verifies the data of the transferred-in transaction and/or the transaction data of the UTXO model.

In still another aspect, embodiments of the present disclosure further provide a computer-readable storage medium storing program instructions, which when executed, may implement the processing method of the chain structure, the transaction data processing method of the chain structure, or the chain structure data verification method.

In yet another aspect, embodiments of the present disclosure further provide a blockchain mechanism, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor can implement the aforementioned processing method of the chain structure, the processing method of the chain-structured transaction data, or the verification method of the chain-structured data when executing the program.

By adopting the chain structure processing method of the embodiment of the disclosure, the transfer between the UTXO model and the balance model can be realized by transferring into the transaction and transferring out the transaction, and the amount in the UTXO model is ensured to be consistent with the balance state in the balance model. By adopting the method for processing the transaction data with the chain structure, the permission chain data can be merged into the account book data of the alliance chain. By adopting the verification method of the chain structure data of the embodiment of the disclosure, the correct circulation of the token in the alliance chain is ensured. By adopting the chain-structured transaction processing method of the embodiment of the disclosure, the permission chains using different algorithms can be ensured to verify that the amounts are equal.

Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

Other aspects will be apparent upon reading and understanding the attached drawings and detailed description.

Drawings

The accompanying drawings are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the example serve to explain the principles of the invention and not to limit the invention.

FIG. 1 is a flow chart of a method for processing chain structure data according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of a data processing method including a verify operation according to an embodiment of the present disclosure;

FIG. 3 is a flow chart of a data validation method of an embodiment of the present disclosure;

FIG. 4 is a diagram illustrating data in a licensed chain block according to an embodiment of the present disclosure;

FIG. 5 is an example list of metadata in a license chain chunk with multiple asset types token according to an embodiment of the present disclosure;

fig. 6 is a diagram of an allowed chain block header data uplink alliance chain according to an embodiment of the present disclosure;

FIG. 7 is a block data diagram of a federation chain of embodiments of the present disclosure;

fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the disclosure.

Detailed Description

The present disclosure describes embodiments, but the description is illustrative rather than limiting and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the embodiments described in the present disclosure. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are possible. Any feature or element of any embodiment may be used in combination with or instead of any other feature or element in any other embodiment, unless expressly limited otherwise.

The present disclosure includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The embodiments, features and elements disclosed in this application may also be combined with any conventional features or elements to form a unique inventive concept as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive aspects to form yet another unique inventive aspect, as defined by the claims. Thus, it should be understood that any features shown and/or discussed in this disclosure may be implemented alone or in any suitable combination. Accordingly, the embodiments are not limited except as by the appended claims and their equivalents. Furthermore, various modifications and changes may be made within the scope of the appended claims.

Further, in describing representative embodiments, the specification may have presented the method and/or process as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. Other orders of steps are possible as will be understood by those of ordinary skill in the art. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. Further, the claims directed to the method and/or process should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and still remain within the spirit and scope of the embodiments of the present application.

The steps illustrated in the flow charts of the figures may be performed in a computer system such as a set of computer-executable instructions. Also, while a logical order is shown in the flow diagrams, in some cases, the steps shown or described may be performed in an order different than here.

Multiple independent private chains may form a federation, and UTXO model transaction data of the private chains may be merged into a federation chain ledger, but there is currently no solution for private chains that support balance models or private chains of different algorithms, such as SM2 national cryptographic algorithm and secp256k1 non-national cryptographic algorithms.

To this end, the embodiment of the present disclosure provides a processing method for a license chain. A grant chain means that every node participating in the blockchain system is granted. Nodes that are not licensed may not access the system. Herein, a license chain includes a private chain and a federation chain, where a private chain refers to a chain of enterprises, including a chain of a single enterprise and a chain in which multiple enterprises participate together (federation of enterprises); a federation chain refers to a federation chain (a federation of chains) in which multiple member chains merge. A private chain in this context may be equivalent to a license chain.

The disclosed embodiment provides a processing method of a chain structure, wherein the chain structure is a license chain, the license chain comprises transaction data of a UTXO model and transaction data of a balance model, and the processing method comprises the following steps:

The balance model performs a roll-out transaction to the UTXO model.

When there are both the roll-in transaction and the roll-out transaction, the present embodiment does not limit the execution order of the above-described roll-in transaction and roll-out transaction.

By the transfer-in transaction and the transfer-out transaction, the transfer between the UTXO model and the balance model can be realized, and the amount in the UTXO model is ensured to be consistent with the balance state in the balance model.

In an exemplary embodiment, the UTXO model performs a transfer-in transaction to a balance model, comprising: the UTXO model performs a direct transfer transaction to the balance model; or the UTXO model carries out indirect transfer transaction to the balance model; wherein: the input directly transferred into the transaction refers to the unspent output of the UTXO transaction, and the output is the user account address of the balance model; the indirect transfer transaction includes a first intermediate transaction whose input references the unspent output of the UTXO transaction and a first return transaction whose output is a user account address or a contract account address of a balance model. In the transfer process, under the indirect transaction scene, the actual transfer is completed only when the receipt transaction is completed. When multiple intermediate transactions are referenced, the response piece transaction may also be referred to as a confounding transaction. The user account address or contract account address of the balance model output by the response piece transaction cannot be output as an unspent and cannot be referenced to a cost.

In an exemplary embodiment, a first intermediate transaction in the indirect transfer transaction binds a first commitment of one or more recipients, an output of the first intermediate transaction is an intermediate transaction address, an input of the first intermediate transaction is one or more first intermediate transactions, an output of the first intermediate transaction is bound to a second commitment, the second commitment is a new commitment obtained after the first commitment is operated, and an address generated by the second commitment through the first operation is a user account address or a contract account address of the balance model.

In the embodiment of the present disclosure, the first commitment may be a public key of the user multiplied by a first coefficient, plus a first generator multiplied by a second coefficient, plus a second generator multiplied by a third coefficient, where the first coefficient may be, for example, 1, and the second coefficient may be, for example, 0. Obtaining a second commitment by operating on the first commitment, wherein the second commitment is the multiplication of a public key of the user and a fourth commitmentCoefficient, plus the second generator times a fifth coefficient, where the fourth coefficient may be equal to the first coefficient and the fifth coefficient may be 0. For example, the user public key P, the first generator G, the second generator H, the first commitment of the first intermediate transaction bound to a receiver is v₁*P+v₃H, the second commitment of the first receipt transaction output binding is C ═ v₄*P+v₅H. For example, the second commitment can be calculated as follows: the first commitment is multiplied by a scalar (which may be 1, i.e., constant), and the second generator is multiplied by a sixth coefficient to obtain a second commitment. The address of the user account output by the second promise after the first operation is Hash (C), namely v₄＝1，v₅0; or obtaining an output contract account address, wherein the contract account address is obtained by computing the user account address and a nonce value, so that the contract account address is Hash (C-v)₅*H)||v₅) I.e. v₄＝1，v₅Wherein Hash (C-v)₅H) is the user account address. The user account address and the contract account address may have an address type identification prefix.

In an exemplary embodiment, the balance model conducts a roll-out transaction to the UTXO model, comprising: the balance model performs a direct transfer-out transaction to the UTXO model, or the balance model performs an indirect transfer-out transaction to the UTXO model; wherein: the input of the direct transfer-out transaction is the user account address or contract account address of the balance model, and the output is the user primary address of the UTXO transaction; the indirect roll-out transaction includes a second intermediate transaction whose input references a user account address or a contract account address of a balance model, and a second response piece transaction whose output is a user one-time address of the UTXO transaction. Similarly, in the roll-out process, the actual transfer is completed only if the receipt transaction is completed in the indirect transaction scenario. When multiple intermediate transactions are referenced, the response piece transaction may also be referred to as a confounding transaction. The user's one-time address of the response piece transaction output may be output as an unspent, which may be referenced to a cost.

In an exemplary embodiment, a second intermediate transaction in the indirect roll-out transaction binds a third commitment of one or more recipients, an output of the second intermediate transaction is an intermediate transaction address, an input of the second receipt transaction is one or more second intermediate transactions, an output of the second receipt transaction binds a fourth commitment, the fourth commitment is a new commitment obtained after the third commitment is subjected to an operation, and an address generated by the fourth commitment subjected to a second operation is a user primary address of the UTXO transaction.

The third commitment may be the same as or different from the first commitment. Accordingly, the fourth commitment may be the same as or different from the second commitment.

In the embodiment of the present disclosure, the third commitment is the same as the first commitment. The third commitment is that the public key of the user is multiplied by a first coefficient, the first generator is multiplied by a second coefficient, and the second generator is multiplied by a third coefficient, wherein the first coefficient can be 1, and the second coefficient can be 0. And obtaining a fourth commitment by operating the third commitment, wherein the fourth commitment is the public key of the user multiplied by a fourth coefficient, and the fourth coefficient is added with the first generator multiplied by a fifth coefficient, wherein the fourth coefficient can be equal to the first coefficient, and the fifth coefficient can be equal to the second coefficient. For example, the user public key P, the first generator G, the second generator H, the third commitment of the second intermediate transaction binding a receiver is v₁*P+v₂*G+v₃H, the fourth commitment of the second receipt transaction output binding is C ═ v₄*P+v₅G. For example, the fourth commitment can be calculated as follows: the third commitment is multiplied by a scalar (which may be 1, i.e. constant), and then the first generator multiplied by a sixth coefficient and the second generator multiplied by a seventh coefficient are added to obtain a fourth commitment. The first address of the user, which is output by the fourth commitment through the second operation, is Hash (C), the corresponding public key is the commitment C, and the private key is v₄*d+v₅Where d is the user private key, i.e., P ═ d × G. By different coefficients v₄And v₅Different public and private keys, namely the primary key of the user, can be obtained, so that the primary address of the user is output. Before the user's primary address can have address type identificationAffixes and/or system identification prefixes.

An embodiment of the present disclosure further provides a method for processing transaction data in a chain structure, where the chain structure is a license chain, and the license chain includes transaction data in a UTXO model and transaction data in a balance model, and the method for processing transaction data is shown in fig. 1, and includes:

step 11, implementing the circulation of the token of the UTXO model and the balance model of the license chain by using the chain structure processing method of any one of the embodiments, and obtaining data of a transfer-in transaction and/or data of a transfer-out transaction;

if the transfer-in transaction from the UTXO model to the balance model is executed, the obtained data is data of the transfer-in transaction, and the data of the transfer-in transaction includes input, output, amount, and the like, and optionally may further include a signature, for example: inputting a user primary address referenced as a UTXO model or an address of a first intermediate transaction, outputting a user account address or a contract account address as a balance model, and outputting a commitment of a transfer amount; whether or not to switch in the transaction is judged by an input address (non-balance model) and an output address (balance model). If the roll-out transaction of the balance model to the UTXO model is executed, the obtained data is the roll-out transaction data, and the roll-out transaction data includes input, output, and the like, for example, including: inputting a user account address or a contract account address which is referred as a balance model, outputting a user primary address of the UTXO model or an intermediate transaction address of a second intermediate transaction, referring to the second intermediate transaction through the second receipt transaction, and outputting the user primary address of the UTXO model; whether or not a transaction is a roll-out transaction is determined by an input address (balance model) and an output address (non-balance model).

Step 12, merging a plurality of pieces of off-system verification data of permit chains belonging to the same alliance chain into account book data of the alliance chain, wherein the off-system verification data of the permit chains comprises one or more of the following: the data of the transfer-in transaction, the data of the transfer-out transaction and the transaction data of the UTXO model.

In an exemplary embodiment, the merging the off-system verification data of a plurality of admission chains belonging to the same federation chain into ledger data of the federation chain in step 12 includes: and generating first-layer ledger data of the alliance chain after the block header data of the plurality of permission chains are identified together, wherein the off-system verification data corresponding to the block header data of the permission chains is used as second-layer ledger data of the alliance chain, and the essence is that TXO (Transaction Output) Transaction data chains of the plurality of permission chains are merged into TXO Transaction data chains of the alliance chain.

The federation chain in the embodiment of the present disclosure refers to a federation of member chains, and unlike a federation of enterprises, the ledger data of the federation chain in the embodiment has a two-layer structure, where the first layer is block header data of a plurality of member chains (for example, permission chains) and is a result of merging the plurality of member chains into the federation chain, and the second layer is off-system verification data corresponding to each member chain. And the alliance chain of the organization only has one layer of structure and does not contain the block head data of other chains as a single layer of data, such as a block data structure of a bitcoin or an Ether house. It can be seen that the differences between the federation of enterprises and the federation of chains can be reflected in the block data structure of the chains being different. The grant chain in the embodiments of the present disclosure is a block chain having a one-layer structure.

In an embodiment of the disclosure, the address used when the license chain participates in the transaction contains a unique identification of the chain, so that the transaction data chains of different license chains are logically isolated.

By adopting the transaction data processing method, a plurality of permission chains can be merged into a alliance chain.

In an exemplary embodiment, the method may further include: verifying, by the verifier, the out-of-system verification data of the license chain block, which may specifically include any one of the following verifications:

verification one: verifying whether input reference of the transaction data of the UTXO model and/or the data converted into the transaction is non-cost output on a alliance chain;

i.e. to verify whether the input reference to the transaction data of the UTXO model is an unspent output on the federation chain and/or whether the input reference to the data carried into the transaction is an unspent output on the federation chain.

And (5) verifying: verifying whether the input reference to the transaction data of the non-cross-chain UTXO model of the license chain and/or the data carried into the transaction is a forward non-spent output of the license chain.

I.e. to verify whether the uneconomic output of the transaction data of the UTXO model of the license chain referencing a non-cross-chain transaction address is the forward uneconomic output of the license chain and/or whether the uneconomic output of the data carried into the transaction referencing a non-cross-chain transaction address is the forward uneconomic output of the license chain.

The verification of the off-system verification data of the license chain block by the verifier in the present embodiment is not limited to be performed at any time, i.e., may be performed at any time period. And the correctness of the input reference is ensured through verification, so that transaction errors are avoided.

In an exemplary embodiment, before the merging the off-system verification data of a plurality of admission chains belonging to the same federation chain into ledger data of the federation chain, as shown in fig. 2, the method may further include the following steps 13 and 14:

step 13, the verifier of the alliance chain verifies the system outside verification data of the license chain block to be uplinked, including any one of the following verifications:

and (3) verification: verifying whether input reference of the transaction data of the UTXO model and/or the data converted into the transaction is non-cost output on a alliance chain;

And (4) verifying: verifying whether an input reference to transaction data of a non-cross-chain UTXO model of the license chain and/or data carried into a transaction is a forward non-spending output of the license chain;

i.e. to verify whether the uneconomic output of the transaction data of the UTXO model of the license chain referencing a non-cross-chain transaction address is the forward uneconomic output of the license chain and/or whether the uneconomic output of the data carried into the transaction referencing a non-cross-chain transaction address is the forward uneconomic output of the license chain. And by permitting the chain block header data to sequentially link the federation chain ensures that transaction data inputs after the uplink federation chain refer to non-costed outputs for non-cross-chain transaction addresses as well as costed outputs forward on the federation chain.

In this embodiment, the verification performed by the verifier of the federation chain is performed before merging the ledger data of the federation chain, and after the verification passes, the extra-system verification data of a plurality of admission chains belonging to the same federation chain are merged into the ledger data of the federation chain, specifically, the block header data of the admission chains are merged. In this embodiment, the validation performed by the verifier of the federation chain is for the block of the license chain to be linked.

Step 14, after the verification is passed, adding a block header hash value for representing a limitation alliance chain block height in the permission chain block header data to be linked, wherein the limitation alliance chain block height is at least the maximum block height corresponding to the non-spending output on the alliance chain referenced by the cross-permission chain transaction in the permission chain block; in an exemplary embodiment, the restricted alliance chain block height may be greater than the maximum block height, for example: the last allowed block includes the block header hash value representing the restricted alliance block height and the restricted alliance block height is greater than the maximum block height (whichever is greater);

limiting blocks of the uplink federation chain by the limited federation chain block height only follows the limited federation chain block height, ensuring that cross-chain transactions all refer to unspent outputs in the forward direction on the federation chain. And the added hash value of the block head of the alliance chain with the corresponding height, so that even if the alliance chain is forked before the height, the block head of the forward direction without the same hash value can be judged, and the block heads of the permission chain can not identify the uplink alliance chain; if it diverges after this height, the forward chunk headers with the same hash value can be determined so the allowed chain chunk headers can identify the uplink federation chain.

In an exemplary embodiment, the adding, in the allowed chain block header data to be linked, a block header hash value for indicating that the federate chain block height is limited may be performed in the following manner:

when the permission chain block to be linked up does not contain the cross-permission chain transaction, recursion is carried out on the permission chain to the last permission chain block containing the cross-permission chain transaction, a permission chain block head pointing to the permission chain block is found on a alliance chain, and a block head hash value used for representing the height limitation of the alliance chain block in the permission chain block head is added into the permission chain block head data of the current chain to be linked up (an explicit height limitation mode); or when no cross-grant chain transaction is included in the grant chain block to be linked and the forward recursion is made on the grant chain to the grant chain block including the cross-grant chain transaction (i.e. as long as there is a grant chain block including the cross-grant chain transaction), a second preset value (e.g. FF … FF) is added to the grant chain block header data of the current to-be-linked (implicit height-limited manner).

In an exemplary embodiment, when the forward recursion on the permission chain to the starting block still does not contain the cross-permission chain transaction, the block header hash value used for indicating the limitation of the alliance chain block height in the permission chain block header data to be linked is set to the first preset value (for example, zero).

Step 15, the verifier of the federation chain carries out endorsement signature on the permission chain block head data added with the block head hash value for representing the height of the block of the constraint federation chain;

in the process of combining the alliance chain account book data, an bookkeeper of the alliance chain identifies the head data of the allowed chain block signed by the multiple alliance chain verifiers to generate the first layer of account book data of the alliance chain, and the out-of-system verification data corresponding to the head of the allowed chain block is the second layer of account book data of the alliance chain. The allowed link block header data of the uplink alliance chain includes a block header hash value indicating the restricted alliance chain block height. Because the maximum block height for the non-spending output on the federation chain referenced by the cross-license chain transaction in the license chain block is constant, the block header hash values added by different verifiers representing the restricted federation chain block height are the same.

The bookkeeper of the alliance chain needs to ensure that the block head hash value corresponding to the allowed chain block head of the uplink alliance chain and representing the block head height limitation of the alliance chain is equal to a forward alliance chain block head hash value, and if the hash value is a first preset value or a second preset value, the block height of the uplink alliance chain is not limited. If the block header of the allowed chain contains the first preset value, the block header can be used as first block header data of the uplink alliance chain, and the first block header data of the uplink alliance chain of the allowed chain needs to contain the first preset value; if the allowed chain block header contains the second preset value, the block before the allowed chain contains the cross-allowed chain transaction and cannot be used as the first block header data of the uplink alliance chain, and the block height of the uplink alliance chain is implicitly limited in a mode of sequentially uplink alliance chains, and the allowed chain block header containing the second preset value is bound to be the uplink alliance chain after the block height of the uplink alliance chain is explicitly limited.

In an exemplary embodiment the license chain block header data includes a unique identification of the license chain. By including the unique identification of the chain in the chunk header, chunk header data isolation for different allowed chains can be achieved.

In an exemplary embodiment, the off-system verification data of the license chain may further include metadata including, for any one asset type token, a cumulative transfer-in amount commitment and a cumulative transfer-out amount commitment of the UTXO model of the asset type token to a balance model, and range attestation data that a difference between the cumulative transfer-in amount commitment and the cumulative transfer-out amount commitment is greater than or equal to zero.

When the licensing chain supports multiple asset type tokens, each asset type token is calculated separately, and multiple lists can be set to record the cumulative transfer-in amount commitment, the cumulative transfer-out amount commitment and the range certification data with the difference between the two greater than or equal to zero of each asset type token.

In an exemplary embodiment, when there is a cross-license chain transaction or an issue transaction or a reclaim transaction, the metadata may further include, for any one asset type token: a first result of a cumulative input amount commitment plus a cumulative issuance amount commitment for the asset type token across a license chain transaction, and a second result of a cumulative output amount commitment plus a cumulative recovery amount commitment across a license chain transaction, and range attestation data having a difference between the first result and the second result greater than or equal to zero. Wherein the difference between the first result and the second result is an amount commitment of a current total amount of the asset type tokens of the license chain.

In other embodiments, when there is a cross-license chain transaction, the metadata may also include, for any one asset type token: a quantity commitment of a current total quantity of the asset type tokens of the permit chain, and range attestation data for the quantity commitment being greater than or equal to zero. Wherein the amount commitment for the current total amount of the asset type token of the license chain is a difference between a sum of a cumulative input amount commitment and a cumulative issuance amount commitment for a cross-license chain transaction of the asset type token and a sum of a cumulative output amount commitment and a cumulative recovery amount commitment for the cross-license chain transaction.

In an exemplary embodiment, the range attestation being greater than or equal to zero, i.e., the range attestation being a non-negative number, is equivalent to attestation in a range, e.g., [0,2^64), since a negative number would be greater than this range.

In an exemplary embodiment, the method further comprises: the method comprises the steps that a first Mercker tree is generated by a system-outside verification data set of the permission chain, a second Mercker tree is generated by other data sets of the permission chain except the system-outside verification data, and a root hash value of the first Mercker tree and a root hash value of the second Mercker tree are recorded in block header data of the permission chain.

In an exemplary embodiment, the transaction data is obtained by a transaction process, the method may further include the transaction process of:

generating cross-chain output transaction data by the first permit chain, and outputting a unique cross-chain transaction address;

generating, by the second permit chain, cross-chain input transaction data, the input referencing the cross-chain transaction address;

wherein: the cross-chain transaction address comprises an address type which indicates that the current address is the cross-chain transaction address, a unique identifier of the first permission chain, a unique identifier of the second permission chain and a unique number of the cross-chain of the first permission chain.

The transaction is a cross-chain transaction, the input of cross-chain output transaction data generated by a first license chain is the non-expense transaction output of the first license chain, the output is a unique cross-chain transaction address, cross-chain input transaction data generated by a second license chain refers to the unique cross-chain transaction address, and the output is a primary address of a user of the second license chain. The cross-chain output transaction and the cross-chain input transaction are transaction data of the UTXO model and are connected through a unique cross-chain transaction address.

In an exemplary embodiment, the first chain of permissions generates cross-chain output transaction data, including:

the first license chain generates a first amount v represented by a first peterson commitment of a first algorithm, a second peterson commitment of a second algorithm, and a second generator coefficient promised by the first and second peterson commitments, across chain outputs₁Equal proof data, i.e. a first amount v expressed by a second coefficient of generators for proving commitments from the first peterson commitment₁And a first amount v represented by a second generator coefficient promised by a second Pedson commitment₁Equal proof data.

A second chain of permissions generates a cross-chain input transaction, the second pettson commitment using the second algorithm.

The attestation data includes: a third Pedelson commitment to the first algorithm, a fourth Pedelson commitment to the second algorithm, and a first scalar, a second scalar, and a third scalar, wherein a second amount, v, represented by a second generator coefficient promised by the third Pedelson commitment and the fourth Pedelson commitment is randomly generated by the first license chain₂Equal;

the first scalar is a first hash value multiplied by the first amount, plus a second hash value multiplied by the second amount;

the second scalar is the first hash value multiplied by a first generator coefficient of the first peadson commitment plus the second hash value multiplied by a first generator coefficient of the third peadson commitment;

the third scalar is the first hash value multiplied by a first generator coefficient of the second peadson commitment plus the second hash value multiplied by a first generator coefficient of the fourth peadson commitment;

first hash value h₁The first, second, third and fourth Pedson commitments and the parameters of the first and second algorithms are derived from a first hash function, a second hash value h₂Deriving from the first, second, third, and fourth Pedelson commitments and the parameters of the first and second algorithms by a second hash function. h is₁And h₂A certain length is satisfied, which can be extended if the length is not sufficient, for example, taking the square of the hash value.

The petersen commitment is denoted C ═ b × G + v × H, where G is the first generator, H is the second generator, b is the blind factor, and v is the amount committed.

The commitment output is: first Pedelson promise C₁＝b₁*G₁+v₁*H₁And a second Pedelson commitment C₂＝b₂*G₂+v₁*H₂. Wherein the first Pedelson commitment uses a first algorithm, namely using a generator G₁And H₁The second Pedelson promise to use a second algorithm, i.e. using generator G₂And H₂。

To prove that the first amounts in the different algorithms are equal, i.e. v1 in C1 is equal to v1 in C2, the following proof data is required: randomly generated commitments and associated scalars. Specifically, the method comprises the following steps:

the randomly generated commitments include: third Pedelson promise C₃＝b₃*G₁+v₂*H₁And the fourth Pedelson promise C₄＝b₄*G₂+v₂*H₂. Wherein the third Pedelson promise uses the first algorithm, i.e., using the generator G₁And H₁Fourth peterson commitmentUsing a second algorithm, i.e. using generator G₂And H₂In the exemplary embodiment, the second amount v₂May be greater than the first amount v₁E.g., greater than 2 < lambda > 64.

Obtain a first hash value h₁＝Hash₁(C₁||C₂||C₃||C₄||G₁||H₁||G₂||H₂) And a second hash value h₂＝Hash₂(C₁||C₂||C₃||C₄||G₁||H₁||G₂||H₂)

Computing the scalar for the proof includes: first scalar m₁＝h₁*v₁+h₂*v₂

Second scalar m₂＝h₁*b₁+h₂*b₃

Third scalar m₃＝h₁*b₂+h₂*b₄

By proving m₂*G₁+m₁*H₁Is equal to h₁*C₁+h₂*C₃And is

m₃*G₂+m₁*H₂Is equal to h₁*C₂+h₂*C₄To demonstrate that v1 in C1 is equal to v1 in C2.

Since the discrete logarithm of the first generator G and the second generator H in the first algorithm or the second algorithm is not known, only the coefficients of the second generator H with which the amount is related are considered. Let coefficients of the second generator H of C1, C2, C3, C4 be a1, a2, a3, a4, respectively, and get m1 ═ H1 ═ a1+ H2 × a3 and m1 ═ H1 × 2+ H2 × 4 according to the proving equations, since the first hash value H1 and the second hash value H2 are unpredictable, only a1 ═ a2 and a3 ═ a4 can satisfy the equations, and thus v1 in C1 is equal to v1 in C2.

Wherein G is₁And H₁Is a generator of the first algorithm, G₂And H₂Is the generator of the second algorithm.

In an exemplary embodiment, multiple signature subkeys are used in a transaction, with a combinatorial relationship of multiple signature subkeys implied in the multiple signature subkeys.

The key can generate a sub-key according to the identification, and a plurality of keys can form a multiple signature key. Different combination relations of the multiple signing keys can be encoded in advance, different encoding results are used as key identifications or part of the key identifications of different multiple signing sub-keys, a plurality of sub-keys corresponding to a plurality of keys are generated according to the key identifications, and the multiple sub-keys form the multiple signing sub-keys. The multiple signature subkeys hide the combinatorial relationship at this time. The multiple signature sub-keys are used during transaction, other traders do not know the combination relation, and the combination relation of the keys can be prevented from being tampered.

The embodiment of the present disclosure further provides a chain structure transaction processing method, which is used for a chain-crossing transaction of a first license chain and a second license chain, where the first license chain uses a first algorithm, and the second license chain uses a second algorithm, and the chain structure transaction processing method includes:

The proof data indicating that the first amount represented by the second generator coefficient promised by the first and second pearson commitments is equal to each other is: proof data proving that a first amount represented by a second producer coefficient promised by the first peadson commitment is equal to a first amount represented by a second producer coefficient promised by the second peadson commitment.

The cross-chain transaction between the first license chain and the second license chain may employ the cross-chain transaction process described herein above. Or other cross-chain transaction methods may be employed.

By adopting the method of the embodiment, the proof with equal promised amount between different algorithms can be realized by providing the proof data. It is possible to implement cross-chain transactions between chains of licenses using different algorithms.

The details of the certification data are described in the foregoing, and are not repeated herein.

The embodiment of the present disclosure further provides a data verification method using a chain structure, where the chain structure is a license chain, the license chain includes transaction data of a UTXO model and transaction data of a balance model, and the data verification method is as shown in fig. 3, and includes the following steps:

step 21, implementing the circulation of the token of the UTXO model and the balance model of the license chain by using the chain structure processing method in any of the foregoing embodiments, and obtaining data of a transfer-in transaction and/or data of a transfer-out transaction;

and step 22, verifying the data transferred into the transaction and/or the transaction data of the UTXO model by the verifier outside the license chain.

The verifier outside the license chain verifies the data transferred into the transaction and/or the transaction data of the UTXO model, which may be the verification one or the verification two, and is not described herein again.

By adopting the verification method disclosed by the embodiment of the disclosure, the correct circulation of the token in the alliance chain is ensured.

In an exemplary embodiment, the method may further include:

a verifier outside the permit chain verifies metadata, for any asset type token, including a cumulative transfer-in amount commitment and a cumulative transfer-out amount commitment of the UTXO model of the asset type token to a balance model, and range certification data that a difference between the cumulative transfer-in amount commitment and the cumulative transfer-out amount commitment is greater than or equal to zero.

The following describes embodiments of the present disclosure.

The permission chain described herein may support both the UTXO model and the balance model, the transaction data of the UTXO model may be merged into the federation chain ledger, and the transaction data of the balance model does not participate in merging of the federation chains. The embodiment of the disclosure provides a token transfer mode, or a transfer mode, of a UTXO model and a balance model, and can transfer transaction data of token between the UTXO model and the balance model.

The license chain described in the embodiments of the present disclosure includes a UTXO model function area, and is capable of generating transaction data of a UTXO model. Because the transaction data of the UTXO model can form a DAG (directed acyclic graph) structure, the transaction data of the UTXO model of multiple independent license chains can be merged into ledger data of a federation chain by the transaction data of the multiple license chains and is a logically isolated DAG structure. The permit chains in the alliance can jointly circulate the tokens issued by the alliance and can effectively limit the circulation boundary of the tokens of the alliance. Because the cross-permit chain export transaction must contain a valid cross-chain transaction address, it can only be exported to a permit chain within the federation. And the input reference of the cross-permit chain input transaction must be the non-paid output on the alliance chain, namely the referenced cross-chain output transaction is linked to the alliance chain, so the cross-permit chain transaction is converted into the transaction in the alliance chain after combination.

After a cross-chain transaction mode such as a notary or a relay chain is output to a certain permit chain in a cross-chain mode, the flow transfer in the permit chain can not be limited, and the permit chain can be transferred in other modes. Different from a cross-link transaction mode such as a notary or a relay link, the mode of merging the license chains into the federation chain (the federation of chains) in the embodiment of the disclosure limits that tokens can only be transferred between the license chains in the federation and cannot be transferred out of other chains outside the federation. And the transaction data of the permit chain flow token is converted into the transaction data of the union chain flow token after being combined, namely the process of token flow has the effective proof of the union chain, so that whether the token of a certain permit chain is the valid token issued by the union can be verified through the SPV (simple Payment Verification) proof of the union chain.

The combined alliance chain comprises two layers of data structures, wherein the first layer is block head data of the permit chain, the second layer is actual transaction book data of the alliance chain, and the actual transaction book data are transaction data of a UTXO model in the permit chain book data corresponding to the block head of the permit chain of the first layer. The data volume of the first-layer account book actually generated by the alliance chain bookkeeper is small, the first-layer account book can contain the data of the admission chain account books of a plurality of large-scale account books, and meanwhile, privacy cannot be leaked from the block header. Therefore, by layering the ledger and multi-level consensus (at least two levels of the permit chain and the alliance chain), the problems of accounting and security privacy of large-scale ledger data of the alliance chain are solved.

The license chain can also comprise a balance model functional area, generates transaction data of a balance model, and can support user-defined intelligent contracts and state storage. The verifier of the alliance chain can not read the transaction data of the license chain balance model, and the data of the license chain balance model can not participate in the combination of the alliance chain. Therefore, the data in the block of the permission chain is divided into two parts, the first part is the data which is verified by the verifier of the federation chain and participates in the merging of the federation chain, and the embodiment of the disclosure is called as the verification data outside the system; the second part is the rest data except the verification data outside the system, and mainly comprises the data of the balance model. The permission chain block header data comprises two Merck tree root hash values respectively generated by the two parts of data in the block. Therefore, the ledger data verification of the permit chain is divided into two modes of system external verification (namely, a verifier of the alliance chain, which only reads and verifies the system external verification data) and internal verification. The internal verification is the verification in the permit chain, and the ledger data of the whole permit chain is verified. For example, the internal verification verifies whether the primary address of the user output by the UTXO model is valid, and the validity of the output address needs to be verified because the permission chain does not allow the output to the primary address of the non-system user; the system external verification is more similar to a public chain verification mode, can be output to any address, does not verify whether the output primary address is a valid user address, only verifies whether the output primary address is valid unlocking cost and has no double flowers, the input amount of the transaction is equal to the output amount of the transaction, namely, the correct circulation of the token issued by the alliance is ensured, and the circulation verification does not contain the user, so the system external verification is private. Internal verification is also to ensure the correct flow of tokens, but the flow verification will involve flow to the correct user address.

Therefore, the permission chain contains the user relationship, and whether the circulated address is a valid one-time address of the user or not is limited; the merged union chain does not contain users, only restricts the token from flowing between the permit chains in the union, and does not allow the token to flow to other chains which are not in the union, so that the union chain is different from cross-chain transaction modes such as notary or relay chain, and the flowing boundary of the token in the union can be effectively restricted. For example, a non-federation token of a license chain may be exported across chains onto other chains of the non-federation without any restrictions, so the license chain may participate in multiple different federations simultaneously, circulating tokens of different asset types issued by different federations.

In an exemplary embodiment, the federation chain also allows for a pass-in token transaction of the license chain from the UTXO model to the balance model, and a pass-out token transaction from the balance model to the UTXO model. After the actual coalition token is transferred into the balance model, the boundary of the coalition chain is exceeded, and because the coalition chain obtained by combining the permission chains does not contain the balance model, the token transferred into the balance model no longer has the member certification of the coalition chain, and only the token transferred out of the UTXO model again can have the member certification of the coalition chain. The in-token and out-token transactions are therefore constrained within the system of the license chain, and the verifier of the federation chain does not read the balance model of the transaction, so the license chain gives the result of the cumulative in-roll amount commitment minus the cumulative out-roll amount commitment, and range attestation data for the result to be greater than or equal to zero. The system external verification only verifies whether the commitment result is correct and the result is proved to be greater than or equal to zero, namely the transfer-out token transaction is considered to be effective; and the internal verification verifies whether the balance corresponding to the input address of the transferred token transaction is more than or equal to the transferred token amount.

The transaction of the UTXO model may contain one or more inputs and one or more outputs, each input referencing one unspent transaction output in the forward direction and becoming spent, and creating one or more new unspent transaction outputs. The reference connection can be divided into an explicit connection and an implicit connection. The unlock script needs to be associated with the corresponding lock script, and other people can know that the referenced unspent output is in an explicit connection mode, such as a mode of 'txid + index' or a one-time address, wherein txid represents a transaction ID referencing unspent output, and index represents a serial number. The spending voucher set records fingerprints of all the spent outputs and therefore cannot be spent repeatedly, and others do not know the referenced unspent outputs, in an implicit connection mode, such as zero knowledge proof or ring secret transactions.

This can be seen as spending one or more outputs (spent) and creating one or more new outputs (unspent) and looping back continuously, all of the spent output STXO and unspent output UTXO can form a DAG structure (directed acyclic graph) regardless of whether the connection between them is explicit or implicit. And the DAG structure reflects the process of token flow, so called the DAG structured transaction data chain (or TXO transaction data chain).

The explicit connection between lock and unlock indicates a certain connection on the transaction chain, and whether the reference connection is in a txid + index or one-time address mode, the method can be used as long as the method can effectively reference a certain output and can judge whether the cost is not spent. Implicit connections using the expense voucher do not indicate which connection is on the transaction chain, but cannot be duplicated by the expense voucher, indicating some of them, and have not been previously expended. So the implicit join is a transaction chain of DAG structure even if not indicated, just hiding the chain's join (sender knows the referenced unspent output and others do not).

Therefore, the transaction of the UTXO model in any mode can be abstracted into a transaction chain of a DAG structure, and the DAG structure is also a combinable theoretical basis. Because the DAG structure can be split into multiple sub-DAG structures, multiple sub-DAG structures can also be merged into one DAG structure. Because the transactions of the UTXO model of the federation chain can form a transaction chain of a DAG structure (using an explicit one-time address connection), and then can be split into a plurality of sub-DAGs, each sub-DAG being formed by transactions of the UTXO model of one private chain, the transactions of the UTXO models of the plurality of private chains can be merged into an account book of the federation chain. The merged federation chain therefore contains only the data of the UTXO model and no balance model.

The DAG structure of a federation chain uses an explicit one-time address connection approach because each address may contain a unique identification of the chain (i.e., a system ID) as a prefix and the address is unique within the private chain, so transaction data can be logically isolated and have globally unique connection addresses, so that transactions merged into a federation chain do not collide. If the private chain transaction data is merged directly, only one explicit address connection can be used. However, the transaction data of each private chain is independently verified and uplink federation chain, and the first layer of the federation chain only has the block header data of the private chain, so that the internal connection of the private chain sub-DAG structure can be replaced by other modes, including a txid + index or a privacy connection mode, but the mode of keeping an address across the private chain transaction is also needed. Therefore, the transaction data of the UTXO model of the private chain of a plurality of different technical modes can be combined into the ledger of the alliance chain.

The transaction of the UTXO model forms a transaction chain of a DAG structure, which is a homogeneous token defaulted to one asset type, but the system may have homogeneous tokens of multiple asset types, or may have heterogeneous tokens, and tokens of different asset types may be distinguished by identification. The non-homogeneous token forms a common chain structure because it costs an existing output and creates a new output. The homogeneous token of the same asset type is a structure with multiple inputs and outputs, so a complex chain structure is formed. And homogeneous tokens of several asset types exist in the system, and a corresponding transaction chain of several DAG structures is formed.

And only the token issued by the alliance is verified in the alliance, other tokens in the private chain are not processed and verified, so the tokens are merged into an alliance chain account book, which is equivalent to only merging the flow of the token issued by the alliance, so even if the flow of the token issued by different alliances in a certain private chain is converted into the token issued by different alliances, the alliance only verifies the flow of the token of the local alliance, which is equivalent to different DAG structures, so that two or more tokens can be circulated in the system, and conflict-free participation in merging a plurality of alliance chains can be realized. The private chain can also choose to join or leave the federation chain after satisfying a condition, for example, if there is no unspent output of the stream federation token in the system, the private chain can leave the federation chain.

Different private chains use different cryptographic algorithms, which may also be combined. Such as private chainsA uses the State secret SM2 elliptic curve and the private chain B uses the secp256k1 elliptic curve. Elliptic curves and algorithms that identify the outgoing user's one-time public key (or commitment address) when transacting across the private chain. It then needs to be proven that the amount commitment output by a is equal to the amount commitment input by B at different elliptic curves. Amount commitments C, e.g. A output₁And B input amount commitment C₂:

The commitment output is: first Pedelson promise C₁＝b₁*G₁+v₁*H₁And a second Pedelson commitment C₂＝b₂*G₂+v₁*H₂。

The randomly generated commitments include: third Pedelson promise C₃＝b₃*G₁+v₂*H₁And the fourth Pedelson promise C₄＝b₄*G₂+v₂*H₂。

So that a third hash value h is obtained₃＝Hash₁(C₁||C₂||C₃||C₄||G₁||H₁||G₂||H₂) And a fourth hash value h₄＝Hash₂(C₁||C₂||C₃||C₄||G₁||H₁||G₂||H₂)

Wherein the Hash₁And Hash₂May be different hash functions, e.g. SHA256 and SM3, but h₁And h₂The length of (A) is greater than the length of the elliptic curve step, so the value can be taken as the square of the hash value, i.e. the length of the elliptic curve step

And is

If SHA512 is used, then the hash value, h, may be used₁＝h₃And h is₂＝h₄。

Second scalar m₂＝h₁*b₁+h₂*b₃

Third scalar m₃＝h₁*b₂+h₂*b₄

By proving m₂*G₁+m₁*H₁Whether or not it is equal to h₁*C₁+h₂*C₃And is

m₃*G₂+m₁*H₂Whether or not it is equal to h₁*C₂+h₂*C₄To demonstrate that v1 in C1 is equal to v1 in C2.

G above₁And H₁Is the generator of the SM2 elliptic curve, G₂And H₂Is the generator of the secp256k1 elliptic curve. So C₁And C₃Is a point on the SM2 elliptic curve, C₂And C₄Is a point on the secp256k1 elliptic curve. v. of₁Is the amount promised by the transfer, v₂Is a randomly generated amount, and v₂Can be greater than 2⁶⁴. H above₁And h₂Is 64 bytes, scalar m₁Participating in the operation of the first and second algorithms simultaneously, which may be denoted as m₁％(n₁*n₂) Wherein n is₁Is the order of the first algorithm, n₂Is an order of the second algorithm, so scalar m₁Using 64 bytes for storage. Scalar m₂And m₃Operating only in respective algorithms, which may be denoted as m₂％n₁And m₃％n₂So m is₂And m₃With 32 bytes of storage. So the cross-permit chain output transaction data from A to B contains amount commitments C of different elliptic curves₁And C₂And to give proof of equal amounts.

The amount of transactions of the UTXO model may be kept secret using homomorphic cryptography, e.g., using the pearsen Commitment (Pedersen Commitment), denoted Cv-b-G + v-H, where v is the amount committed, b is a blind factor, and G and H are the first generator and the second generator on the elliptic curve, respectively. The commitment Cv has additive homomorphic properties, so Cv1+ Cv2 ═ b1+ b2 × G + (v1+ v2) × H can be used. The addition may be a subtraction, that is, Cv1-Cv 2 (b 1-b 2) G + (v 1-v 2) H. And may incorporate scope attestation, such as using the Bulletproofs protocol, to certify that the amount v promised by Cv is within a certain range, such as v ∈ [0,2^ 64). Ranges stated herein as greater than or equal to zero, i.e., non-negative, are equivalent to ranges, e.g., [0,2^64 ].

In order to meet the requirement that the private chain system can support an intelligent contract with state storage, a balance model functional area is added in the private chain system, namely the private chain system can simultaneously have a UTXO model functional area and a balance model functional area.

The balance model comprises a user account and a contract account, which are a user account address and a contract account address respectively. The account status has a Balance (Balance) value that can be added and subtracted, and thus can be represented using the Pedersen commitment. The transaction amount of the UTXO model, or the Balance value of the Balance model, may be a commitment Cv to secure the commitment value v. The balance model transaction may also contain a sequence number nonce to prevent replay of balance model transaction data.

The transaction address of the UTXO model (also referred to as the user primary address) may be "address type + system ID (or chain ID) + transaction mode (optionally) + Hash value of the user primary public key", where the user primary public key is generated from the user's signature public key and a generation private key, e.g., by the user's signature public key Pb and the generation private key s, the generation primary public key Qb ═ Hash (c × s × G) × G + Pb, where c is referred to as a generation coefficient, and the corresponding private key is (Hash (c × s G) + d)% n, where d is the user's signature private key Pb × d × G, and n is an additive cluster with G as a base point. The primary public key may be generated by a method of Qb ═ Hash (c, s) × G) × Pb, and the corresponding private key is (Hash (c, s) × G) × d)% n. And then generating a corresponding hash value by the user once public key, for example: the hash value Lb of the public key is HL (ID, Qb), where Qb is the primary public key of the user, which may be referred to as the primary public key corresponding to the primary address of the user, and HL is the address hash function. Take the user address 12317466924e4f854afd8e494fa657a4 as an example, where 1 is the user address type, 23 is the system ID (or chain ID), 1 represents the committed address transaction mode, and the rest is the hash value of the user's one-time public key. The user primary address needs to correspond to a certain user primary public key, the unlocking script of the reference address needs to give a primary public key or committed address operation (namely, the committed address is associated with the user primary public key) to obtain the primary address, and the unlocking is completed by using a private key signature corresponding to the primary public key. The address length is not limited and the length of different types of addresses may also be different.

The user account address of the balance model may be "address type + public key address", which is an address generated by a signature public key operation of the user, for example: the user account address La ═ 8+ HL (ID, Pa), where 8 is the user account address type, Pa is the user's public signature key, and HL is the address hash function. The transaction data of the balance model may comprise: the sender's account address L1, the recipient's account address L2, the transfer amount commitment Cv3, the sender's serial number count nonce, and the sender's signature private key signature on the transaction data. According to the Balance value Cv1 corresponding to the sender account address L1 and the Balance value Cv2 corresponding to the receiver account address L2, after the transfer is completed, the Balance value of L1 is Cv1-Cv 3, the Balance value of L2 is Cv2+ Cv3, and the transaction data can further include range certificates of Cv1-Cv 3> -0 and Cv3 ∈ [0,2^ 64). Transactions of the balance model may also create and invoke contracts, although the scope of this document is not concerned with.

The contract account address of the balance model may be "address type + hash value", where the hash value may be the result of a hash of the user account address La and nonce at which the contract was created. For example: the contract account address Lc is 9+ HL (ID, La | nonce), where 9 represents a contract account address type and nonce is a transaction count when the user creates a contract. The corresponding contract account address can be calculated from the user account address and the nonce value. Contract accounts also have Balance values, but can only be controlled by contracts.

The license chain system can include a direct transaction mode and an indirect transaction mode in order to meet the requirements of management and flexibility. The direct transaction mode is that the transaction generated by the sender directly outputs the primary public key or address of the receiver; the indirect transaction mode is that the transaction generated by the sender does not directly output the public key or address of the receiver, but outputs an intermediate transaction address, and then an endorsement node of the permit chain generates a receipt obfuscated transaction data to reference the intermediate transaction address and outputs a primary public key or address of the receiver. Since the indirect transaction method is an output generated by the endorsement node, a method of binding a public key to an intermediate transaction address output by the sender is used. Indirect transactions differ from most blockchain transactions in that the sender cannot directly output the primary address or the address of the receiver of the cross-chain transaction (not the user of the local license chain), and thus the cross-license chain transaction requires the use of indirect transactions.

Transaction data of the cross-permit chain transaction uses a cross-chain transaction address mode, specifically, a user of a first permit chain generates an intermediate transaction, outputs an intermediate transaction address, an endorsement node of the first permit chain generates cross-chain output transaction data, inputs and refers to the intermediate transaction address, and outputs a unique cross-chain transaction address; generating, by the endorsement node of the second permission chain, cross-chain input transaction data, the input referencing the cross-chain transaction address, and outputting a primary address of the user. The cross-chain transaction address comprises an address type of the cross-chain transaction address, a unique identification of the first license chain, a unique identification of the second license chain and a unique number of the cross-chain of the first license chain. The address is globally unique and indicates that the output of the crosslink from the first license chain to the second license chain can only be referenced by the transaction input of the second license chain.

The UTXO model and the balance model are mainly transferred into and out of the transaction flow token, including the user account and the contract account with the balance model. Similarly to transactions, direct or indirect roll-in and roll-out transactions may be used in the system to effect the transfer of tokens between the UTXO model and the balance model, as described separately below.

Directly transferring into a transaction: the input is an unspent output that references the UTXO model, the output is the user account address L2 of the balance model, and the output cannot be referenced for cost. The output can use the amount commitment, the output amount commitment Cvin is the amount transferred into the Balance model, so the Balance result Cv2+ Cvin is obtained by adding homomorphic operation with the Balance value Cv2 of L2. The transaction may contain a range attestation of Cvin ∈ [0,2^ 64). Direct transfer to a non-supported contract account address requires an indirect transfer to the contract account address because the execution of the contract may fail, but the transfer to the trade cannot be revoked and the output cannot be referred to for cost.

Direct roll-out transaction: inputting a user account address or a contract account address of the balance model, and outputting a user primary address of the UTXO model. Since the address of the balance model is entered, the nonce count is included in the transaction to prevent replay. If the user account address is entered, the transaction is generated by the user, the nonce value is the sender's user account transaction count, and the sender then signs the transaction using the private signature key. If a contract account address is entered, the transaction is generated by the contract script, actually a roll-out transaction is generated and signed by the endorsement node executing the contract, and the nonce value generates a count of roll-out transactions for the contract account address. For example, Balance value Cv1 of input address L1 (user account address or contract account address) and Balance result Cv1-Cvou obtained by subtraction operation with amount commitment Cvou output by roll-out transaction, wherein the transaction may include range certification of Cv1-Cvou > -0 and range certification of Cvou ∈ 0,2^ 64).

Indirect transfer into transaction: the indirect transfer mode is that the user generates an intermediate transaction (namely the first intermediate transaction), the intermediate transaction outputs a binding committed address, the intermediate transaction refers to the unspent output of the UTXO model, the output is the intermediate transaction address, the endorsement node generates a response receipt transaction (namely the first response receipt transaction) after receiving the intermediate transaction, the input of the first response receipt transaction is one or more first intermediate transactions, the output of the first response receipt transaction comprises a user account address or a contract account address to be transferred into the balance model, and the binding (or association) of the committed address bound by the intermediate transaction is realized. The commitment address can be generated in the following way: c ═ r × P + t × H, where C is the commitment address, P is the user's public signature key, H is the second generator, r is the first coefficient, and t is the second coefficient. A third generator H2 and a third coefficient u, such as C r P + t H + u H2, may also be included.

For example, the transfer user account address, the input commitment address of the confusing transaction is C1 ═ r1 × P + t1 × H, C2 ═ r2 × C1 and r2 ═ 1-r 1)/r1, the output user account address is La ═ 8+ HL (ID, P), the binding commitment address is C3 ═ C1+ C2- (t1/r1) × H ═ P, and it can be verified whether La is equal to 8+ HL (ID, C3). If the transfer is carried into the contract account address, the input commitment address of the confusing transaction is C1 ═ r1 ═ P + t1 ═ H + nonce ═ r1 ═ H2, C2 ═ r2 ═ C1 and r2 ═ 1-r 1)/r1, the output contract account address is Lc ═ 9+ HL (ID, La | | nonce) and La ═ 8+ HL (ID, P), the binding commitment address is C3 ═ C1+ C2- (t1/r1) · H ═ P + nonce H2, so that the coefficient nonce can be given, and La ═ 8+ HL (ID, C3-nonce) Lc 2 can be calculated, and whether the transaction is correct or not can be verified. The user account address or contract account address output above cannot be referenced to the cost as well. The output amount commitment Cvin is similar to the direct transfer, and is accumulated to the Balance value of the corresponding account. After confusion, other people do not know which input address corresponds to the output, that is, which address generates the transfer-in transaction, because the promised address bound to the intermediate transaction cannot distinguish whether the transfer-in transaction or the common transaction, only the endorsement node can know the promised address, but can verify the promised address. The above coefficient r1 may also be equal to 1, and C2 is equal to a unit cell, i.e., an infinite point or a zero point of the elliptic curve.

And if the output of the indirect transfer is a contract account address, calling a corresponding contract script, and encrypting the called parameter in the intermediate transaction data, wherein the contract execution may fail. The endorsement node executes the corresponding contract script while generating the receipt obfuscated transaction, and encrypts and stores an execution result and the like in remark information corresponding to the obfuscated transaction if the execution is successful; if the execution fails, the contract account address output by the confused transaction is cancelled, the input amount is output to a new primary address of the sender, the failure reason and the like are stored in the remark information of the receipt transaction in an encrypted manner, and finally the receipt transaction is endorsed. Therefore, the contract execution fails, the contract account address is not output actually, the transfer-in transaction is not formed, and the user can quote the cost again.

Indirect roll-out transaction: similar to the direct roll-out transaction, the difference is that instead of directly outputting the user's primary address of the UTXO model, a second intermediate transaction outputs an intermediate transaction address, binding the commitment address of the outputting user. If the user account address of the balance model is input, generating intermediate transaction data by the user; if the input is the contract account address of the balance model, intermediate transaction data is generated when the endorsement node executes the contract, the endorsement node generates a response piece transaction (namely the second response piece transaction), the input of the second response piece transaction is one or more second intermediate transactions, and the output of the second response piece transaction is the primary address of the user of the UTXO model and is associated with the commitment address bound by the intermediate transaction address.

Therefore, through the transfer-in and transfer-out transaction of the UTXO model and the balance model, the token can be transferred in different model function areas, the transfer-in contract account model is supported, the corresponding contract script is executed, and the contract is executed and the primary address of the user of the UTXO model is transferred out.

Before merging the UTXO model transaction data of each private chain account, the transaction data may be verified, and after the verification is correct, the transaction data may be merged into an alliance chain (or uplink alliance chain). The purpose of the verification is to prevent the private chain from generating incorrect transaction data, resulting in an increase in the federation tokens that are not known, so that the total amount of transitive tokens within the federation can be confirmed. The balance model functional area is added, but the data of the balance model part does not participate in merging, so that the correct token circulation of the UTXO model transaction data needs to be verified, and whether the transferred amount is effective or not needs to be verified. And the transferred-out amount can be considered to be valid only by verifying the cumulative transfer-in amount promise CvinSum > as the cumulative transfer-out amount promise CvoutSum without verifying the data of the balance model. If the balance state of the private chain of a certain system is wrong, the system can be ensured to be inside and not to be transmitted to other mechanism systems, the risk diffusion is avoided, and other member mechanisms of the alliance chain are protected.

As shown in fig. 4, the data in the block of the license chain is divided into two parts, the off-system verification data and the rest data. The first part is the off-system verification data, including the transaction data of the UTXO model, the transfer-in transaction data and the transfer-out transaction data, and optionally may also contain metadata containing the range certificate of CvinSum-CvoutSum > -0. The second part is the rest data except the verification data outside the system, namely the non-system verification data, and mainly comprises the transaction data of the balance model and the like. The two data sets in the block respectively generate a Merkle Tree, and the corresponding Merkle Root can be recorded in the block header data of the private chain. Authentication also encompasses both system external authentication and internal authentication. The external verification of the system can be the verification of the data to be merged by the verifier of the federation chain, such as other enterprises or endorsement nodes of the federation chain, when merging the federation chains. The external authentication means authenticates only one or more of the following: whether the quote unlocking of the UTXO model transaction is effective, whether the sum of the input amount commitments of the transaction is equal to the sum of the output amount commitments, and the range certification of the output amount commitments, namely whether the circulation of the coalition token is correct is verified. The internal verification may include all verifications within the permit chain, including whether the output address user exists, whether the contract result is correct, whether the user status is correct, etc.

In an exemplary embodiment, the first data in the set of off-system verification data may be metadata, which is not transactional data. The metadata includes proof data of transfer-in amount commitment, namely CvinSum and CvoutSum, and CvinSum-CvoutSum > is range proof of 0, wherein CvinSum is the cumulative transfer-in amount commitment from the UTXO model to the balance model, and CvoutSum is the cumulative transfer-out amount commitment from the UTXO model to the balance model. CvinSum and CvoutSum can be obtained by accumulating CvinSum 'and CvoutSum' contained in the metadata in the previous block and all the transfer-in and transfer-out amounts in the block, so that the verification process does not need to store the state. Other additional information may also be included in the metadata, such as commitment cingoall of total deposit amount and commitment CoutgoAll of total withdrawal amount currently circulated by the private chain system, and range certification of cingoall-CoutgoAll > -0. CincomeAll is the sum of the cumulative input amount commitment and the cumulative issued amount commitment of the cross-permit chain transaction, and CoutgoAll is the sum of the cumulative output amount commitment and the cumulative recovery amount commitment of the cross-permit chain transaction. FIG. 5 is an exemplary list of metadata in a license chain chunk with multiple asset types token.

The above analysis of homogeneous tokens containing several asset types in the system forms a corresponding transaction chain of several DAG structures. So there may be multiple federation-issued tokens circulated over the private chain, the metadata in the tiles may contain a list in which the accumulated data and certification for different asset types tokens are recorded, respectively. For example, cincometal ═ cumulative cross-chain input amount commitment + cumulative distribution amount commitment, CoutgoAll ═ cumulative cross-chain output amount commitment + cumulative recovery amount commitment, and cincometal-CoutgoAll represent the total amount of a certain type of asset in the system, and CvinSum-CvoutSum represent the total amount of a certain type of asset balance model part in the system, so the difference between the two is the total amount of a certain type of asset UTXO model part in the system, and a range proof of the difference between the two can be given in the metadata. The list of metadata has recorded therein token identifications for a plurality of different asset types and corresponding cumulative amount commitment and scope certification data.

If the private chain system internal transaction uses the zero-knowledge proof mode, the externally verified coalition chain verifier can only verify whether the zero-knowledge proof is correct, does not know the actual transaction data, and needs to convert to the address transaction mode for the cross-private chain transaction. To prevent the system from rolling out illegal tokens, the validity of the cross-chain output transaction can be demonstrated by the amount in the metadata. The principle is similar to that of verifying that the cumulative transfer amount commitment of the UTXO model and the balance model is larger than or equal to the cumulative transfer amount commitment, so that the system cannot output wrong tokens to other mechanism systems across private chains, and risk diffusion is avoided.

In an exemplary embodiment, the specific merging process is: after a new block data is generated by a certain permission chain, the verifier of the alliance chain carries out external verification on the block data, namely only the system external verification data in the block is verified, whether the non-expense transaction referred by the uplink data input to be tested has member certification of the alliance chain needs to be verified, namely, the data of the uplink alliance chain are all the non-expense output referred by the alliance chain, and therefore the cross-permission chain transaction is merged and then converted into the transaction in the alliance chain. And after the verifier successfully verifies, adding a block head hash value for indicating the height of the block of the restricted alliance chain to the block head data of the block of the permission chain, namely the maximum block height corresponding to the uneconomic output on the alliance chain referenced by the transaction of the cross permission chain in the block. If the cross-permission-chain transaction is not contained in the permission-chain block, the block head hash value which is equal to the block head hash value corresponding to the previous permission-chain block head contained in the permission-chain block head and represents the height of the restricted alliance-chain block, namely, if the cross-permission-chain transaction is not contained, the height of the restricted alliance-chain block is unchanged. If the last block does not contain a cross-grant chain transaction, nor does there be a uplink alliance chain (the block headers of the uplink alliance chain all have block header hash values indicating the restricted alliance chain block height), then forward recursion needs to continue. If no cross-permit chain transactions are contained in the starting block recursion, the block header hash value of the block header, which represents the restriction federation chain block height, is set to a first preset value (e.g., zero).

As shown in fig. 6, the federation chain block header X contains block header data for a plurality of grant chains, exemplary block header data with a grant chain a and a grant chain B, and block header data for other grant chains. Where the grant chain B chunk header N1 and chunk header N2 have hash values representing chunk header X1 that limit the federation chain chunk height, so indicating that N1 and N2 can only chain federation chains after federation chain chunk header X1. So N1 uplink alliance chain block X2, N2 uplink alliance chain block Xn. And the block header data of the grant chain B is not contained between the federation chain blocks X2 and Xn, but only contained block header data of other grant chains, so the block header data of the grant chain B is in turn a uplink federation chain. Similarly, the block Xn of the alliance chain also includes the block header Nm of the grant chain B, which means that one block of the alliance chain may contain a plurality of block header data of a certain grant chain, but also requires that the uplink be performed sequentially. By these two conditions, it is ensured that the input references to UTXO transaction data for the permit chain to which the uplink alliance chain corresponds are both front, uneconomical outputs over the alliance chain and are not affected by alliance chain forking.

And then, the verifier carries out endorsement signature on the block header data and sends the endorsement signature to an account keeper of the alliance chain, and the account keeper carries out consensus uplink alliance chain on the block header data. Similarly, after the other system private chains generate new block data, they are also verified and the block header data is linked on the chain.

The bookkeeper of the alliance chain needs to ensure that the allowed chain block header data comprises the previous allowed chain block header data to uplink the alliance chain before, and no other block header data of the allowed chain exists subsequently, namely the allowed chain block headers are sequentially uplink. And the block head hash value corresponding to the permission chain block head and used for representing the block head hash value for limiting the height of the alliance chain block is equal to a forward alliance chain block head hash value. The hash value is a first preset value and does not limit the block height of the uplink alliance chain because no unused outputs of other allowed chains are referenced and the uplink alliance chain can be linked at any block height. Since transactions in the license chain block can be divided into two categories, transactions within the license chain and transactions across the license chain. These two conditions guarantee the validity of the trade uplink alliance chain in the permit chain and the validity of the trade uplink alliance chain across the permit chain respectively, because the sequential uplink of the permit chain blocks can guarantee that the trade in the permit chain refers to the forward non-cost output in the permit chain. And if the alliance chain generates a bifurcation, the transaction data after the uplink alliance chain can be ensured to meet the input reference that the input references the front unconsumed output on the alliance chain by the block header hash value used for representing the block height of the restricted alliance chain.

The bookkeeper verifies that the block head of a certain permission chain sequentially links the alliance chain, and also needs to verify whether the first block head of the permission chain links the alliance chain is valid, if the hash value of the block head, which represents the block height of the restricted alliance chain, contained in the first block head is not a first preset value, the first block head which is valid cannot be verified, because the block before the permission chain may contain cross-chain transaction data. Therefore, the hash value of the first block header of the uplink alliance chain in a certain permission chain, which represents the block header with the restricted alliance chain block height, must be a first preset value, so as to represent that no cross-chain transaction data is contained in the block before the permission chain. If the current block of the license chain does not contain the cross-license chain transaction and the block before the license chain contains the cross-license chain transaction, the hash value of the block header of the current block header indicating the block height of the restricted federation chain may be set to a second preset value (e.g., FF … FF) because the block headers of the license chain sequentially link the federation chains. The block header data of the permission chain containing the second preset value also does not limit the block height of the uplink alliance chain, but indicates that the block before the permission chain contains the cross-permission chain transaction, cannot be used as the first block header data of the uplink alliance chain, and the block height of the uplink alliance chain is implicitly limited through uplink in sequence, because the uplink alliance chain must be limited after the block height of the uplink alliance chain (containing the cross-chain transaction) is explicitly limited.

The merged federation chain has a two-layer structure, as shown in fig. 7, where the first layer is a middle layer of the federation chain (including block header data of the private chain), the second layer is ledger data of the federation chain (i.e., block data corresponding to the block header of the private chain), and the non-system-outside verification data in the block of the permission chain does not belong to the federation chain. Therefore, the transaction data of the private chain is not certified by the member of the private chain before the uplink alliance chain, and is certified by the member of the alliance chain after the uplink alliance chain, and the certification is also two layers. The federation chain uses a two-layer structure, the amount of first-layer data which needs to be generated by combination actually is very small, a private chain which combines a plurality of large amounts of account book data can be supported, and only the first-layer data is disclosed, so that no privacy information can be revealed. Therefore, by means of the layered account book and the multi-level consensus, the problems of accounting and safety privacy of large-scale account book data of the alliance chain are solved.

Several member chains in the alliance chain can realize faster cross-chain transaction between the sub-alliances by establishing the sub-alliance chain. The uplink mode of the sub-alliance chain is the same as that of the alliance chain, but the number of the participating member chains is small, and the member chains can trust each other and only verify the cross-chain transaction, so that the cross-chain transaction between the sub-alliances can be completed more quickly. The verifier of the alliance chain verifies that the cross-permission-chain transaction between the sub-alliance chains is verified as a transaction mode in the sub-alliance chains, and the cross-permission-chain transaction between the non-sub-alliance chains is verified as a normal cross-chain transaction mode. While transaction data within the chain need only reference the unspent output within the chain, the chunk-header hash value of a sub-federation chain used to represent the limit federation chain chunk height is the maximum chunk height corresponding to the unspent output on the federation chain referenced by the cross-permit chain transaction between non-sub-federation chains. And the new first-layer block data generated by the sub-alliance chain consists of permission chain block header data participating in the sub-alliance chain, and then the block header data are packaged together and added with block header hash values used for indicating the limitation of the alliance chain block height and the alliance chain is linked up, so that cross-chain transaction between the permission chains of the sub-alliance chain can be ensured and the block header hash values can be processed as an intra-chain transaction mode of the sub-alliance chain.

The balance model may also use a stand-alone system, i.e. the private chain only contains UTXO model transactions and transfer-in and transfer-out transactions (it is necessary to be able to calculate an amount commitment, the actual transfer-out transaction being initiated by the balance model). The balance model uses an independent system, is different from the UTXO model in consensus, can not ensure the consensus block time, and the transaction and the state are based on the data of the block of the balance model, so that two parts need to have a set of transfer-in and transfer-out transaction respectively. For example, the UTXO model generates a transfer-in transaction, and a balance model needs to be copied; or the balance model generates a roll-out transaction, the UTXO model also needs to be copied. In order to ensure that the transfer-in and transfer-out transactions of two different systems are in one-to-one correspondence, verification can be performed in a serial number counting mode.

The private chain of the organization can also be a license chain (alliance of the organization) in which a plurality of organization nodes participate in management together, namely an endorsement node and an accounting node with a plurality of organizations, and the related organization IDs are replaced by system IDs or chain IDs. That is, whether the private chain or the permission chain of the federation of enterprises, can participate in the federation chain merged into a chain, and the disclosed embodiments are not limited in any way. And may also be recombined into a federation chain by sub-federation chains (federation of chains), for example by merging block header data of the first layer.

The signature key of the user may be replaced with a signature sub-key of the user, for example, a signature sub-public key PkId ═ Hash (su, keyId) × Pk, where su is a generation private key or a view private key of the user, Pk is a signature public key of the user, keyId is an identifier of the sub-key, and a corresponding signature sub-private key dkId ═ Hash (su, keyId)% dk%, where dk is a private key of Pk, and n is an order of an additive group with G as a base point. Different scenes can use different signature subkeys to protect the privacy and security of the user.

For example, a user has 5 public keys Pa, Pb, Pc, Pd, and Pe, and the user needs to register on the private chain using the 5 public keys, so that the multiple signature public key of the user is Px Pa + Pb + Pc + Pd + Pe, and the multiple signature sub-public key of the user is h Px h (Pa + Pb + Pc + Pd + Pe), that is, the sum of each sub-public key of the user, where h is Hash (su, keyId). However, the multiple signature keys lack a combination relationship, the relationship of the key combination can be encoded as sc, and the keyId can contain sc information.

For example, the above-mentioned 5 public keys of the user are respectively 5 points P (x, y) on the elliptic curve, P1-P5 are sequentially ordered according to the size of x, AND according to the sequence number AND the combination relationship of the keys, for example, OP _2(1,3,5) OP _3OP _ CMS AND OP _1(2,4) OP _2OP _ CMS, where OP _ CMS represents the verification of m-of-n multiple signatures, including n public keys, AND at least m public keys are signed. The above indicates key number 1,3,5, key 2-of-3 signature and key number 2,4, key 1-of-2 signature. The combinatorial relationship is encoded (RLP) to sc by recursive length prefix. KeyID contains sc information, e.g., KeyID + sc. Therefore, the generated multiple signature sub-keys are associated with the key combination relationship, and the sub-keys generated by different combination relationships are different. The user public key is used in the transaction, the receiver only needs to present a multiple signature public key or a common public key to the sender, and the sender cannot distinguish the type of the key because the multiple signature public keys are all a certain point on the elliptic curve, but the multiple signature public keys lack a combination relation. Through the multiple signature sub-keys with hidden combination relationship, a user can generate multiple signature sub-public keys in any combination mode only by registering the original multiple public keys, the system can also verify the validity of the combination relationship, the multiple signature sub-keys with different combination relationships can be used in different scenes, and other people can be prevented from replacing or tampering with other combination relationships.

An exemplary embodiment of the present disclosure also provides a computer storage medium having computer-executable instructions stored thereon; the computer executable instructions, when executed, can implement the methods provided by one or more of the foregoing exemplary embodiments, for example, a processing method of a chain structure, a data processing method of a chain structure, or a data verification method of a chain structure. Including volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer.

An exemplary embodiment of the present disclosure also provides a computer apparatus (or computer device). The computer apparatus may include a processor, a memory, and a computer program stored on the memory and executable on the processor, the processor when executing the computer program may implement the chain structured processing method, the chain structured data processing method, or the chain structured data verification method of the present disclosure. The structure of the above-described computer apparatus is explained below by way of an example.

As shown in fig. 8, in one example, a computer device may include: a processor 101, a memory 102, a bus system 103 and a transceiver 104, wherein the processor 101, the memory 102 and the transceiver 104 are connected via the bus system 103, the memory 10 is used for storing instructions, and the processor 101 is used for executing the instructions stored in the memory 102 to control the transceiver 104 to transmit signals.

It should be understood that the processor 101 may be a Central Processing Unit (CPU), and the processor 101 may be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

Memory 102 may include both read-only memory and random access memory and provides instructions and data to processor 101. A portion of the memory 102 may also include non-volatile random access memory. For example, the memory 102 may also store device type information.

The bus system 103 may include a power bus, a control bus, a status signal bus, and the like, in addition to the data bus. For clarity of illustration, however, all buses are labeled as bus system 103 in fig. 8.

In implementation, the processing performed by the computer device may be performed by instructions in the form of hardware, integrated logic circuits, or software in the processor 101. That is, the steps of the method disclosed in the embodiments of the present disclosure may be implemented by a hardware processor, or implemented by a combination of hardware and software modules in a processor. The software module may be located in a storage medium such as a random access memory, a flash memory, a read only memory, a programmable read only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory 102, and the processor 101 reads the information in the memory 102 and completes the steps of the method in combination with the hardware thereof. To avoid repetition, it is not described in detail here.

It will be understood by those of ordinary skill in the art that all or some of the steps of the methods, systems, functional modules/units in the devices disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed by several physical components in cooperation. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as is well known to those of ordinary skill in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by a computer. In addition, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media as known to those skilled in the art.

The foregoing shows and describes the general principles and features of the present application, together with the advantages thereof. The present application is not limited to the above-described embodiments, which are described in the specification and drawings only to illustrate the principles of the application, but also to provide various changes and modifications within the spirit and scope of the application, which are within the scope of the claimed application.

Claims

1. A processing method of a chain structure, wherein the chain structure is a license chain, and the license chain includes transaction data of a UTXO model and transaction data of a balance model, the processing method comprising:

The balance model performs a roll-out transaction to the UTXO model.

2. The method of claim 1, wherein the UTXO model conducts a transfer-in transaction to a balance model, comprising:

the UTXO model performs a direct transfer transaction to the balance model; or the UTXO model carries out indirect transfer transaction to the balance model;

wherein: the input directly transferred into the transaction refers to the unspent output of the UTXO transaction, and the output is the user account address of the balance model; the indirect transfer transaction includes a first intermediate transaction whose input references the unspent output of the UTXO transaction and a first return transaction whose output is a user account address or a contract account address of a balance model.

3. The method of claim 2,

the first intermediate transaction in the indirect transfer transaction is bound with first commitments of one or more receivers, the output of the first intermediate transaction is an intermediate transaction address, the input of the first receipt transaction is one or more first intermediate transactions, the output of the first receipt transaction is bound with second commitments, the second commitments are new commitments obtained after the first commitments are operated, and the address generated by the second commitments through the first operation is a user account address or a contract account address of the balance model.

4. The method of claim 1, wherein the balance model conducts a roll-out transaction to the UTXO model, comprising:

the balance model performs a direct transfer-out transaction to the UTXO model, or the balance model performs an indirect transfer-out transaction to the UTXO model;

wherein: the input of the direct transfer-out transaction is the user account address or contract account address of the balance model, and the output is the user primary address of the UTXO transaction; the indirect roll-out transaction includes a second intermediate transaction whose input references a user account address or a contract account address of a balance model, and a second response piece transaction whose output is a user one-time address of the UTXO transaction.

5. The method of claim 4,

and a second intermediate transaction in the indirect roll-out transaction is bound with a third commitment of one or more receivers, the output of the second intermediate transaction is an intermediate transaction address, the input of the second receipt transaction is one or more second intermediate transactions, the output of the second receipt transaction is bound with a fourth commitment, the fourth commitment is a new commitment obtained after the third commitment is operated, and the address generated by the fourth commitment through the second operation is a primary address of a user of the UTXO transaction.

6. A transaction data processing method with a chain structure is characterized in that the chain structure is a permission chain, the permission chain comprises transaction data of a UTXO model and transaction data of a balance model, and the transaction data processing method comprises the following steps:

implementing a circulation of tokens of the UTXO model and the balance model of the permit chain with the chain structure processing method of any of claims 1-5, obtaining data of a transfer-in transaction and/or data of a transfer-out transaction;

7. The method of claim 6, wherein the merging the off-system verification data of a plurality of admission chains belonging to the same federation chain into ledger data of the federation chain comprises:

and after the block header data of the plurality of permission chains are identified together, generating first-layer ledger data of the alliance chain, wherein the off-system verification data corresponding to the block header data of the permission chains is used as second-layer ledger data of the alliance chain, so that the TXO transaction data chains of the plurality of permission chains are merged into the TXO transaction data chain of the alliance chain.

8. The method of claim 6, further comprising: validating, by a verifier, the out-of-system validation data for the license chain block, comprising:

verifying whether input reference of the transaction data of the UTXO model and/or the data converted into the transaction is non-cost output on a alliance chain; or

Verifying whether the input reference to the transaction data of the non-cross-chain UTXO model of the license chain and/or the data carried into the transaction is a forward non-spent output of the license chain.

9. The method of claim 6,

before the merging the off-system verification data of a plurality of admission chains belonging to the same federation chain into ledger data of the federation chain, the method further comprises:

the verifying method of the alliance chain for verifying the off-system verification data of the permission chain block to be uplinked comprises the following steps: verifying whether the input reference of the transaction data of the UTXO model and/or the data transferred into the transaction is an unspent output on a alliance chain or whether the input reference of the transaction data of the UTXO model and/or the data transferred into the transaction which are not across chains of the license chain is a forward unspent output of the license chain;

after the verification is passed, adding a block header hash value used for representing the height of a restricted alliance chain block in the allowed chain block header data to be linked, wherein the height of the restricted alliance chain block is at least the maximum block height corresponding to the non-expense output on an alliance chain referenced by the cross-allowed chain transaction in the allowed chain block;

endorsement signing permission chain block head data added with a block head hash value for indicating the height of the limitation alliance chain block;

the merging of the off-system verification data of a plurality of admission chains belonging to the same federation chain into the ledger data of the federation chain includes: and after the block head data of the plurality of permission chains subjected to endorsement signature are identified together, generating first-layer account book data of the alliance chain, wherein the out-of-system verification data corresponding to the block head data of the permission chains is used as second-layer account book data of the alliance chain.

10. The method of claim 9, wherein adding a block header hash value indicating a restricted federated link block height to the allowed link block header data to be linked comprises:

when the permission chain block to be linked up does not contain the cross-permission chain transaction, recursion is carried out on the permission chain to the last permission chain block containing the cross-permission chain transaction, a permission chain block head pointing to the permission chain block is found on a alliance chain, and a block head hash value used for representing the height of the limitation alliance chain block in the permission chain block head is added into the permission chain block head data of the current chain to be linked up; or when the block of the permission chain to be linked does not contain the transaction of the cross-permission chain and recurses to the block of the permission chain containing the transaction of the cross-permission chain on the permission chain, adding a second preset value into the block header data of the permission chain to be linked currently.

11. The method of claim 10, further comprising: when the forward recursion on the permission chain is carried out to the starting block and the cross-permission chain transaction is not contained, the block head hash value used for representing the height of the block of the restricted alliance chain in the permission chain block head data to be linked is set to be a first preset value.

12. The method according to claim 6, wherein the out-of-system verification data of the license chain further comprises metadata including, for any asset type token, a cumulative transfer-in amount commitment and a cumulative transfer-out amount commitment of the UTXO model of the asset type token to a balance model, and range certification data that a difference between the cumulative transfer-in amount commitment and the cumulative transfer-out amount commitment is greater than or equal to zero.

13. The method of claim 12, wherein the metadata further comprises, for any asset type token: a first result of a cumulative input amount commitment plus a cumulative issuance amount commitment for the asset type token across a license chain transaction, and a second result of a cumulative output amount commitment plus a cumulative recovery amount commitment across a license chain transaction, and range attestation data having a difference between the first result and the second result greater than or equal to zero.

14. The method of claim 6, further comprising:

the method comprises the steps that a first Mercker tree is generated by a system-outside verification data set of the permission chain, a second Mercker tree is generated by other data sets of the permission chain except the system-outside verification data, and a root hash value of the first Mercker tree and a root hash value of the second Mercker tree are recorded in block header data of the permission chain.

15. The method of claim 6, further comprising:

16. The method of claim 15, wherein the first chain of permissions generates cross-chain output transaction data, comprising:

the first license chain generates proof data of equal first amounts represented by a first peadson commitment of a first algorithm, a second peadson commitment of a second algorithm, and a second generator coefficient promised by the first and second peadson commitments, output across the chain.

17. A chain structure transaction processing method for a chain-crossing transaction of a first license chain using a first algorithm and a second license chain using a second algorithm, the chain structure transaction processing method comprising:

18. The method of claim 17,

the attestation data includes: a third peterson commitment of the first algorithm, a fourth peterson commitment of the second algorithm, and a first scalar, a second scalar, and a third scalar, wherein a second number of quotients represented by second generator coefficients promised by the third and fourth peterson commitments are equal;

wherein the first hash value is derived from the first, second, third, and fourth peadson commitments and parameters of the first and second algorithms by a first hash function; the second hash value is derived from the first, second, third, and fourth peadson commitments and parameters of the first and second algorithms by a second hash function.

19. A method for verifying data with a chain structure, wherein the chain structure is a license chain, and the license chain comprises transaction data of a UTXO model and transaction data of a balance model, and the method for verifying data comprises:

20. The method of claim 19 wherein verifying the transaction-in data and/or the transaction data of the UTXO model by a verifier outside the license chain comprises:

21. The method of claim 19, further comprising:

22. A computer-readable storage medium storing computer-executable instructions for performing the method of any one of claims 1-5 or 6-16 or 17-18 or 19-21.

23. A computer arrangement comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the steps of the method according to any one of claims 1-5 or 6-16 or 17-18 or 19-21 are implemented when the program is executed by the processor.