CN111159288A

CN111159288A - Method, system, device and medium for storing, verifying and realizing chain structure data

Info

Publication number: CN111159288A
Application number: CN201911294794.6A
Authority: CN
Inventors: 郑杰骞
Original assignee: Individual
Current assignee: Individual
Priority date: 2019-12-16
Filing date: 2019-12-16
Publication date: 2020-05-15
Anticipated expiration: 2039-12-16
Also published as: TW202125299A; TWI749583B; CN111159288B; WO2021120253A1

Abstract

The disclosure provides a chain structure data storage method and device, a chain structure verification method and device, a chain structure system and implementation method, a storage medium and a computer device. The chain structure implementation method comprises the following steps: after the account book data is signed by the first chain system, writing the signed account book data into block data of the first chain; after verifying the block data of the first chain, the second chain system writes one or more continuous block data of the first chain into the block data of the second chain; the data storage device takes part or all of the connection information in the second chain as a first key, after verifying that the data associated with the first key is error-free, the data storage device stores the data as input data or output data, and the input data and the output data stored by the same data storage device are associated according to the same connection information. The connection storage provided by the disclosure can be used for dispersedly storing huge chain structure data on a plurality of devices, so that the storage and the verification are convenient.

Description

Method, system, device and medium for storing, verifying and realizing chain structure data

Technical Field

The present application relates to, but not limited to, the technical field of computer data processing, and in particular, to a method and an apparatus for storing chain structure data, a method and an apparatus for verifying chain structure data, a chain structure system and an implementation method thereof, a storage medium, and a computer apparatus.

Background

The existing decentralized system such as a public chain system has the characteristics of openness, transparency, traceability, non-falsification and the like, so that the trust cost among transaction participants can be reduced, and the value transfer can be realized as the basis of trust.

However, the current decentralized system has the following problems: the node needs to store all data to verify the entire ledger data.

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.

The invention provides a data storage method, a chain structure verification method, a chain structure implementation method and a chain structure implementation system.

In a first aspect, the present disclosure provides a data storage method for storing data in a chain structure, the method including:

and using part or all of connection information in a chain in the chain structure as a first key, using data in the chain structure associated with the first key as a value, and storing the data as input data or output data, wherein the input data and the output data stored in the same data storage device are associated according to the same connection information.

In a second aspect, the present disclosure also provides a chain structure verification method, including:

and using part or all of connection information in a chain in the chain structure as a first key, using data in the chain structure associated with the first key as a value, verifying whether the data associated with the first key has errors, and storing the data as input data or output data after verifying that the data associated with the first key has no errors.

In a third aspect, the present disclosure further provides a chain structure verification method, including:

and using part or all of the connection information of the chain in the chain structure as a second key, acquiring data stored in a data storage device and associated with the second key from the data storage device, and verifying whether the data in the chain structure has errors according to the acquired data.

In a fourth aspect, the present disclosure also provides a method for implementing a chain structure, where the chain structure system includes a first chain system, a second chain system, and a data storage device, the method includes:

after the account book data is signed by the first chain system, writing the signed account book data into block data of the first chain;

after verifying the block data of the first chain, the second chain system writes one or more continuous block data of the first chain into the block data of the second chain;

the data storage device takes part or all of the connection information in the second chain as a first key, the data associated with the first key as a value, after verifying that the data associated with the first key is error-free, the data is stored as input data or output data, and the input data and the output data stored by the same data storage device are associated according to the same connection information.

In a fifth aspect, the present disclosure also provides a data storage device with a chain structure, the data storage device including a first storage module and a second storage module, wherein:

the first storage module is used for storing part or all of connection information of the chain in the chain structure as a first key;

the second storage module is used for storing the data in the chain structure associated with the first key as input data or output data, and the input data and the output data stored in the same data storage device are associated according to the same connection information.

In a sixth aspect, the present disclosure further provides a data verification apparatus with a chained structure, where the data verification apparatus includes a key value search module and a second verification module, where:

the key value searching module is used for searching part or all of connection information of the chain in the chain structure as a second key;

and the second verification module is used for acquiring the data which is stored by the data storage device and is associated with the second key from the data storage device, and verifying whether the data in the chain structure has errors or not according to the acquired data.

In a seventh aspect, the present disclosure also provides a chain structure system, including: a first chain system, a second chain system, and a data storage device, wherein:

the first chain system is used for writing the signed account book data into the block data of the first chain after signing the account book data;

the second chain system is used for writing one or more continuous block data of the first chain into the block data of the second chain after verifying the block data of the first chain;

the data storage device is used for using part or all of the connection information of the chain in the second chain as a first key, using the data associated with the first key as a value, verifying whether the data associated with the first key has errors, storing the data as input data or output data after verifying that the data associated with the first key has no errors, and associating the input data and the output data stored in the same data storage device according to the same connection information.

In an eighth aspect, the present disclosure also provides a computer-readable storage medium storing computer-executable instructions for implementing any one of the methods described above.

In a ninth aspect, the present disclosure also provides a computer apparatus comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of any one of the above methods when executing the program.

The connection storage provided by the disclosure can be used for dispersedly storing huge chain structure data on a plurality of devices so as to reduce the data storage pressure. This storage also facilitates verification.

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 diagram of an exemplary data storage method;

FIG. 2 is a schematic diagram of an exemplary data storage device;

FIG. 3 is a flow diagram of an exemplary data verification method;

FIG. 4 is a schematic diagram of an exemplary data storage device with authentication functionality;

FIG. 5 is a flow diagram of another exemplary data verification method;

FIG. 6 is a schematic diagram of an exemplary data verification device;

FIG. 7 is a flow diagram of an exemplary chain architecture implementation;

FIG. 8 is a schematic diagram of an exemplary chain architecture system;

FIG. 9 is an exemplary connection storage diagram with connection information Bd 1;

FIG. 10 is a diagram of an exemplary three-layer two-chain system architecture;

FIG. 11 is a block diagram of an exemplary computer device.

Detailed Description

The present application 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 herein. 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 application 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 of the features shown and/or discussed in this application 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.

The combination scheme of the private chain and the public chain is provided, the credibility problem of the private chain data is solved, part of fairness problems are solved, and each user side can equivalently verify all the ledger data only by storing part of ledger data.

The concepts involved herein are explained first.

token, refers to a token on a blockchain, also known as a pass.

Ca (certificate authority), authentication authorization.

eID (electronic identity), which refers to the electronic identity of the network of the citizen, is a credible real-name authentication method

Spv (simplified patent verification): simple payment verification, verifies whether a transaction is contained in a block of the chain and how many confirmations are passed through the merkel tree authentication path.

POA (proof of authority): authority certification, a consensus algorithm based on identity and reputation.

Gossip network protocol: also called Epidemic Protocol, is an unstructured peer-to-peer network Protocol, and is a network Protocol adopted by systems such as bitciin and the like.

Dht (distributed Hash table): the distributed hash table is a distributed storage method. Each client is responsible for a small range of routing without the need for a server and for storing a small portion of the data, thereby enabling addressing and storage of the entire DHT network.

Kademlia network protocol: the Distributed Hash Table (DHT) network protocol is a structured peer-to-peer network protocol and is a network protocol adopted by systems such as IPFS and the like.

Consistent hashing algorithm: an implementation of DHT. Can satisfy the balance, monotonicity, dispersion and load in a dynamically changing environment.

Utxo (outstanding Transaction output), unspent Transaction output, reference one or more unspent Transaction outputs to become spent, and create one or more new unspent Transaction outputs and continue to loop back. The chain structure of DAG (Directed Acyclic Graph) is formed according to the connection mode. Referred to herein as UTXO chains.

The public chain, which refers to a blockchain that anyone can read, send transactions and participate in consensus, belongs to a completely decentralized system. The embodiment of the invention adopts a similar public chain system which is the same as the public chain system except that anyone can send a transaction, and the transaction centralization and ledger data decentralization are met. In the public chain-like system described herein, anyone can read, verify transactions and participate in consensus, enabling traceability and non-tampering.

The private chain refers to a data chain with writing authority in one organization hand, and belongs to a centralized system.

A alliance chain refers to a data chain with writing authority in a plurality of organizations, and belongs to a partially decentralized system.

An exemplary embodiment herein provides a data storage method for storing data in a chain structure, as shown in fig. 1, including steps 11-12.

Step 11, using part or all of connection information of the chain in the chain structure as a first bond;

and step 12, taking the data in the chain structure associated with the first key as a value, storing the data as input data or output data, and associating the input data and the output data stored in the same data storage device according to the same connection information.

The data or the group of data comprises information in the previous data or the group of data, the information is the connection information of the chain, and the connection information enables the data to form a chain structure logically.

The means for data storage may be implemented using DHT technology. The device has stored thereon connection information in the chain structure as a first key (also referred to as key value or key value). The connection information as the first key may be part or all of the chain structure connection information. The first key may be, for example, an address or a hash value of an address.

For any one or one group of data in the chain structure, each or each group of data includes input information and output information, wherein the input information of the current data is output information of data M, the data M is logically previous data (previous data) of the current data, the input information of the current data or the output information of data M belongs to the connection information of the chain, the output information of the current data is input information of data N, the data N is logically next data (next data) of the current data, and the output information of the current data or the input information of data N also belongs to the connection information of the chain. The chain structure is, for example, a UTXO chain, each transaction data comprising a referenced uneconomic output as input information and a new uneconomic output as output information.

When receiving data matching the first key value, the data storage device stores the data as input data or output data according to the meaning of the data in the chain structure. Input data and output data stored on the same data storage device are associated according to the same key (i.e., link information of the chain), and such storage may be referred to as link storage or data pair storage. One or more sets of input data and output data may be stored on the same data storage device, the input data and output data being associated according to the same connection information for any one set of input data and output data. There may be one or more input data stored on the same device, or there may be zero (i.e., no output data) or one or more output data stored. The chain structure may be any chain having the characteristics of a chain structure. The data storage device can be a user end node, a consensus group or other devices needing connection storage. The data to be stored may be transaction data or control data, and for example, token issuance data and consensus reward data in the control data may be stored as input data, and token recovery data in the control data may be stored as output data. The corresponding keys are respectively a token issuing preset address, a consensus reward preset address and a token recycling preset address.

By adopting the connection storage, huge chain structure data can be stored on a plurality of devices in a scattered manner, so that the data storage pressure is relieved. This storage also facilitates verification.

In an exemplary embodiment, when the first key is used as part or all of the output information in the chain structure, the data associated with the first key is stored as input data; and when the first key is used as part or all of input information in the chain structure, storing the data associated with the first key as output data.

For example, if the first key is an output address in the chain structure, the data associated with the first key is stored as input data, and if the first key is an input address in the chain structure, the data associated with the first key is stored as output data.

The data storage device of this embodiment may be used in conjunction with other systems, such as a decentralized system or a centralized system.

The data storage device may include, for example, as shown in fig. 2, a first storage module 21 and a second storage module 22, where:

a first storage module 21, configured to store part or all of the connection information of the chain in the chain structure as a first key;

and the second storage module 22 is used for storing the data in the chain structure associated with the first key as input data or output data, and the input data and the output data stored in the same data storage device are associated according to the same connection information.

For example, when the first key is used as part or all of the output information in the chain structure, the second storage module 22 stores the data associated with the first key as the input data, and when the first key is used as part or all of the input information in the chain structure, the second storage module 22 stores the data associated with the first key as the output data.

By adopting the storage mode, the whole chain structure can be stored by a plurality of data storage devices in a segmented mode, and the retrieval and the verification are convenient.

An exemplary embodiment herein further provides a chain structure verification method, which is implemented by a data storage device, as shown in fig. 3, and includes steps 31-33.

Step 31, using part or all of connection information of the chain in the chain structure as a first bond;

step 32, using the data in the chain structure associated with the first key as a value, and verifying whether the data associated with the first key has errors;

and step 33, after verifying that the data associated with the first key has no error, storing the data as input data or output data.

As in the previous embodiments, the chain structure may be any chain having the characteristics of a chain structure. The data storage device can be a user end node, a consensus group or other devices needing connection storage. The data to be stored may be transaction data or control data. The connection information as the first key may be part or all of the chain structure connection information. In this embodiment, chain structure authentication is performed by the device (e.g., user end node) performing data storage. The data storage device stores the connection information in the chain structure as the first key, so that the data storage device verifies the data matched with the first key corresponding to the data storage device when receiving the data, and performs connection storage after no error exists in the verification.

Taking data as account book data as an example, after the data storage device verifies that the account book data has no error, when the output information of the account book data is judged to be matched with the first key, the account book data is stored as input data, when the input information of the account book data is judged to be matched with the first key, the account book data is stored as output data, and the input data and the output data stored on the same device are associated according to the same connection information. There may be one or more input data stored on the same device, or there may be zero (i.e., no output data) or one or more output data stored.

The embodiment performs verification during connection storage, can convert verification of the whole chain structure into local verification, and performs verification by the plurality of data storage devices respectively, which is equivalent to equivalently verifying the correctness of all data.

In an exemplary embodiment, storing the data as input data or output data may take the following form: when the first key is used as part or all of output information in the chain structure, storing data associated with the first key as input data; when the first key is used as part or all of input information in the chain structure, storing data associated with the first key as output data; the input data and the output data stored on the device are associated according to the same connection information.

In an exemplary embodiment, the verifying whether the data associated with the first key has an error includes one or more of the following verifications:

verifying 11, namely verifying whether the data is the data on the chain structure;

verifying 12, when the first key is used as input information in the chain structure, whether output information with the same connection information as the input information exists is verified;

verifying 13, when the first key is used as the input information in the chain structure, whether the output information having the same connection information as the input information is used;

and verifying 14, when the first key is used as input information in the chain structure and the data associated with the first key comprises a transaction amount, whether the transaction amount is correct or not is verified.

And verifying 15, when the first key is used as the input information in the chain structure and the data associated with the first key contains signature information, verifying whether the signature information is correct. The signature information is an unlocking signature of a user terminal generating the transaction data. And verifying whether the signature information is correct or not, namely verifying whether the signature information is valid or not.

The verification sequence numbers are for convenience of description only and do not represent the verification order. For the above verification 11, if the data is data on a chain structure, the verification is error-free; for verification 12, if there is output information having the same connection information as the input information, it is verified as error-free; for verification 13, if the output information having the same connection information as the input information is not used, the verification is no error; for verification 14, if the transaction amount is correct, then verification is no error; for verification 15, the signature information is verified to be valid, and then verified to be error-free.

An exemplary verification process: the data storage device synchronizes the block header data in the chain structure, the device searches whether the device stores the input data associated with the first key (can also search from the chain structure), if not, the connection error is judged, if yes, the connection associated with the input data is judged whether to be quoted, and if so, the connection error is judged; and judging whether the transaction amount of the ledger data is correct or not, if so, storing the ledger data as output data, identifying the associated connection of the input data as being quoted, namely, the associated output information is marked as used, if not, judging the data to be wrong, if so, verifying whether the signature information is correct or not when the data contains the signature information, and if not, judging the data to be wrong. The signature information is, for example, an unlocking signature of a user terminal that generated the transaction data. When the verification is successful, the output information associated with the input information will be marked as used.

In an exemplary embodiment, whether the data is the data on the chain structure may be verified in the following manner:

and synchronizing the block head data of the chain structure, and verifying whether the data is the data on the chain structure according to the root hash value of the Mercker tree in the block head data and the authentication path of the data.

In an exemplary embodiment, the method further comprises: and returning data which is stored by the data verification device and is associated with the connection information of the chain to the data verification device according to the request of the data verification device, wherein the data comprises but is not limited to one or more of the following data: input data, output data, a merkel tree authentication path, additional verification data.

There may be one or more of the input data. There may be no (i.e. zero) or one or more output data, no output data indicating that the connection to the input data is unused or not spent. Normally, there is output data only when there is input data, but the error condition is not excluded, only output data, no input data. The merkel tree authentication path exists in correspondence with input data or output data. Additional authentication data may or may not be present. Additional verification data is used to verify that the transaction amount is correct, for example, the UTXO may require the total input amount and total output amount to be accumulated, so that additional transaction data may be required to complete the transaction amount verification. The additional verification data also has a corresponding merkel tree authentication path.

In order to enhance the safety of the data, a verification mechanism of other devices is set, namely, a non-data storage device is used as a data verification device to verify whether the data in the chain structure has errors, and a node selected as the data verification device acquires relevant data from the storage device to complete verification.

The data storage device with verification function may include, for example, as shown in fig. 4, a third storage module 41, a first verification module 42, and a fourth storage module 43, where:

a third storage module 41, configured to store, as a first key, part or all of connection information of the chain in the chain structure;

a first verification module 42, configured to verify whether data in the chain structure associated with the first key has an error;

the fourth storing module 43 is configured to store the data in the chain structure associated with the first key as input data or output data after the verifying module 42 verifies that there is no error.

For example, the third storage module 41 may be stored in the same manner as the first storage module 21 in fig. 2, and the fourth storage module 43 may be stored in the same manner as the second storage module 22 in fig. 2, and the data storage device with the authentication function may be added with the first authentication module 42 on the basis of the data storage device shown in fig. 2. When the first key is used as part or all of the output information in the chain structure, the fourth storage module 43 stores the data associated with the first key as the input data, and when the first key is used as part or all of the input information in the chain structure, the fourth storage module 43 stores the data associated with the first key as the output data.

The first verification module 42 may perform any one or more of the verifications 11-15 described above, and will not be described herein.

In an exemplary embodiment, the data storage device may further include a sending module, configured to return, to the data verification device, data stored by the data verification device and associated with the connection information of the chain according to a request of another data verification device, where the data includes one or more of the following data: input data, output data, a merkel tree authentication path, additional verification data.

By adopting the storage and verification method, the whole chain structure can be stored by a plurality of data storage devices in a segmented mode and equivalently verified.

An exemplary embodiment herein further provides a chain structure verification method implemented by a data verification apparatus, as shown in fig. 5, the method includes steps 51-52.

Step 51, using part or all of connection information of the chain in the chain structure as a second key;

and step 52, acquiring data (namely, a value corresponding to the key) stored on the data storage device and associated with the second key from the data storage device, and verifying whether the data in the chain structure has errors according to the acquired data.

In order to enhance the safety of the data, other device verification mechanisms are arranged, namely, whether the data in the chain structure has errors or not is verified by the non-data storage device, and the node serving as the data verification device acquires the relevant data from the data storage device to complete verification. The second key may be, for example, an address or a hash value of an address. For the description of the chain structure, the connection information in the chain structure, the input information, and the output information, reference is made to the description in the foregoing embodiments, and details are not repeated here.

In an exemplary embodiment, the data associated with the second key retrieved from the data storage device includes, but is not limited to, one or more of: the data storage device stores: data associated with the second key as part or all of the output information in the chained structure, a merkel tree authentication path, additional verification data, wherein the second key is part or all of the input information in the chained structure. When the second key is used as part or all of the output information in the chain structure, the data associated with the second key is the input data stored in the data storage device; and when the second key is used as part or all of the input information in the chain structure, the data associated with the second key is the output data stored by the data storage device.

The data verification device can synchronize a block head with a chain structure, the block head contains the data volume of the accumulated account book, the data verification device generates a number address by using the data volume of the accumulated account book in the block head (generates a control data number address by using the data volume of the accumulated control, and generates a transaction data number address by using the data volume of the accumulated transaction), and acquires data which is stored on the data storage device and is related to a second key from the data storage device according to part or all of connection information of the number address acquisition chain as the second key. The control data numbering address is used as a key to acquire control data corresponding to the control data numbering address, and the control data numbering address can also comprise a Mercker tree authentication path of the control data; the transaction data number address is used as a key to acquire the transaction data corresponding to the transaction data number address, and the transaction data number address can also comprise a Mercker tree authentication path of the transaction data. For example, a preset address of token issuing data (abbreviated as token issuing address), a preset address of token reclaiming data (abbreviated as token reclaiming address), or a preset address of consensus reward data (abbreviated as reward address) of control data may be used as a key, and the key is used to acquire data associated with the key stored thereon from the data storage device; the transaction address of the transaction data may be used as a key with which to retrieve data stored thereon associated with the key from the data storage device.

In an exemplary embodiment, the verifying whether the data in the chain structure has an error according to the acquired data includes:

and synchronizing the block head data in the chain structure, and verifying whether the data in the chain structure has errors or not by combining the block head data with the data which is acquired from the data storage device and is associated with the second key. For example, including performing one or more of the following verifications:

a verification 21 for verifying whether the value associated with the second key obtained from the data storage device is data on the chain structure;

verifying 22, when the second key is used as input information of the acquired data, whether output information with the same connection information as the input information exists is verified;

a verification step (23) of verifying whether output information having the same connection information as the input information is used when the second key is used as the input information of the acquired data;

verifying 24, when the second key is used as input information of the acquired data and the acquired data comprises a transaction amount, verifying whether the transaction amount is correct;

and verifying 25, when the second key is used as the input information of the acquired data and the acquired data contains signature information, verifying whether the signature information is correct.

The verification sequence numbers are for convenience of description only and do not represent the verification order. For the above verification 21, if the value is data on a chain structure, then verify as error-free; for verification 22, if there is output information having the same connection information as the input information, it is verified as error-free; for the verification 23, if the output information having the same connection information as the input information is not used, the verification is no error; for verification 24, if the transaction amount is correct, then the verification is no error; for verification 25, if the signature information is valid, the verification is error-free.

An exemplary verification process: verifying input data stored on a data storage device by using a Merckel tree authentication path, or judging that the input data is a data error if one of the input data and the output data is not data on a chain; judging that the connection is wrong if only the output data exists; judging that the connection is wrong if the associated connection of the input data is quoted; judging whether the transaction amount of the output data is incorrect or not, and judging that the data is wrong; and judging that the signature information (such as an unlocking signature of a user end generating the data) in the data is incorrect, and judging that the data is wrong.

The security of the system can be improved through the non-storage device verification, and the risk caused by the fixed storage device verification is avoided.

The data verification apparatus may include, for example, as shown in fig. 6, a key value lookup module 41 and a second verification module 62, where:

a key value searching module 61, configured to search for part or all of connection information of the chain in the chain structure as a second key;

a second verifying module 62, configured to obtain, from a data storage device, data (i.e., a value corresponding to a key) stored in the data storage device and associated with the second key, and verify whether the data in the chain structure has an error according to the obtained data.

The second verification module 62 may perform any one or more of the verifications 21-25 described above, which are not described in detail herein.

By adopting the verification mechanism, the safety of the system is improved by adding the data verification device.

An exemplary embodiment herein also provides a chain structure implementing method, the chain structure system including a first chain system, a second chain system and a data storage device, as shown in fig. 7, the method including steps 71-73.

Step 71, after the account book data is signed by the first chain system, writing the signed account book data into block data of the first chain;

step 72, after verifying the block data of the first chain, the second chain system writes one or more continuous block data of the first chain into the block data of the second chain;

and 73, the data storage device takes part or all of the connection information in the second chain as a first key, the data associated with the first key as a value, after the data associated with the first key is verified to be error-free, the data is stored as input data or output data, and the input data and the output data stored by the same data storage device are associated according to the same connection information.

The ledger data includes transaction data and/or control data.

The first chain is a private chain or a alliance chain, and is a chain controlled by a management terminal, and the second chain is similar to a public chain, except that any data can not be uplinked. And after the block data verification is passed, the chain generating node of the second chain generates new block data according to the consensus algorithm of the second chain. The block data submitted by the first chain is sequentially recorded in the second chain, and the amount of the block data of the first chain contained in each block data of the second chain may not be fixed, that is, each block of the second chain may contain 1 to n block data of the first chain, and the amount is determined by the consensus algorithm of the second chain. Each block data on the second chain system is composed of one or more block data of the first chain system in sequence, so that the first chain system and the second chain system are identical in logic state. In the embodiment, a mode of generating the chain first and then verifying is used, that is, a mode of generating the second chain first and then verifying by the data storage device of the third layer is used. The actual ledger data is chained by a first layer, namely a first chain system, a second layer, namely a second chain system, can verify the signature of a Mercury tree and a management terminal, does not modify the ledger data, and verifies whether the ledger data has errors or not by a data storage device of a third layer. And realizing transaction centralization and account book data decentralization. The data storage devices on the third layer store and verify data in a connection storage mode, each data storage device only needs to store and verify a small amount of data, equivalent verification of the whole chain can be achieved, and burden of each device is reduced. And the chain generating node of the second layer can only verify the management terminal signature and the Mercker tree of the first chain system, so that the calculation amount of the second chain system is reduced.

In an exemplary embodiment, the method further comprises: the first chain system having some or all of the linkage information of a chain in the first chain as a third key, the data associated with the third key as a value, the value associated with the third key assigned to a consensus group having the same third key as the value; for example, the first chain system may perform the assignment before signing the transaction data. The consensus group validates the data associated with the third key, wherein:

the third key associated data comprises transaction data, and the verification comprises one or more of:

when the third key is used as input information of the transaction data, verifying whether output information with the same connection information as the input information exists;

when the third key is used as the input information of the transaction data, verifying whether the output information with the same connection information as the input information is used or not;

when the third key is used as the input information of the transaction data, verifying whether the transaction amount of the transaction data is correct or not;

and when the third key is used as the input information of the transaction data, verifying whether signature information (unlocking signature of the user side) of the transaction data is correct or not.

The order of the above-described verification is not limited.

An exemplary verification process: when the consensus group searches input data connected with the transaction data, namely a third key is used as the input information of the transaction data, whether output information with the same connection information as the input information exists is searched, if the output information is not searched, the connection is judged to be wrong, if the output information is searched, whether the associated connection of the input data is quoted or not is judged, namely the third key is used as the input information of the transaction data, whether the output information with the same connection information as the input information is used or not is verified, if the output information is quoted or used, the connection is judged to be wrong, if the output information is not quoted, whether the transaction amount of the transaction data is correct or not is judged, if the transaction amount is incorrect, the data is judged to be wrong, and if the signature information contained in the data (such as an unlocking signature of a user side generating the transaction data) is correct or not, if not, the data is judged to be wrong, if the data is correct, the transaction data is stored as output data (namely, the consensus group can also store the data by adopting the connection storage mode), and the associated connection of the input data is identified as being referred, namely, the associated output information is marked as being used.

In an exemplary embodiment, when the data associated with the third key is stored in a connected manner after the data associated with the third key is verified, the data associated with the third key is stored as input data or output data according to the meaning of the data represented in the first chain, wherein when the third key is used as part or all of the output information in the first chain, the data associated with the third key is stored as input data, and when the third key is used as part or all of the input information in the first chain, the data associated with the third key is stored as output data; the input data and the output data stored on the same consensus group are related according to the same connection information.

For example, if the consensus group determines that the output information of the transaction data or the control data matches the third key, the transaction data or the control data is stored as input data; and if the input information of the transaction data or the control data is judged to be matched with the third key, storing the transaction data or the control data as output data.

The first chain system comprises a plurality of common identification groups, keys corresponding to nodes in the same common identification group are the same, if the received transaction data is verified, the transaction data and the keys are stored in a connected mode, and if the received control data is verified, the key values and the control data are stored in a connected mode. If the data is output information in the chain structure, storing the data as input data; and if the data is input information in the chain structure, storing the data as output data. Input data and output data stored on the same consensus group have the same key to form a data link store.

In an exemplary embodiment, the data storage device stores data in the same manner as in the previous embodiment: when the first key is used as part or all of output information in the second chain, storing data associated with the first key as input data; when the first key is used as part or all of input information in the second chain, storing data associated with the first key as output data; the input data and the output data stored on the present data storage device are associated according to the same connection information.

In an exemplary embodiment, the data storage device verifying whether the data associated with the first key is erroneous comprises one or more of:

a verification 31 verifying the integrity of said second chain;

a verification 32, verifying whether the data is data on the second chain;

verifying 33, when the first key is used as input information of the ledger data in the second chain, whether output information with the same connection information as the input information exists is verified;

verifying 34 that when the first key is used as input information of the ledger data in the second chain, output information having the same connection information as the input information is used;

and verifying 35, when the first key is used as input information of the book data in the second chain and the data associated with the first key contains a transaction amount, verifying whether the transaction amount is correct.

And verifying 36, when the first key is used as input information of the ledger data in the second chain, and when the data associated with the first key contains signature information, verifying whether the signature information is correct.

The verifications 32-36 in this embodiment are similar to the verifications 11-15 in the previous embodiments, except that the verification object in this embodiment is a second chain.

In an exemplary embodiment, the method further comprises: the first chain system arranges sequence numbers for the account book data in sequence, and the block head of the block data corresponding to the account book data comprises the data volume of the accumulated account book. The second chain system includes, in a block header of block data of a second chain, an accumulated book data amount in the block data.

For example, when the ledger data is written into the block data of the first chain, the sequence number is arranged for the transaction data according to the first sequence, the sequence number is arranged for the control data according to the second sequence, and the sequence number of the last transaction data and/or the sequence number of the last control data is written into the block head of the block data, so that the block head data includes the accumulated transaction data amount and the accumulated control data amount. For example, after each consensus group receives the accumulated transaction data volume sent by the previous consensus group, arranging a serial number for the transaction data to be linked in the consensus group on the basis of the accumulated transaction data volume, recalculating a new accumulated transaction data volume and sending the new accumulated transaction data volume to the next consensus group; after the common identification group arranges a serial number for the transaction data to be linked, the common identification group requests to sign the transaction data after arranging the serial number, the signed transaction data is written into a first link, and the block head of the block where the transaction data is located contains the accumulated transaction data amount accumulated with the transaction data. The accumulated ledger data volume of the first chain includes a first accumulated transaction data volume and/or a first accumulated control data volume, and the accumulated ledger data volume of the second chain includes a second accumulated transaction data volume and/or a second accumulated control data volume. The second chain is asynchronous and homomorphic with the first chain, and as the block head of the first chain comprises the accumulated transaction data volume and the accumulated control data volume, the block head of the second chain also comprises the corresponding accumulated transaction data volume and the corresponding accumulated control data volume. The block header data carries the data volume of the accumulated account book, so that the data storage device can carry out integrity verification on the second chain according to the data volume of the accumulated account book.

The data storage device may verify the integrity of the chain structure in the following manner: the data storage device synchronizes a block header of the second chain, and verifies the integrity of the second chain according to the accumulated book data amount (accumulated transaction data amount and accumulated control data amount) in the block header. When integrity is verified, verification is performed by taking the number address as a key. For example, the device calculates all transaction data number addresses of the current block according to the accumulated transaction data amount in the current block head data and the accumulated transaction data amount in the previous block head data, calculates all control data number addresses of the current block according to the accumulated control data amount in the current block head data and the accumulated transaction data amount in the previous block head data, judges that each transaction data number address is matched with the network identifier of the distributed hash table of the node, searches the transaction data corresponding to the transaction data number address, judges that each control data number address is matched with the network identifier of the distributed hash table of the node, searches the control data corresponding to the control data number address if each control data number address is matched with the network identifier of the distributed hash table of the node, if the control data number address is found, the integrity verification is passed, and if the control data number address is not found, the integrity verification fails.

Integrity verification is verification by the data storage device storing the numbered addresses, which may be verified at the time of storage. Since the DHT is characterized by storing data on the node corresponding to the key to provide key retrieval, it is necessary to store the key and value. Here, since the numbered address is a serial number and is known, the key is known, i.e., it is known on which nodes the key should be stored. Therefore, the node only needs to synchronize the block header data to know which keys with the serial numbers and addresses should be stored by the node, if the node judges that the node needs to store the data of the keys but does not store the data, the data is retrieved at a third layer (a user side) or a second layer (a class public chain), and then integrity verification is carried out, so that the integrity of the data can be verified through the node self verification. Since the node can know which numbered addresses are available by the accumulated number of block headers.

In addition to integrity verification, random verification may also be performed. Random verification can be any node, not only the node storing the number address, but also can randomly select some number addresses for verification without storage. And during random verification, acquiring the transaction data corresponding to the random number address according to the random number address, and verifying by taking the input address of the transaction data as a key. Similar in nature to integrity verification.

In an exemplary embodiment, the data storage device verifies the second-chain block header data according to the first-chain block header data, including verifying whether the accumulated ledger data amount is correct. The data storage device may verify whether the accumulated transaction amount and the accumulated control amount of the first chain block head are equal to the accumulated transaction amount and the accumulated control amount of the second chain block head, and if so, the data storage device may indicate that the amounts are correct and the first chain block head is the last block head data in the second chain block head generation time slice.

In an exemplary embodiment, the data storage device verifies whether the data is on-chain data by carrying a root hash value of the merck tree in the second-chain chunk header data. The second chain system writes one or more consecutive block data of the first chain to block data of a second chain, including: and the second chain system recombines one or more continuous block data of the first chain according to the sequence of the transaction data sequence number and the sequence of the control data sequence number to respectively generate a Mercker tree root hash value, and the generated block head of the second chain contains the Mercker tree root hash value.

The data storage device verifying whether the data is data on the second chain, including: and the data storage device synchronizes the block head of the second chain, and verifies whether the data is the data on the second chain according to the root hash value of the Mercker tree in the block head and the authentication path corresponding to the data.

In an exemplary embodiment, in addition to the data storage device capable of performing data verification, in order to improve security, a data verification device is added for performing data verification, i.e. the data verification device in the foregoing embodiment. The chain structure system further comprises: a data verification device, the method further comprising: the data verification device takes part or all of the connection information of the chain in the chain structure as a second key, acquires data stored on the data storage device and associated with the second key from the data storage device, and verifies whether the data in the second chain has errors according to the acquired data. For example, the data verification apparatus may synchronize a block header of the second chain, generate a number address using the accumulated book data amount in the block header (generate a control data number address using the accumulated control data amount, generate a transaction data number address using the accumulated transaction data amount), and acquire data associated with the second key stored on the data storage apparatus from the data storage apparatus based on part or all of connection information of the number address acquisition chain as a second key. The control data numbering address is used as a key to acquire control data corresponding to the control data numbering address, and the control data numbering address can also comprise a Mercker tree authentication path of the control data; the transaction data number address is used as a key to acquire the transaction data corresponding to the transaction data number address, and the transaction data number address can also comprise a Mercker tree authentication path of the transaction data. For example, a preset address of token issuing data (abbreviated as token issuing address), a preset address of token reclaiming data (abbreviated as token reclaiming address), or a preset address of consensus reward data (abbreviated as reward address) of control data may be used as a key, and the key is used to acquire data associated with the key stored thereon from the data storage device; the transaction address of the transaction data may be used as a key with which to retrieve data stored thereon associated with the key from the data storage device.

For example, the data verification device obtains from the data storage device data stored on the data storage device associated with the second key, including one or more of: data associated with the second key as part or all of the output information in the chain structure, a merkel tree authentication path, additional verification data, wherein the second key is part or all of the input information in the chain structure; the data verification means synchronizes the chunk headers in the second chain, in conjunction with the chunk headers and the data associated with the second key retrieved from the data storage means, performing one or more of the following verifications:

verifying whether the data associated with the second key obtained from the data storage device is data on the second chain;

when the second key is used as input information of the acquired data, verifying whether output information with the same connection information as the input information exists or not;

when the second key is used as input information of the acquired data, verifying whether output information having the same connection information as the input information is used;

when the second key is used as input information of the acquired data and the acquired data comprises a transaction amount, verifying whether the transaction amount is correct;

and when the second key is used as the input information of the acquired data and the acquired data contains signature information, verifying whether the signature information is correct.

The description of the verification part is described in the foregoing embodiments, and is not repeated here.

In an exemplary embodiment, the first chain is a private chain or a federation chain, the method further comprising: the first chain system issues to the user one or more of the following keys: a management address master key, a transaction address master key, a confidential transaction master key, and a symmetric encryption master key, wherein:

the management address master key is used for generating the next management address of the user with the current first generation parameter, and all the management addresses of the user form a logic chain;

the transaction address master key is used for generating a next transaction receiving address of the user with the current second generation parameter, and all transaction receiving addresses of the user form a logic chain;

the confidential transaction master key is used for generating a working key of the current encrypted and decrypted ciphertext transaction amount together with the current third generation parameter;

the symmetric encryption master key is used for generating a symmetric encryption working key of next encryption and decryption management data of the user together with the current fourth generation parameter, and the symmetric encryption master key can also be used for generating a symmetric encryption working key of other data.

For example, the first chain system generates a current management address of a user by using a master key of a management address issued for the user and a generation parameter in last management data of the user, and writes a generation parameter for generating a next management address of the user in the current management data. The first chain system can use a symmetric encryption master key issued for a user and a generation parameter in the last management data of the user to generate a symmetric encryption working key to encrypt the current management data of the user. The user can use the same key generation mode to generate a symmetric encryption working key to decrypt the current management data of the user.

In an exemplary embodiment, the method further comprises: the first chain system includes a value of a current consensus public key set mapping in a block header of a first chain; and the data storage device adopts the Mercker tree certification or the accumulator certification according to the mapping value of the common public key set in the first chain block header to verify whether the common public key in the second chain block header is valid. In addition to the above verification, the data storage device may also verify whether the common public key in the header of the second chain block is valid by using a merkel tree verification or an accumulator verification according to the mapping value of the common public key set in the header of the first chain block.

An exemplary embodiment herein also provides a chain structure system, as shown in fig. 8, including: a first chain system 81, a second chain system 82, and a data storage device 83, wherein:

the first chain system 81 is configured to write signed account book data into block data of the first chain after signing the account book data;

the second chain system 82 is configured to, after verifying the block data of the first chain, write one or more consecutive block data of the first chain into the block data of the second chain;

the data storage device 83 is configured to use part or all of the connection information in the second chain as a first key, use data associated with the first key as a value, verify whether the data associated with the first key has an error, store the data as input data or output data after verifying that the data associated with the first key has no error, and associate the input data and the output data stored in the same data storage device according to the same connection information.

In an exemplary embodiment, the first chain system further comprises a consensus group;

the first chain system is further configured to treat some or all of the linking information in a chain in the first chain as a third key, the third key associated data as a value, assign the value associated with the third key to a consensus group having the same third key as the value, the third key associated data comprising transaction data;

the consensus group is used for verifying the data associated with the third key, and comprises one or more of the following verifications:

and when the third key is used as the input information of the transaction data, verifying whether the signature information of the transaction data is correct or not.

In an exemplary embodiment, the consensus group is further configured to store the data associated with the third key as input data or output data after verifying the data associated with the third key, where the data associated with the third key is stored as input data when the third key is used as part or all of the output information in the first chain, and the data associated with the third key is stored as output data when the third key is used as part or all of the input information in the first chain; the input data and the output data stored on the same consensus group are related according to the same connection information.

In an exemplary embodiment, the first chain system is further configured to arrange sequence numbers for the ledger data in sequence, and a block header of block data corresponding to the ledger data includes an accumulated ledger data amount; the second chain system is also used for including the accumulated account book data amount in the block data in the block head of the block data of the second chain.

In an exemplary embodiment, the data storage device 83 may be, for example, a data storage device as shown in fig. 2, which stores the data as input data or output data, including: when the first key is used as part or all of the output information in the second chain, storing the data associated with the first key as input data; when the first key is used as part or all of input information in the second chain, storing data associated with the first key as output data; the input data and the output data stored on the present data storage device are associated according to the same connection information.

In an exemplary embodiment, the data storage device verifies whether the data associated with the first key is erroneous, including one or more of:

verifying the integrity of the second chain;

verifying whether the data is data on the second chain;

when the first key is used as input information of the account book data in the second chain, verifying whether output information with the same connection information as the input information exists or not;

when the first key is used as input information of the account book data in the second chain, verifying whether output information with the same connection information as the input information is used or not;

when the first key is used as input information of the book data in the second chain and the data associated with the first key contains a transaction amount, verifying whether the transaction amount is correct;

and when the first key is used as input information of the ledger data in the second chain and the data associated with the first key contains signature information, verifying whether the signature information is correct.

In an exemplary embodiment, the data storage device verifies the integrity of the chain structure in the following manner: and the data storage device synchronizes the block head of the second chain, generates a serial number address by using the data volume of the accumulated account book in the block head, and verifies the integrity of the second chain according to the serial number address.

In an exemplary embodiment, the data storage device is further configured to verify whether the accumulated ledger data amount in the second-chain block header data is correct according to the first-chain block header data.

In an exemplary embodiment, the first chain is a private chain or a federation chain, and the first chain system is further configured to issue to a user one or more of the following keys: a management address master key, a transaction address master key, a confidential transaction master key, and a symmetric encryption master key.

In an exemplary embodiment, the system may further include a data verification device, which may be, for example, the data verification device shown in fig. 6. The data verification device is used for taking part or all of the connection information of the chain in the chain structure as a second key, acquiring data stored on the data storage device and associated with the second key from the data storage device, and verifying whether the data in the second chain has errors according to the acquired data.

In an exemplary embodiment, the first chain system is further configured to include a value of a current common public key set mapping in a block header of the first chain, so that the data storage device or the data verification device verifies whether the common public key in the block header of the second chain is valid according to the merkel tree certification or the accumulator certification by using the mapping value of the common public key set in the block header of the first chain.

In an exemplary embodiment, the first chain system is further configured to generate a current management address of the user using a master key of a management address issued for the user and a generation parameter in last management data of the user, and write the generation parameter for generating a next management address of the user in the current management data.

The functions and effects of the first chain system, the second chain system, the data storage device and the data verification device in the chain structure system are described in the method, and are not described herein again.

The following describes the key (key, or key value) mentioned herein:

the first key value is a key value used when the data storage device performs connection storage, the second key value is a key value used when the data verification device retrieves data from the data storage device, and the third key value is a key value used when the common identification group is queried in the first chain system and is used when the common identification group performs connection storage. The first key value, the second key value and the third key value may be different according to the corresponding chain structure, but all use part or all of the connection information in the chain structure. For example, one or more of the following types may be used: the transaction address of the transaction data, the preset address of token issuing data (called token issuing address for short), the preset address of token recovery data (called token recovery address for short) of the control data and the preset address of consensus reward data (called reward address for short). The data associated with the key value is corresponding transaction data or control data, and may further include a merkel tree authentication path (authentication path for short) corresponding to the data. The key value can be stored in the management terminal or the client terminal. Taking the chained architecture system in the above embodiment as an example, the chained architecture system includes a first chained architecture system, a second chained architecture system, and a plurality of user end (or client end) nodes, where the user end nodes may include user end nodes serving as data storage devices, and may also include user end nodes serving as data verification devices. For the user end node, the data associated with the key value also comprises a corresponding merkel tree authentication path besides the transaction data or the control data, and the authentication path is the merkel tree authentication path of the transaction data or the control data in the second chain.

The disclosure also provides a class of key values (fourth key values), which can be used for verifying the integrity of the book data by the data storage device and also can be used for inquiring the key values by the data verification device. The fourth key value includes one or more of the following information: the numbering address of the transaction data (generated from the transaction data number) and the numbering address of the control data (generated from the control data number). May be stored at the client. The data associated with the fourth key value is corresponding transaction data or control data, and may further include a corresponding merkel tree authentication path. In the above example of the chain structure system, the authentication path associated with the fourth key value is a merkel tree authentication path of the transaction data or control data in the second chain.

In addition, the present disclosure also provides a class of key values (fifth key value), which may be used to query or retrieve an account data chain, where the account data chain of a user includes a first account data chain composed of the management data of the user and a second account data chain composed of the received transaction data of the user. The management address for storing the management data is in a hidden chain structure, so that a first account data chain is formed. The transaction address for storing transaction data is also in an implicit chain structure, thereby forming a second account data chain. The fifth key value includes a management address for inquiring the management data or a transaction address for inquiring the transaction data.

An address as a key value herein may be an address or a hash value of an address.

The following describes the merkel tree and block chain structure. The merkel tree is a hashed binary tree, which is a data structure used for rapid generalization and checking of large-scale data integrity. Leaf nodes of the Mercker tree store hash values of unit data of the data set, hash values of father nodes are obtained among the nodes through hash operation, and the hash values of root nodes are finally formed through layer-by-layer calculation. The leaf node may verify whether the leaf node belongs to an element in the data set according to the root hash value and the corresponding authentication path.

It can be seen that, if the number of leaf nodes (i.e. the number of data set elements) of the merkel tree is known, and the sequence number (i.e. the position) where the leaf node is located is also known, the height and the direction of the authentication path corresponding to the leaf node are fixed and known, where the direction refers to the left-right direction of the path. Therefore, the element is represented to be ordered and cannot be replaced by different authentication paths and height and direction, and the data security can be enhanced.

The number of leaf nodes of the Merck tree is at most 2^ n of the tree depth, and even if a large amount of data is contained, a certain leaf node can be quickly verified through a fixed path. For example, a tree depth of 30, a maximum of 1073741824 leaf nodes can be included. If an average of 10 minutes produces a block of data, 1789569 transactions per second may be involved. However, the data of a certain leaf node is verified, only 30 hash values are needed to complete the verification, and if each hash value is 32 bytes, 960 bytes are needed. If each client needs to store 10 data blocks, each client needs to store 525600 data blocks in one year, each block is calculated according to the tree depth of 30, the size of the authentication path needing to be stored is 481MB, and if the size of each data block is 1KB, the size of the total data volume needing to be stored is 994 MB. However, such data is not required to be saved, and the client can clear the previous data after a certain period of time, so that the data amount required to be saved is always kept in a controllable range and is acceptable even for the mobile device.

The block chain is composed of block header data and block volume data generated in time slices of consecutive slices. Wherein the latter block header contains the hash value of the former block header, thereby forming a chain structure of reverse connection. And the block head also contains the root hash value of the Merck tree corresponding to the data of the block body, so that the data of the block body can be uniquely mapped. The block volume data includes actual account book data. And because the block head uniquely maps the block data, that is, the consistency of the block head can map the consistency of the block data. Therefore, only the block header data needs to be synchronized, whether the account data is in the block of the chain can be verified according to the account data and the corresponding authentication path, and how many confirmations are passed, that is, the SPV simple payment verification.

The underlying data structure is described below. The data of the account book is divided into a transaction data set and a control data set, wherein the transaction data set comprises actual transaction data; the control data set includes, but is not limited to, one or more of the following types of data: management data of users, issued data of tokens, recycled data of tokens and notice data issued by a system. The transaction data is mainly generated by the client, comprises an unlocking signature of the client, the management terminal verifies the uplink, and when the uplink is carried out, the managed terminal is endowed with a sequentially arranged (such as increasing) unique serial number, and the serial number and the transaction data pass through an endorsement signature of the management terminal. The control data is generated by the management side of the chain structure system (such as the first chain system), and is generated by giving a unique serial number which is sequentially arranged (such as increasing) and is signed by the management side. The root hash value of the Mercker tree generated by the transaction data set and the control data set is recorded in the block header. The block header also contains the last transaction data number and the last control data number in the corresponding block data, and the numbers are sequentially increased and are also equal to the block header containing all the current accumulated transaction data amount and the accumulated control data amount.

The third layer of clients (including data storage devices) use a structured peer-to-peer network, such as Kademlia network protocol. Each user end (node) only needs to synchronize block head data, and account book data in the block bodies can be stored by nodes on the whole network in a scattered mode according to a Distributed Hash Table (DHT), and each node stores part of the account book data and corresponding authentication paths. Because each transaction data and control data has an incremental unique serial number, and the block header contains the last serial number, which is equivalent to the current accumulated transaction data amount and the accumulated control data amount, the block where each transaction data and control data is located can be quickly found, and the data can be verified by using the Mercker tree in combination with the authentication path. And because the leaf node number of the block's merkel tree and the sequence number (i.e. position) corresponding to the data are known, the height and direction of the authentication path are fixed and known, and cannot be replaced by different authentication paths and height and direction, thereby enhancing the security of the data.

The user searches the account data of the user through the account data chain. And the third party user and the supervisor can also acquire the account data of the user through the account data chain after the master key of the authorized user. The account data chain is a forward-connected logic chain structure formed by obtaining an intermediate value K through a user master key and a current generation parameter and obtaining the address of the next data through other operations by the K. The account data link enables the user to retrieve under private circumstances from the user master key. One user has two account data chains, wherein one account data chain, namely the first account data chain, is composed of management data of the user, and the user searches through a master key of a management address. The first chain system generates a current management address of a user by using a master key of the management address issued to the user and generation parameters in last management data of the user, the current management address is contained in the current management data, and the generation parameters for generating a next management address of the user are written in the current management data, so that all the management addresses of the user form a logical chain. The management address of the user management data in the control data may be used as a query key value of the first account data chain, and the data associated with the key value is the user management data corresponding to the management address.

The initial management address generation parameter may be a preset value, such as a user ID. The management address is disposable and unique, so that the aim of protecting the identity privacy of the user can be fulfilled. And the first chain system generates a symmetric encryption working key by using a symmetric encryption master key issued for a user and a generation parameter in the last management data of the user to encrypt the current management data of the user. The user can use the same key generation mode to generate a symmetric encryption working key to decrypt the current management data of the user.

The other account data link, the second account data link, is comprised of the received transaction data of the user, which is retrieved by the transaction address master key. After the received transaction data is linked up, all the received transaction data of the same transaction receiving end form a logical chain structure. The logical chain is implicit in the generated ledger data.

The transaction data is submitted to a management end of the first chain system from the user end, and the management end verifies the transaction data. The transaction data comprises a transaction address of a transaction receiving end and address parameters generated during the transaction, the transaction address is generated by using the address parameters generated when the transaction receiving end receives the transaction last time, and the address parameters generated during the transaction are used for generating the transaction address of the transaction receiving end receiving the transaction next time. The verification of the management end on the transaction data mainly comprises verification of validity, such as verification of validity of a user state, validity of an unlocking script, validity of a transaction amount, and whether a transaction address is a valid address. And after the transaction data passes the verification, the management terminal carries out endorsement signature on the transaction data, and the endorsement signed transaction data is written into the block data of the first chain. After the transaction data is linked up, all the received transaction data of the same transaction receiving end form a logical chain structure. The logical chain is implicit in the generated ledger data.

When the user is used as a transaction receiving end to perform transaction, all received transaction data of the user form a logic chain, namely a second account data chain. When the managed end of the same user issues a new key for generating the transaction address, the managed end will re-generate an initial address parameter for the user, and generate a new initial transaction address from the re-generated initial address parameter, where the re-generated initial address parameter is associated with the issued new key. Thereafter, when the user performs a transaction as a transaction receiving end, all received transaction data of the user form a new second account data chain. It can be seen that the received transaction data at the same transaction receiver may have one or more logical chain structures. The newly generated initial address parameter is stored in the management data of the user each time, and the user can search the second account data chain according to the initial address parameter in the management data.

If there are multiple concurrent transactions for the same transaction receiving end, that is, there are multiple transaction data containing the same transaction address, the transaction data containing the same transaction address are brother nodes of each other in the second account data chain.

The transaction address generated by using the address parameter in the last received transaction and the address parameter used for generating the next transaction address are contained in the transaction data, so that the received transaction data of the same user side forms a logic chain or has a brother node, all the received transaction data of the user side can be quickly retrieved, and the transmitted transaction data refers to the received transaction data, so that all the transaction data can be quickly acquired. The transaction address is disposable and unique to different users, so that the purpose of protecting the identity privacy of the users can be achieved.

Because the transaction address can be used as the first key value, the transaction address connection information of the second account data chain is hidden in the key value of the connection storage, and the user can retrieve and acquire the second account data chain of the user by using the transaction address as the second key value. The transaction address as the second key value may be the current received transaction address of the user, and may be generated by the transaction address master key of the user, the generation parameter in the last received transaction data of the user, and the signature public key of the user.

The keys of the user side are divided into two types, one is a signature key of the user side, and the other is a user master key issued by the management side. The signing key may be generated and managed locally at the user end or may be hosted by a trusted third party. If real-name authentication is required, the public key of the signature key needs to be subjected to identity certificate issuing by a trusted CA (certificate Authority) or subjected to eID authentication. The user master key issued by the management end comprises a management address master key, a transaction address master key, a secret transaction master key and a symmetric encryption master key. Wherein the management address master key is used to generate an address of a first account data chain consisting of management data of the user; the transaction address master key is used for generating an address of a second account data chain consisting of the received transaction data of the user; the secret transaction master key is used for generating a working key in secret transaction, and can be used for protecting blinding factors so that a user can decrypt the amount of ciphertext transaction; the symmetric encryption master key is used to generate a symmetric encryption working key that can be used to protect the user's administrative data and the user's other data.

The user master key and the current generation parameter are operated through a first one-way irreversible function to obtain an intermediate value K, wherein the management address master key and the first generation parameter generate the intermediate value K1, the transaction address master key and the second generation parameter generate the intermediate value K2, the confidential transaction master key and the third generation parameter generate the intermediate value K3, and the symmetric encryption master key and the fourth generation parameter generate the intermediate value K4. The generation parameter may be different in each transaction data and the initial generation parameter may be a user ID. The address of the next management data of the user can be obtained by K1 through a second one-way irreversible function operation; a new public key is obtained by the operation of the K2 and the user's signature public key, for example, scalar multiplication on an elliptic curve can be used, and then the new public key is used to obtain the address of the next receiving transaction of the user through a third one-way irreversible function operation, and the private key corresponding to the new public key can be obtained by the operation of the K2 and the user's signature private key, for example, multiplication in a finite field; obtaining a symmetric encryption working key of the next management data through the fourth one-way irreversible function operation by the K3; the working key in the current confidential transaction is obtained by the K4 through a fifth one-way irreversible function operation, and can be used for protecting the blinding factor. The user master key and the current generation parameter can also obtain a plurality of different intermediate values through a plurality of one-way irreversible function operations, then the intermediate values are operated one-to-one with a plurality of signature public keys to obtain a plurality of new public keys, and then the new public keys generate a multiple signature address of the next receiving transaction.

The one-way non-reversible function described above and herein may be a hash function or a combination of hash functions, which are described below.

Different addresses or keys can be obtained through the user master key and different generation parameters, and the safety of data can be enhanced. Even if the quantum computation cracks the private key on the elliptic curve, the public key of the private key is obtained by the operation of the user signature public key and the intermediate value K, namely the intermediate value K needs to be cracked to associate the private key and the user signature public key, because any user signature public key can find a K' value to be operated to obtain the public key, which user signature public key is operated to obtain cannot be found, and the signature private key is also obtained in the same way. Or the symmetric encryption working key is cracked by quantum computation, but the symmetric encryption working key is obtained by K operation of an intermediate value, and the K value in each datum is different, so that the association between the data cannot be found. Therefore, by combining the user master key and different generation parameters with the hash function which can resist quantum computing cracking, the association between the data or the key and the user cannot be found after the data or the key is cracked, and the association between the data cannot be found, so that the user privacy can not be leaked. Therefore, the system can upgrade the quantum computation resistant cryptographic algorithm with safety guarantee in the future, and the privacy of the user cannot be revealed because the previously disclosed data is cracked.

The transaction data in the present system uses the UTXO model so each transaction data contains a reference to the unspent output as input and a new unspent output. The way of referencing may be an address of the unspent output plus a referenced transaction Identification (ID), where the transaction ID is a hash value of the referenced transaction data. However, in the present system, each transaction data has a unique transaction data number, so the transaction data number may be used instead of the referenced transaction ID, and the referenced unspent output can be uniquely confirmed by adding the transaction data number to the output address. The following description uses the transaction data number as an example. The new, non-spent output address is then the new address generated based on the generation parameters of the last received transaction for the corresponding user, the user's transaction address master key, and the user's signed public key. The transaction amount is protected by a confidential transaction realized by the addition homomorphic commitment or the peterson commitment, so that any user can verify that the input sum of the transaction amount is equal to the output sum under the condition of ciphertext, and the verification of the transaction amount is not less than zero and cannot overflow by combining with range certification, namely the validity of the transaction amount is verified. The blinding factor in the confidential transaction is the work key generated by the generation parameter of the current transaction data and the confidential transaction main key of the user for encryption protection, so that the user can decrypt the amount of the ciphertext transaction.

The structured peer-to-peer network of the user side dispersedly stores the corresponding values in the nodes of the network according to the indexed key through a Distributed Hash Table (DHT), and the indexed key can be used for quickly retrieving the corresponding values in the network. In this embodiment, the transaction address, the management address, the preset address issued or recycled by token, and the like in the system are all clearly distinguished by address prefixes, and then the transaction data number and the control data number are also extended in a similar address manner (such as 0 complementing) and clearly distinguished by prefixes (hereinafter referred to as number addresses). For example, the prefix of the control data number address is represented by E, and the control data with the sequence number of 1 is represented by E001 as the control data number address; the transaction data number address prefix is denoted by F, and the transaction data with the number 1 is denoted by F001 as the transaction data number address. The hash values of the addresses may be used as indexed keys, for example, if some account book data has one or more addresses, the hash value of each address is used as an indexed key, and the corresponding account book data and authentication path data are stored as values in the structured peer-to-peer network. Any user can search corresponding account book data and an authentication path through the key (the address), and the data can be verified by using the Merckel tree by combining the block header data and finding the block where the account book data is located according to the number. For simplicity of description, hereinafter, the address is used as the key of the index, which is equivalent to the key using the hash value of the address as the index. And different from the key-value of the conventional DHT, the system allows a plurality of values to have the same key value, and specifies the storage and retrieval modes of different values of the same key, namely the connection storage (or pair storage) mode described below.

The following describes a way to convert a chained structure into node verification by connecting storage structures.

Taking the chain of block headers as an example, the block header is known to connect (contain) the hash value of the previous block header. Assuming that the first block header H1 contains a value of 0000, the hash value of H1 is hash (00H 1); the hash value contained in the second chunk header H2 is hash (00H1), and the hash value of H2 is hash (00H 2); the hash value contained in the third chunk header H3 is hash (00H2), and the hash value of H3 is hash (00H 3). The hash value of the block head is used as an index key, and the hash value of the previous block head is also used as the index key. The node storing the hash (00H1) will store H1 and H2; the node storing the hash (00H2), would store H2 and H3; by analogy, each node stores a pair of data on the chain, and the index key is all or part of the information connected by the data pair. For example, for the connection, the transaction ID and the output index are part of the information if the transaction ID is used as the key; if the block header is connected with the hash value of the previous block header, the hash value is used as a key, and the key is the whole information. The hash value is explained below as a key. The hash value of H1 is hash (00H1), the hash value of H2 is hash (00H1), so the concatenated storage needs to distinguish between input data (hereinafter referred to as input) and output data (hereinafter referred to as output), for example, the key (hash (00H1)) corresponding to H1 input here is the hash value of data (which can be regarded as the output address), and the key corresponding to H2 output is the hash value of data concatenation (which can be regarded as the input address). The method can be summarized as that the key corresponds to the output address, and the key is the input data which is stored in a connected mode; and if the key corresponds to the input address, the key is the output data stored in the connection. If the chain is growing all the time, the current last data is assumed to be Hn, so that the node storing the hash (00Hn) only stores the input data Hn, and the output data is empty; when the chain is newly added with H [ n +1], the node contains the output data H [ n +1 ]; the node storing the hash (00H [ n +1]) also only stores the input data H [ n +1], and the output data is null. The node storing 0000 will only store H1, and since 0000 is the input address to which H1 is connected, H1 is the output data of this node, while the input data is null. But since 0000 is a special start data, i.e. can be identified as start connection store, the start connection store can use a special 0000 data (or null data) as input.

The block head chain has the possibility of branching and connecting a tertiary block head, namely the block head chain can have a plurality of inputs and a plurality of outputs. Since the hash value of the tertiary chunk header is different from the hash value of the parent chunk header, and the hash value is stored at a different node, the concatenated storage of the chunk header chain does not have multiple input data, but the forking causes the associated node to have multiple output data. According to the difference of keys selected as the connection, if the key is the hash value of the data, because the hash value has uniqueness (no collision is considered), the connection only stores one input data; if the address is the same address, there may be a plurality of the same addresses according to the difference of the addresses selected as the key, and there may be a plurality of input data in the connection storage at this time.

If a node has only output data and no input data (except for the special initial connection store), then the connection of the chain is incorrect; if a node has only input data and no output data, the input data must be stored contiguously in the last node and is output data. The connection storage means that the node stores one or more input data and one or more corresponding output data, and the node can verify whether the input data and the output data are correct; there may also be no output data, meaning that the connection for the input data is unused or not spent, i.e. zero output data. Wherein verifying the correctness of the input-output data comprises verifying whether the connection of the one or more inputs and the corresponding one or more outputs is correct. If the output data contains the transaction amount, whether the transaction amount of the output data is correct or not needs to be verified; if the output data contains the signature information, whether the signature information of the output data is valid can be verified. For example, in the UTXO structure, only the output amount is input, and the input is the referenced address, so that the transaction amount of the output data is verified, wherein the part of the input amount can be derived from the output amount of the input data, that is, the acquisition of part of the data can be reduced. The chain structure is also converted into a connection store for the node and the node verifies that the connection of the chain is correct. And the link storage mode also enables the chain to have the capability of bidirectional retrieval, such as the block head chain query hash (00H2), the hash value hash (00H1) of the previous block head contained in H2 and the hash value hash (00H3) of H3 can be obtained. And the data retriever can also judge whether the data is input data or output data through the retrieved key and the data returned by the node, thereby judging whether the connection of the chain is correct.

In combination with the block chain, the node performing the connection storage may also verify whether the data stored by the connection is data on the chain. The UTXO data has a mercker tree authentication path and the UTXO is also of a chain structure, which is described below by way of example as UTXO. Because the UTXO reference mode used by the system is address plus transaction data number, and key taking address as index. Because of the existence of concurrent transactions, a plurality of same output addresses can be used, but transaction data numbers are different, so that the system can have a plurality of inputs and a plurality of outputs according to the connection storage of the transaction addresses, but the same address refers to different transaction data numbers, namely the transaction data numbers are referred to one by one according to the addresses and the transaction data numbers, so that the transaction data numbers are not double-colored. Such as transaction data T1, in which the input addresses are Ad1 and Ad2 and the output addresses are Bd1 and Bd 2; the transaction data T2 has input addresses Bd1 and Ed1, and output addresses Cd1 and Cd 2. From the above, for the node storing Bd1, as shown in FIG. 9, T1 and T2 are stored, where T1 is the input data stored in connection (because Bd1 is the output address of T1) and T2 is the output data stored in connection (because Bd1 is the input address of T2). For nodes storing Ad1 and Ad2, the T1 data is output data stored in a connection; for nodes storing Cd1 and Cd2, the T2 data is the input data to the concatenated store. Each node can verify whether the input and the output of the self-connected storage data are correct, for example, a node storing Bd1 can verify whether input data T1 exists or not, whether double flowers exist in output data T2 or not, whether the transaction amount of the output data T2 is correct or not, but the input of T2 also needs to depend on Ed1, so that the node storing Bd1 needs to obtain Ed1 as output data to be verified, and whether Ed1 as output data is T3 or not, so that the node storing Bd1 stores T3 and corresponding authentication paths as additional verification data, and verifies whether the input amount of Bd1 and Ed1 is equal to the output amount of Cd1 and Cd2, namely whether Bd1+ Ed1 is equal to Cd1+ Cd2 or not. Similarly, the node storing Ed1 stores the input data T3 and the output data T2, and additionally verifies the data T1, and verifies whether the input and output data are correct.

The token issuing and recycling of the system, that is, the initial transaction data and the end transaction data are also stored in a connected manner, and the relevant nodes can also verify whether the input and the output of the connected and stored data are correct. Therefore, the UTXO chain is converted into a connection storage structure of nodes, each node verifies whether the connection storage is correct, such as whether only output is provided and no input is provided (the initial connection storage also has a special input), whether the input data has a plurality of identical outputs (i.e., double flowers), and whether the input and output of the connection storage data are correct, and each transaction data can be verified as data on the chain through the mercker tree, so that the correctness of the entire UTXO ledger can be verified through the distributed nodes. According to the above, the user can also obtain the bidirectional searching capability through searching the address in the network, and can judge whether the connection of the chain is correct or not according to the input or output of the data returned by the node, and can also judge whether the output is not cost according to the returned data. For example, user C retrieves Ed1 in the network, the node will return the data T1, T2, and T3 associated with Ed1 and the corresponding authentication path to user C. User C is the output address of T3 according to Ed1, so T3 is the input data; according to Ed1 being the input address of T2, so T2 is the output data; ed1 is not the address of T1, so T1 is the additional verification data. The authentication path verification T1, T2, and T3 according to the related data are all data on the chain, and it can be verified whether the input amounts of Bd1 and Ed1 are equal to the output amounts of Cd1 and Cd2, so that the correctness of the input and output data can be verified. If the node only returns T2 data, only the output is output and no input is input, and the link is judged to be a link error; if the node returns only T3 data, then Ed1, representing T3, is not spent.

The system token issues or recycles the default address and first needs to be published in the clear in the control data set. For example, the issued address is a001, and the collected address is B001. Because token issuing or recycling information published in the control data set contains the preset address information, a node storing A001 in the network can store the information published in the control data set and transaction data which is input and quoted by A001, namely initial transaction data; the node storing B001 in the network stores information issued in the control data set and transaction data that B001 outputs, that is, end transaction data. Therefore, the preset address issued or recovered by the system token is also in accordance with the characteristics of connection and storage, only preset input or output data is used, for example, plaintext issuing or recovery information in a control data set instead of transaction data, and the node can also verify whether the input or output data is correct.

The exemplary system described above uses homogeneous tokens, and if non-homogeneous tokens are used, they may also conform to the characteristics of the connection store and may achieve the purpose of verifying the UTXO chain.

The distributed nodes can verify whether the connection of the chain is correct or not through the connection storage, and can also verify whether the length of the chain is correct or not. In order to verify whether the length of the chain is correct, according to the accumulated transaction data volume and the accumulated control data volume contained in the block header, the node can calculate all the number addresses contained in the block, and then the node can inquire whether the network identifier of the node matches the key according to each number address, if the corresponding number address key is stored by the node and does not have corresponding data, the data of the key is inquired through the network (for example, the data is firstly searched by the user end node, and if the number address is not searched on the second layer chain as the key, the integrity of the chain is wrong if the number address is not found). If the account book data corresponding to the key is found and the data is verified, the data of the serial number address is correct, if the data is transaction data, the transaction data is stored in a connected mode through the transaction address according to the knowledge, and the node can inquire and verify according to the input reference address of the transaction. This allows the integrity of the chain to be verified by the numbered addresses and the unspent output to be queried over the network.

The ledger data of the system consists of two parts, namely a transaction data set and a control data set. And each control data has a unique control data number, the number is sequentially increased, and the integrity of the control data can be verified through the number address according to the above. This carries a certain risk if an address is only verified by a specific node, i.e. the node verifying a certain transaction data or control data is fixed and known, so in an exemplary embodiment the system may choose to increase the way the user chooses randomly for verification. Since the block header contains all the accumulated transaction amount and the accumulated control amount currently, each node can know the start number and the end number of the transaction data and the control data contained in the block. When the user end node is at the head of the synchronous block, the account book data in the block can be randomly selected and verified according to the serial number address, for example, m1 control data can be randomly selected and verified, and m2 transaction data can be randomly selected and verified. The control data only has the signature of the management end, so the user end node only needs to acquire the control data through the control data numbering address, verify the signature of the management end and verify whether the data is on the link according to the authentication path. And when the transaction data is verified, the transaction data is acquired through the transaction data numbering address, and then the addresses are inquired and verified according to the input reference address in the transaction data. As known from the above, what the address node that inquires the input reference returns is the connection storage data with the input and output data, i.e. the input data and the output data with the association relationship, and can verify the correctness of the input data and the output data and verify whether the data is on the chain according to the authentication path. Because the user side uses the distributed hash table network for retrieval and each node independently and randomly selects the account book data for verification, the user side cannot know which nodes select and verify certain transaction data, the defect that a certain address is verified only by a specific node can be avoided, and the safety is improved.

From the above, data on any chain can be converted into a connection storage structure of nodes, wherein the nodes store one or more input data and zero, one or more corresponding output data, and the nodes can verify whether the input data and the output data are correct, and the special initial connection storage and the special ending connection storage can also conform to connection storage characteristics through preset input data and preset output data. The data on any chain is converted into node storage through connection storage, and the stored data is proved to be the data on the chain, so that whether the connection of the chain is correct or not can be verified. And by numbering the integrity of the address verification chain, each node can store part of the account book data and the corresponding authentication path, and verify whether the input data and the output data are correct, so that the correctness of all the account book data can be equivalently verified, namely equivalent verification. And the mode of randomly selecting and verifying by the user can be selected to be added, so that the defect that a certain address is only verified by a specific node is avoided, and the safety is improved.

The UTXO with the public chain is taken as an example, such as the Bitcoin system. The UTXO input of bitcot references an unspent transaction ID and an output index, where the transaction ID is a hash of the referenced transaction data. The issue may be treated as a mineworker created CoinBase reward transaction (a coinage transaction, i.e., the first transaction data in each tile volume data). The transaction ID is used as the key for retrieval, and the referenced transaction ID is also used as the key for retrieval. For example, the transaction data ID is Tb, where the inputs are referenced Ta 1 and Ta 2, and there are two outputs Tb 1 and Tb 2; transaction data ID is Tc, with the input reference being Tb [1 ]; transaction data ID is Td, with input reference Tb [2 ]; the number in parentheses is the output index of the reference. The node storing Tb stores the input data Tb, and the output data Tc and Td. Since the same transaction ID is not allowed, there will not be multiple input data but there may be multiple output data depending on the transaction ID as the key retrieved. The input references of the two outputs here are not the same output index and are therefore not double-flower. Each transaction data contains corresponding authentication path data, and the authentication path of the CoinBase reward transaction is the special first transaction data, i.e. the originating connection store. Each node can easily verify the correctness of the input and output data without considering the transaction commission, and the initial connection storage can also easily verify the correctness of the CoinBase awarded transaction. However, considering that the actual bitjoin transaction contains a commission fee, the CoinBase reward transaction comprises a block reward and a transaction commission fee, so that the initial connection storage needs to verify all transaction commission fees of the block in the region where the CoinBase reward transaction is located, if the number of transactions in the block is large, the verification becomes very difficult, and the retrieval of the user who initially connects the storage needs to verify the CoinBase reward transaction also becomes very difficult. If the correctness of input data and output data can be verified only by depending on a limited number of transaction data, the advantages of distributed node connection storage can be exerted, and the correctness of partial transaction data can be stored and verified through each node, so that the aim of verifying the correctness of the whole UTXO chain is fulfilled. And the integrity of the chain can be verified by adding numbered addresses.

Because the present system uses the UTXO model, the unspent output of user a may be known to other users B in the same transaction, the timestamp of the transaction referencing the unspent output may also be known to user B, and if the transaction also references other unspent outputs of user a, user B may also know. To ensure that as little information as possible is revealed, the user may select an auxiliary obfuscation scheme provided by the system. For example, the user transfers these unspent outputs in turn to the obfuscated address provided by the system, which is also a logical chain, so that each time the transferred obfuscated address is different, then another obfuscated address of the system transfers the same amount to the user's new receive transaction address, which has no association with the user's previous unspent output in the UTXO chain, and thus no information can be leaked.

The management address of the user is generated by the generation parameter in the previous management data and the management address master key, and the management data is encrypted and protected by the symmetric encryption working key generated by the generation parameter in the previous management data and the symmetric encryption master key. The first management data of the user, that is, the registration management data of the user, uses the registration ID of the user as a generation parameter. The registration management data of the user comprises an initial address generation parameter of a second account data chain formed by the received transaction data, and also comprises an identity certificate hash value and a user signature public key of the user, and the initial address generation parameter can be used for confirming the identity of the user. Except that the user registration management data and the user identity certificate updating management data contain user associated information for confirming the user identity, the rest of the account book data do not contain the associated information of the user any more. For example, the transaction data may include additional user information, which may include identity information of the user, so that the additional user information is stored under a chain, only a hash value of the additional user information is recorded on the chain, and the additional user information may use a timestamp of the transaction as a salt. In addition to the user additional information, the transaction data may further include contract additional information, which is associated information for recording a contract and does not include the identity information of the user, so that the contract additional information may be stored in a chain. The signature public key of the user is associated with the user identity certificate, so that the user identity certificate update management data also comprises user signature public key update information. Other management data for the user may include user master key update information and general management information, neither of which is related to the user identity.

After the user registers, the user finds out the registration management data through the registration ID and the management address master key, and the symmetric encryption working key generated by the registration ID and the symmetric encryption master key decrypts the data, so that a first account data chain formed by the management data of the user is obtained. And then acquiring a second account data chain formed by the transaction data received by the user according to the transaction data initial generation parameters, the transaction address master key and the signature public key of the user in the registration management data. According to the above, the received transaction address is searched in the user side network, and the transaction using the received transaction address as the input reference, that is, the sending transaction of the user, can be obtained because the connection storage is adopted. Therefore, all transaction data of the user can be acquired simultaneously by acquiring the second account data chain for receiving the transaction. And the blinding factor is decrypted by the generating parameter in the transaction data and the working key generated by the secret transaction master key, so that the account information of the user is obtained.

For example, the user Alice registers an account with the ID of Alice on a management terminal through an identity certificate, and the management terminal issues a management address master key, a transaction address master key, a secret transaction master key and a symmetric encryption master key to the account Alice. Wherein the account ID name is the default initial generation parameter of the management data. The user generates a registration management address through the account ID name Alice and the management address master key, then searches the registration management address in a user side network, namely, the registration management information of the account Alice can be found, and the symmetric encryption work key generated through the account ID name Alice and the symmetric encryption master key decrypts data. The registration management information contains a hash value of a user identity certificate, which can prove the identity of the user, generation parameters used for generating the address of the next management data and a symmetric encryption working key, and initial generation parameters of a receiving transaction address used for generating the first receiving transaction address of the user. After transferring money to an account Alice, a user can generate a receiving transaction address through a generation parameter of the last receiving transaction, a transaction address main key and a signature public key of the user, then the address is searched in a user side network, transaction information can be found, and a working key decryption blinding factor generated through the generation parameter in transaction data and a secret transaction main key can be used for decrypting a ciphertext transaction amount. If Alice needs to transfer money to Bob, an unlocking script needs to be generated through the generation parameter of the last received transaction, the transaction address master key and the signature private key of the user.

When the user needs to prove the asset of a certain address to a third-party user, only the intermediate value K, the identity certificate of the user and the blinding factor need to be provided. The third party user can verify the validity of the identity certificate to confirm the identity of the user, then scalar multiplication operation on an elliptic curve is carried out on the K and the user signature public key to obtain a new public key, and the address generated by verifying the new public key is equal to the address. Because scalar multiplication operation on the elliptic curve has unidirectionality, a public key address of other people cannot be obtained by the operation of K' and a signature public key of a user (assuming that before quantum computation cracking occurs, an algorithm capable of resisting the quantum computation cracking needs to be updated later, and effective proof can be provided). And inquiring whether the address is an unconsumed address through the network, and finally decrypting the ciphertext amount by using the blinding factor. And the information provided by the user does not contain related key information, so that the third-party user cannot acquire the privacy of other transaction data of the user according to the provided information. The query does not cost addresses and is realized through the connection storage of the nodes. As described above, if the address has been spent, the relevant node will return input data and output data; the non-expense is to return only the input data and no output data. However, the query method depends on the relevant nodes, and as will be known later, the third-party user can query the information of the unused address through the second chain system.

The announcement data issued by the system is plaintext, such as announcement information issued or recycled by token, key algorithm updating information, new transaction rule issuing information, system version updating information and the like. According to different announcement types, each announcement has an announcement type and an increasing sequence number, and according to an announcement prefix + an announcement type + an announcement sequence number, an announcement address is formed, and any user can retrieve and verify the announcement in the network through the announcement address.

Therefore, the UTXO chain of the system is stored according to the connection of the UTXO chain of the transaction address (including the special address of the initial transaction data and the end transaction data), and whether the UTXO chain is correct or not can be verified; addresses with sequentially increasing numbers such as numbering addresses are not in a chain relation, so that the addresses are directly stored and can be used for verifying the integrity of a chain and randomly selecting verification; the management address is not in an explicit chain relation (the first account data chain of the user can be acquired only by the user master key, and the management address forms an implicit chain relation), and the announcement address and the like are also directly stored. The value corresponding to the directly stored key has uniqueness, and corresponding data is retrieved and returned; the key stored in connection with may correspond to a plurality of value data, i.e. input and output data stored in connection with, and all relevant data including additional verification data is retrieved and returned. And the user side uses a distributed hash storage mode through a structured peer-to-peer network, each user side only needs to store part of the account book data, corresponding account book data can be retrieved through the address, and the Merckel tree can be used for verifying whether the account book data is contained in a block of the chain.

There may also be rewards in the system that generate chains. In order to meet the condition of the similar public chain, anyone can participate in the generation of the chain, does not need to register or authorize in the system, only needs to generate an asymmetric key as a key for getting the reward by himself, and generates an address according to a certain mode by a public key in the asymmetric key, wherein the address is identified as a getting address through a prefix so as to distinguish the address used in the system. The pick-up address is included when a chain generation object (e.g., a chain generation node) participates in generating a new chunk header. After the block head is confirmed by n, the management terminal issues the plaintext of the reward information to the control data set, the reward information includes a reward preset address, a reward amount and a bound pickup address, and the reward preset address is similar to a preset address issued by token, such as C001. When the reward is picked up, the reward is required to be registered in the system, then reward picking transaction data is generated, the input of the transaction refers to the reward address C001, and the output of the transaction refers to the transaction receiving address of the user, so that the transaction is on a second account data chain of the user, and the private key of the reward picking address is required to be used for generating an unlocking script, and the reward picking can be unlocked. Therefore, the reward is divided into two steps of issuing first and then getting, wherein the issuing is similar to token issuing, and the reward address also conforms to the characteristics of the connection and storage in the above text, and only the plaintext reward information in the control data set is input. The generation of the participation chain does not require registration or authorization in the system, but the drawing of the prize requires registration in the system. The chain generation object may also authorize other users to receive the key to the address, and receive rewards from other users.

Public chain refers to a blockchain system that anyone can read, send transactions and participate in consensus, and belongs to a completely decentralized system. The similar public chain means that the system is the same as the public chain except that anyone can send the transaction, and the transaction centralization and the ledger data decentralization are met. The system architecture of the generic public link is described below in terms of a public link system.

Assuming a public chain system S, in which a user a sends transaction data that satisfies the UTXO rule, i.e. has a legal input reference, and no double flowers can exist. If multiple inputs and outputs are not considered, the transaction data for a on the S-chain will form a sequential single-connect UTXO chain. Assuming that a is a private chain system (S can still regard a as a user), and replacing the transaction data of a with the block data generated by the private chain system, because the private chain can be regarded as the output of the previous block connected (spent) by the next block, and the private chain can be regarded as the UTXO chain, the block data generated by a is connected to the block data and cannot be forked (cannot be double-striped), that is, the UTXO chain of a and the private chain of a on the S chain can be regarded as equivalent. When the block data of the block A is uplink, the S system needs to verify the validity of the block data of the block A, needs to be connected in sequence and cannot be branched, and needs to verify the validity of the book data in the block. The system S can be used by anyone to participate in consensus, read the ledger data and verify the ledger data, so that anyone can verify the ledger data of the system A.

The S system can also have extension data besides the block data of the A, but the extension data does not influence the management data and the transaction data of the user and the account state of the user, so that the user side does not need to read and verify the extension data. The role of the extension data is to enable S to interact with a, enabling S to partially influence the generation of a data, so that this data will only be read by objects and a that participate in S consensus. For example, before the system a issues token issued or recycled information in control data, voting needs to be performed through the system S; or generating a fair random number by S, and influencing the data generated by the A system by the random number so as to solve the partial fairness problem of the A system. The client C does not need to synchronize the block header data of the private chain a, but only needs to synchronize the block header data of the system S, so the block header data of the private chain a can also be stored in the extension data. If illegal data are generated in the system and the data need to be testified, the related data can be stored in the extended data of the S system. If the system uses consensus algorithms such as POA (Proof Of authority) or the like, data Of the relevant verifier elections and verifier lists can also be stored in the extension data.

And the user C of the system A, the initiated transaction data needs to pass from A to S, and the C acquires the transaction data from S. The system S, the system a (private chain or alliance chain system), and the user C of the system a can be regarded as a kind of public chain application system. Anyone can read, verify the transaction, and participate in the consensus. Here, the data of the S chain is read, and the client C also synchronizes the block header data of the S chain. As can be seen from the above, the consistency of the block headers ensures the consistency of the system status, and the synchronization of the consistent S-chain block headers at all the clients can ensure that the statuses of all the clients and the system S are consistent. And the user end only needs to obtain the user master key (the key does not belong to the chain data) from the A system, so that the account data can be retrieved by itself in the structured peer-to-peer network (or the S chain) of the user end, and the third-party user and the supervisor can also retrieve by themselves after the key is authorized, and the process does not depend on the A system or other centralized systems. The generic public chain application system is verifiable, traceable, and non-tamperable. However, since the transaction data of the user needs to be linked up in S through a, the analogous public link application system does not solve the fairness problem of the transaction, but for the general payment system, such as online music purchase, the order of purchase does not affect the result, and the user can normally link up the transaction as long as the user is in compliance. And the fairness problem that the selection can be delayed and prioritized exists, and the fairness problem can be solved by a public chain application system.

The deferrable selection priority is different from the time priority in a manner of generating an authenticatable fair random number and then deciding the priority based on the random number, and is fair because anyone can participate. For example, a lottery system, a purchaser pays a certain amount of money and reserves a random number and a prize receiving address, then the system S generates an authenticatable fair random number through a consensus object, for example, a Commit-before-disclosure scheme (Commit Reveal) can be used, and to avoid block reservation attacks, the Commit can be terminated, then a plurality of block confirmations can be performed, and then disclosure of relevant parameters is delayed, so that the generated random number is ensured to be unknown in advance and can not be tampered. After the random number is published, the prize winning condition is judged according to the correlation degree of the random number reserved by each person and the random number, and then the prize is drawn through the prize drawing address. System a may invoke the associated contract to award the prize to the winning user based on the published random number. The award can bind with relevant contract information of winning a prize, including quoting the information of drawing a prize, quoting the random number and the address of winning a prize reserved by the user, and the plaintext amount of winning a prize, generate the award of the corresponding ciphertext amount to the address of winning a prize, and then subtract the corresponding plaintext amount from the account of the real-name institution issuing the lottery to ensure that the total amount of token in the system is not changed. So the choice of delay is preferential, that is, the system S generates a random number which can be proved to be fair, the disclosure of a plurality of blocks is delayed, and the system A determines the priority through the random number so as to solve the fairness of the problems.

The architecture of the system is described below, and the system is composed of a three-layer two-chain architecture, as shown in fig. 10.

The first layer is also a first chain system, which may be a private chain or a federation chain, belongs to a centralized system (for example, the system a), may adopt a private network and a consensus algorithm such as PBFT (Practical Byzantine Fault Tolerance algorithm) to meet the requirements of quick confirmation and high-frequency transaction, is responsible for a subject with a real name, and is a manager of the system. Including one or more of the following: the management of users and organizations, the issuance or recovery of tokens, the issuance of user master keys and system bulletins, etc., mainly implement system management by issuing control data, and then write in the first chain. The transaction data of the user side is verified by the management side and then written into the first chain, and the block data generated by the first chain can be immediately broadcast to the second layer or the third layer. Because the management terminal has all the user master keys, the management terminal can generate a state tree of the system, and the operations of inquiring and modifying the user account state and the like of the management terminal are realized through the state tree of the system and then converted into the UTXO transaction data or the control data of the bottom layer. The management end can verify the transaction data of the user end and verify the related user identity information. Each transaction data or control data is respectively endowed with a unique serial number which is sequentially increased, and the transaction data or the control data together pass through an endorsement signature of the management terminal. The block head data of the first chain comprises the current accumulated transaction amount and the accumulated control amount, and the block head data passes through the signature of the management terminal.

The second layer is also a second chain system, which is a class public chain (the system S described above), and adopts an unstructured peer-to-peer network, for example, a gossip network protocol may be used, and an algorithm with a long consensus time may be adopted. The second layer verifies the block data of the first chain, but since the second layer does not have the user master key, only the transaction data is verified, the related user identity information is not verified, and a state tree of the system is not generated. As can be seen from the above, the system employs the UTXO model, and anyone can verify the correctness of the transaction amount in the case of ciphertext. The block data of the second chain is composed of one or more block data sequences of the first chain, and the state of any account on the first chain is consistent with the state of the account on the second chain, so that the system is asynchronous and homomorphic. Since the block data of the second chain may be composed of a plurality of block data of the first chain sequentially, the book data of the block blocks of the first chain needs to be re-composed sequentially into the book data of the block blocks of the second chain, including the transaction data and the control data, and then the root hash values of the merkel trees are re-generated and recorded in the block headers of the second chain, and the block headers of the second chain also contain the current accumulated transaction quantity and the accumulated control quantity. Since the ledger data of the second chain block is composed in order, the number of leaf nodes and node sequence numbers satisfying the known merkel tree are also satisfied, and the height and direction of the corresponding authentication path are fixed and known. The second chain may also contain extension data, which may be the state data of the second chain system itself, and does not modify the state of the user, nor does the third layer synchronize and read the data. For example, the data may be a voting process of the second chain, a process of generating an authenticatable fair random number, or the like, or may be a process of voting a chain generating node for the second chain, or may be data for authentication, and the extended data is only read by the first layer and the second layer, and may affect a block subsequently generated by the first chain or the second chain. The block header data of the first chain can also be recorded in the extension data of the second chain, which does not affect the user status, but serves as the data for evidence storage. The block data generated by the second chain is broadcasted to the third layer, and the broadcasted data is the block header data, the transaction data, the control data, the corresponding authentication path data and the like of the second chain.

The third layer is a user end system, a structured peer-to-peer network is adopted, for example, a kademlia network protocol can be used, data is retrieved through a Distributed Hash Table (DHT), and each user end node (hereinafter referred to as a node) only needs to store part of the ledger data and a corresponding authentication path. According to the above, through equivalence verification, each node verifies part of the self account book data, namely all the account book data can be equivalently verified, and then the account book data is independently and randomly selected by combining each node for verification, so that a certain address is prevented from being verified only by a specific node, and the safety is improved. Each node of the third layer synchronizes the block header data of the second layer so that the third layer is consistent with the system state of the second layer. The reading operation of the user end, the third party user and the supervisor can be at the second layer or the third layer, and the writing operation of the transaction data of the user end is linked up at the first layer through the management end, so that the system is read and written separately. And the first chain can be immediately broadcast to the third layer, so the transaction data of the user side can be timely acquired, but the transaction data at the moment is not in the second chain, but only in the first chain. If the transaction is a small transaction, the user side can immediately trust the data issued by the management side; however, if the transaction amount is larger, the ue may wait for a period of time until the transaction data is linked up in the second chain and confirmed by n blocks, and then the transaction data is considered to be irreversible and cannot be tampered.

Because the system states of the second layer system and the third layer system are consistent, and the third layer verifies all the ledger data through equivalent verification, the second layer system can select to verify only the block header data of the first chain, the merkel tree of the ledger data and the management terminal signature of the ledger data, then the data is linked to generate the block data of the second chain and broadcast the block data to the third layer, and the third layer verifies whether the connection of the UTXO chain is correct, and verifies whether the user terminal unlocking signature and the transaction amount in each transaction data are correct. Because each node of the third layer only needs to verify a small amount of ledger data, even if the user side uses a multi-signature mode and needs to verify whether the ciphertext transaction amount is correct, each node has less burden and even the mobile device can complete verification. The signature of the second layer verification management end can also verify a plurality of signatures generated by a single signer in an optimized batch, so that the calculation amount of verification required by participation in second layer consensus is greatly reduced. According to the characteristics of the merkel tree, the chain generating node of the second layer can sequentially disperse the ledger data generated by the first layer to a plurality of physical devices, and combine the ledger data on the physical devices to generate the root hash value of the merkel tree, that is, the generation and verification of huge block volume data containing a great number of ledger data can be completed through the plurality of physical devices, and the storage can also be dispersed to the plurality of physical devices. Different from a way of storing by using a distributed hash table at the third layer, the way belongs to linear division storage, namely, the number of leaf nodes corresponding to a certain parent node is the power of 2 according to the characteristics of the Mercker tree, so that the data is linearly divided into a plurality of physical devices for storage according to the power of 2, then the corresponding root hash values of the Mercker tree can be jointly generated, and an authentication path corresponding to the account book data can also be generated. Therefore, the chain generating node of the second layer only needs a plurality of common physical devices and storage devices, the verified calculation amount is controllable, and the device actually participating in the consensus generating block header only needs common devices, so that the threshold of participating in the second layer consensus is greatly reduced.

The above method uses a mode of generating before verifying, that is, a mode of generating the second chain first and then verifying by the third layer, because the actual ledger data is chained by the first layer system, the second layer verifies the signatures of the mercker tree and the management terminal, and the ledger data is not modified. Therefore, if the third layer verifies that the ledger data is wrong and passes through the signature of the management end (the second layer needs to verify whether the data is the data of the first chain later), the responsible person is the first layer system, and the first layer is the management end with the real name, and the supervisor can perform corresponding processing. Because the first layer is a centralized system, if illegal ledger data is generated, the second layer and the third layer cannot be prevented, but can be immediately verified, and then corresponding measures are taken. For example, the third layer writes illegal account book data into the evidence storage data of the public chain-like extension data from the second layer, while the first layer system cannot modify the data of the second chain, and the data can be accessed by anyone who is open and can be processed by a supervisor accordingly. The system cannot guarantee that the data in the time period of the uplink fragment is definitely correct (because the data is generated by centralization), but can guarantee that the erroneous data is not corrupted (verified by the second layer or the third layer). The data that is uplinked by the second chain and validated over n blocks is correct and non-tamper-able, and therefore trusted. And the first layer system also adopts a private chain or a alliance chain, so that the possibility of data errors is reduced and prevented. As can be seen from the above, the first chain is not allowed to branch, and the first chain can be prevented from branching by using a consensus algorithm such as PBFT. If the first chain is forked, the second layer system can detect and write the data into the evidence storage data of the extended data of the public chain and the supervisor can correspondingly process the data.

The management end system of the first layer can also optimize and process mass data to be verified and stored in a connection storage mode. For example, the consistent hash algorithm may be used to distribute transaction data into a plurality of consensus groups according to the transaction address and the transaction ID, and then the first chain of block header data may be generated by a PBFT (practical byzantine fault-tolerant algorithm) consensus algorithm of attribute grouping.

The PBFT algorithm is a state machine replica replication algorithm. The number of sets of all replicas is set to N, assuming the number of failed replicas is F, N >3F is required. Each node has one state machine copy, so the PBFT algorithm can tolerate less than N/3 invalid or malicious nodes. However, PBFT has the disadvantage of having a message complexity of O (N ^2), so N is not usually very large.

The attribute grouping PBFT consensus algorithm uses a consistent hash algorithm to distribute data into a plurality of consensus groups according to the attributes of the data, and only one group needs to be copied with a state machine copy. For example, N is divided into M consensus groups, each of which has N nodes, i.e., N ═ M × N, and the consensus groups are set to 1 to M sequence numbers.

Before generating the block, mapping each input address of the transaction data to one of 1 to M using a consistent hashing algorithm, mapping the transaction ID, that is, the hash value of the transaction data, to one of 1 to M, and then storing the transaction data in the mapped consensus group, wherein as can be seen from the above, the input address corresponds to the output data stored in a connected manner. After the blocks are generated, namely data uplink, each output address of the transaction data is mapped to one of 1 to M in the same way, and includes a token issue address and a reward address in the control data of the uplink, and then the corresponding uplink data is stored in the mapped common identification group. As can be seen from the above, the output address corresponds to the input data stored in the connection, so the input data stored in the connection stored in the consensus group is the data after uplink, and the consensus group can verify the data through the mercker tree.

If the storage of the consensus group corresponds to the input data, the input data is stored; if the consensus group storage corresponds to the output data, the corresponding input data needs to be searched, the correctness of input and output is verified, and then connection storage is formed; if the storage of the consensus group corresponds to the transaction ID, the PBFT consensus verification is initiated to the consensus group corresponding to the address according to all input reference addresses of the transaction data. It can be known that the common identification groups corresponding to the addresses form a connection storage if the verification is passed, and the verification is returned successfully, and the verification is returned failed if the verification is not passed. As can be seen from the above, when the number of verification successes returned by each address is greater than n × 2/3, the transaction data is verified and may be linked. Therefore, the transaction data is verified and uplinked by the consensus set corresponding to the transaction ID, and since the transaction ID is unique, the uplinking is not repeated. In order to optimize the additional verification data required for verifying the transaction amount, the transaction amount can be verified by the consensus group corresponding to the transaction ID, the consensus group corresponding to the input reference address only needs to verify whether the connection is correct or not, whether the unlocking signature of the user side is valid or not, the transaction amount data is returned, and the additional verification data is not required.

After a time period, each consensus group independently initiates PBFT consensus uplink, and each consensus group respectively and independently identifies the transaction data and sequence of the uplink set of the group. Then the number 1 common identification group adds the accumulated number to the number of the uplink set of the number 1 common identification group, and sends the accumulated number information to the number 2 common identification group; then the number 2 common identification group adds the accumulated number to the number of the uplink set of the number 2 common identification group, and sends the accumulated number information to the number 3 common identification group; until the last consensus group M, M sends the accumulated quantity information to the number 1 consensus group; when the number 1 consensus group receives the accumulated number message, a cycle operation is completed, and the transaction data in the cycle is linked up. Each consensus group calculates a starting serial number according to the accumulated number, then assigns the transaction data of the uplink set and the corresponding sequence to an increasing serial number and requests a signature (for example, n nodes require a request greater than n × 2/3 to assign a signature), and finally combines the signed data to generate a root hash value of the mercker tree. Because of the independent common uplink, each common group can receive a number of messages and then perform common uplink, and complete the cycle operation through message transmission. The reason why the common identification group can separately and commonly identify the uplink is that since the input data stored in the connection is the data after the uplink, the legal transaction of the two references does not occur in the same time slice.

Therefore, it can be seen that the PBFT consensus algorithm message complexity of attribute grouping is O (n ^2), and can tolerate less than n/3 invalid or malicious nodes. However, since there are M packets, the transaction data is also dispersed in the M packets, so that the amount of transaction data that can be finally processed can be greatly increased.

The control data of the system is not a UTXO chain, an increasing serial number can be given and signed when the control data is generated, then the control data is linearly divided, stored and verified according to the serial number, and the Merkel tree root hash value of the control data can also be generated jointly. And finally, generating the first chain of block head data according to the root hash value of the transaction data, the root hash value of the control data and the corresponding accumulated quantity. Therefore, the management end system of the first chain can optimally process massive data in a connection storage mode.

As can be seen from the above, the data stored at the third layer of the user end includes the block header data, the account book data, and the corresponding authentication path data. The ledger data is actually generated by the management side of the first layer, the block header data is generated by the consensus of the second layer, and the block header data can also map the consistency of the block volume data (ledger data), and the block header data can also confirm the corresponding authentication path, so the correct synchronization of the block header data is very important for the correctness of the system. However, the third layer of ue does not participate in the consensus of the second layer, and if the public link system of the second layer adopts a consensus algorithm such as POA (authority certification) or the like, or a consensus algorithm with a mortgage penalty, the third layer of ue needs to be able to correctly synchronize the consensus list, which increases the burden of the ue. Because the second chain is generated based on the verified first chain chunk headers, the third layer user side can verify the second chain chunk headers based on trusting the first chain chunk headers. The consensus algorithm with the mortgage penalty is taken as an example for explanation. The consensus objects at the second level may be anonymous and may participate in the consensus by way of mortgage assets of a third-party public chain (a third-party public chain system other than the first chain system and the second chain system), which may be deducted if illegal data is generated, as explained below.

First, the management end of the first layer needs to establish an intelligent contract on the public chain of the third party. The contract has the functions that any user can upload a consensus public key (the consensus public key is an asymmetric key generated by the user and can be used for participating in consensus of a second layer), one consensus public key needs to collate a certain number of tokens on a third-party public chain, the collated tokens are associated with the uploaded consensus public key, and a consensus date maps a consensus public key set consisting of all the consensus public keys uploaded currently into a value. One of the cryptographic accumulators is a one-way membership function that can be used to identify whether a candidate is a member of a set without exposing members of the set in the process. The block header generated by the first chain contains the value mapped by the current consensus public key set, and may also contain the number of elements in the consensus public key set, and a key represents a fixed interest, i.e. a key-ticket. The header data generated by the second chain is broadcast to the third layer along with the last header data corresponding to the first chain. The second chain block head comprises all current accumulated transaction quantity and accumulated control quantity and corresponding consensus public keys, and the second chain block head data is signed by the consensus private keys. The user side of the third layer synchronizes the block head data of the second chain, can verify the signature of the common identification private key according to the common identification public key, verify the management end signature of the block head of the first chain, verify whether the accumulated transaction quantity and the accumulated control quantity of the block head of the first chain are equal to the accumulated transaction quantity and the accumulated control quantity of the block head of the second chain, if so, the quantity is correct, and the block head of the first chain is the last block head data in the time segment generated by the block head of the second chain, so the mapping value of the common identification public key set in the block head of the first chain is the newest in the time segment. The user side can also verify whether the common public key in the second chain block head is valid or not by adopting a Mercker tree certification or an accumulator certification according to the mapping value of the common public key set in the first chain block head, if the common public key set in the second chain block head is valid, the second chain block head is indicated to be valid, and the block head of the candidate main chain can be added. Therefore, the user side can verify the block head of the second chain on the basis of trusting the block head of the first chain without synchronizing the consensus list of the second chain, and can verify whether the accumulated transaction quantity and the accumulated control quantity of the block head of the second chain are correct or not through the accumulated transaction quantity and the accumulated control quantity of the block head of the first chain so as to ensure that the block head data of the second chain can be correctly synchronized.

The second layer of the similar public chain system can also adopt a consensus algorithm such as POA (public office automation) and the like, so that the identity identification can be provided by the consensus object needing to participate without depending on the public chain of a third party. The first-chain block header may also include a mapping value of a verifier list of the POA consensus algorithm and the number of verifiers, so that the user end can correctly synchronize the block header data of the second chain.

If the first chain block header does not contain the mapping value of the correct public key set of the consensus person according to the rule, the mapping value of the public key set of the consensus person is stored in the contract of the third party public chain or the extension data of the second layer class public key chain, and is public and cannot be tampered. The second layer system can write the head data of the non-compliant blocks of the first chain into the evidence storage data of the extended data of the public chain, and the supervisor can perform corresponding processing.

Therefore, the system respectively uses the block chains to realize the traceability and the non-falsification of the account book data, the UTXO chain realizes the correct connection of the transaction data, the token total amount of the system is ensured to be certain, and the account data chain realizes the privacy retrieval of the user account data. And through equivalence verification, the user end stores and verifies partial account book data through a structured peer-to-peer network, and the correctness of all the account book data can be equivalently verified.

An exemplary embodiment of the present disclosure also provides a computer storage medium storing a computer program; the computer program, when executed, can implement the methods provided by one or more of the foregoing exemplary embodiments, for example, perform one or more of the methods shown in fig. 1, fig. 3, fig. 5, and fig. 7. 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 implementing the operations performed by the data storage device or the data verification device in the present disclosure when executing the computer program.

As shown in fig. 11, in one example, a computer device (node) may include: a processor 91, a memory 92, a bus system 93 and a transceiver 94, wherein the processor 91, the memory 92 and the transceiver 94 are connected via the bus system 93, the memory 92 is used for storing instructions, and the processor 91 is used for executing the instructions stored in the memory 92 to control the transceiver 94 to transmit signals. For example, the operations of the second storage module in the data storage device may be performed by the transceiver under the control of the processor, and the operations of the first authentication module may be performed by the processor.

It should be understood that the processor 91 may be a Central Processing Unit (CPU), and the processor 91 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.

The memory 92 may include a read-only memory and a random access memory, and provides instructions and data to the processor 91. A portion of memory 92 may also include non-volatile random access memory. For example, memory 92 may also store device type information.

The bus system 93 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 93 in fig. 11.

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 91. 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 92, and the processor 91 reads the information in the memory 92 and performs the steps of the above 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 method of storing data in a chained architecture, the method comprising:

2. The data storage method of claim 1, wherein: the storing the data as input data or output data includes:

when the first key is used as part or all of output information in the chain structure, storing data associated with the first key as input data; and when the first key is used as part or all of input information in the chain structure, storing the data associated with the first key as output data.

3. A method of chain structure validation, the method comprising:

4. The chain structure validation method of claim 3, wherein the storing the data as input data or output data comprises:

when the first key is used as part or all of output information in the chain structure, storing data associated with the first key as input data; when the first key is used as part or all of input information in the chain structure, storing data associated with the first key as output data; the input data and the output data stored on the device are associated according to the same connection information.

5. The chain structure verification method according to claim 3, wherein the verifying whether the data associated with the first key is erroneous comprises one or more of the following verifications:

verifying whether the data is the data on the chain structure;

when the first key is used as input information in the chain structure, verifying whether output information with the same connection information as the input information exists;

when the first key is used as input information in the chain structure, verifying whether output information with the same connection information as the input information is used or not;

when the first key is used as input information in the chain structure and data associated with the first key contains a transaction amount, verifying whether the transaction amount is correct;

and when the first key is used as input information in the chain structure and the data associated with the first key contains signature information, verifying whether the signature information is correct.

6. The chain structure validation method of claim 4, further comprising:

according to the request of the data verification device, returning data which is stored by the device and is associated with the connection information of the chain to the data verification device, wherein the data comprises one or more of the following data: input data, output data, a merkel tree authentication path, additional verification data.

7. A method of chain structure validation, the method comprising:

8. The chain structure validation method of claim 7, wherein the data associated with the second key retrieved from the data storage device includes one or more of: data associated with the second key as part or all of the output information in the chained structure, a merkel tree authentication path, additional verification data, wherein the second key is part or all of the input information in the chained structure.

9. The method for verifying the chain structure according to claim 7, wherein the verifying whether the data in the chain structure has errors according to the acquired data comprises:

synchronizing the chunk header data in the chained structure, in conjunction with the chunk header data and the data associated with the second key obtained from the data store, performing one or more of the following verifications:

verifying whether the data associated with the second key obtained from the data storage device is data on the chain structure;

10. A method for implementing a chain structure, wherein the chain structure system comprises a first chain system, a second chain system and a data storage device, the method comprising:

11. The method of claim 10, further comprising: the first chain system having some or all of the linkage information of a chain in the first chain as a third key, the data associated with the third key as a value, the value associated with the third key assigned to a consensus group having the same third key as the value; the consensus group validates the data associated with the third key, wherein:

12. The method for implementing chain structure according to claim 11, wherein after the verifying the data associated with the third key by the consensus group, the method further comprises:

the consensus group stores data associated with the third key as input data or output data, wherein the data associated with the third key is stored as input data when the third key is used as part or all of the output information in the first chain, and the data associated with the third key is stored as output data when the third key is used as part or all of the input information in the first chain; the input data and the output data stored on the same consensus group are related according to the same connection information.

13. The chain structure implementation method of claim 10, wherein the data storage device stores the data as input data or output data, and comprises:

when the first key is used as part or all of the output information in the second chain, storing the data associated with the first key as input data; when the first key is used as part or all of input information in the second chain, storing data associated with the first key as output data; the input data and the output data stored on the present data storage device are associated according to the same connection information.

14. The method of claim 10, wherein the data storage device verifies whether the data associated with the first key is erroneous, including one or more of:

verifying the integrity of the second chain;

verifying whether the data is data on the second chain;

15. The chain structure implementation method of claim 10 or 14,

the method further comprises the following steps: the first chain system arranges sequence numbers for the account book data in sequence, and the block head of the block data corresponding to the account book data comprises the data volume of the accumulated account book; the second chain system includes, in a block header of block data of a second chain, an accumulated book data amount in the block data.

16. The chain structure implementation method of claim 15,

the data storage device verifies the integrity of the chain structure, including: and the data storage device synchronizes the block head of the second chain, generates a serial number address by using the data volume of the accumulated account book in the block head, and verifies the integrity of the second chain according to the serial number address.

17. The method of claim 15, further comprising:

and the data storage device verifies whether the data volume of the accumulated account book in the second chain block head data is correct or not according to the first chain block head data.

18. The method of claim 10, further comprising:

the first chain system includes a value of a current consensus public key set mapping in a block header of a first chain;

and the data storage device adopts the Mercker tree certification or the accumulator certification according to the mapping value of the common public key set in the first chain block header to verify whether the common public key in the second chain block header is valid.

19. The chain structure implementation method of claim 10,

the second chain system writes one or more consecutive block data of the first chain to block data of a second chain, including: and the second chain system recombines one or more continuous block data of the first chain according to the sequence of the transaction data sequence number and the sequence of the control data sequence number to respectively generate a Mercker tree root hash value, and the generated block head of the second chain contains the Mercker tree root hash value.

20. The chain architecture implementation method of claim 10, wherein the system further comprises: a data verification device; the method further comprises the following steps: the data verification device takes part or all of the connection information of the chain in the chain structure as a second key, acquires data stored on the data storage device and associated with the second key from the data storage device, and verifies whether the data in the second chain has errors according to the acquired data.

21. The method for implementing the chain structure according to claim 20, wherein the data verification device uses part or all of the connection information in the chain structure as a second key, and the obtaining the data stored on the data storage device and associated with the second key comprises:

the data verification device synchronizes a block head of the second chain, generates a serial number address by using the data volume of the accumulated account book in the block head, acquires partial or all connection information of the chain as a second key according to the serial number address, and acquires data which is stored on the data storage device and is associated with the second key from the data storage device.

22. The chain structure implementation method of claim 20,

the data verification device obtaining from the data storage device data stored on the data storage device associated with the second key includes one or more of: data associated with the second key as part or all of the output information in the chain structure, a merkel tree authentication path, additional verification data, wherein the second key is part or all of the input information in the chain structure;

the data verifying device verifies whether the data in the second chain has errors according to the acquired data, and the method comprises the following steps:

the data verification means synchronizes the chunk headers in the second chain, in conjunction with the chunk headers and the data associated with the second key retrieved from the data storage means, performing one or more of the following verifications:

23. The chain structure implementation method of claim 20,

and the data verification device adopts the Mercker tree certification or the accumulator certification according to the mapping value of the common public key set in the first chain block header to verify whether the common public key in the second chain block header is valid.

24. The method of claim 10, wherein the first chain is a private chain or a federation chain, and wherein the method further comprises: the first chain system issues to the user one or more of the following keys: a management address master key, a transaction address master key, a confidential transaction master key, and a symmetric encryption master key, wherein:

and the symmetric encryption master key is used for generating a symmetric encryption working key of the next encryption and decryption management data of the user together with the current fourth generation parameter.

25. The method for realizing a chain structure according to claim 10 or 24, further comprising:

the first chain system generates a current management address of a user by using a master key of a management address issued for the user and generation parameters in last management data of the user, and writes generation parameters for generating a next management address of the user in the current management data.

26. A chain structured data storage device, comprising a first storage module and a second storage module, wherein:

27. The chain structure data storage device of claim 26, further comprising a first verification module for verifying whether data in the chain structure associated with the first key is erroneous.

28. The chained architecture data storage device of claim 27, wherein the first verification module verifies that the data associated with the first key is erroneous, comprising:

the first authentication module performs one or more of the following authentication operations:

verifying whether the data is the data on the chain structure;

29. The data verification device with the chain structure is characterized by comprising a key value searching module and a second verification module, wherein:

30. The chain structure data verification device of claim 29, wherein the second verification module verifies whether the data in the chain structure has errors according to the acquired data, and comprises:

the data verification device synchronizes the block header data in the chain structure, and the second verification module combines the block header data with the data associated with the second key acquired from the data storage device to perform one or more of the following verifications:

31. A chain structure system, comprising: a first chain system, a second chain system, and a data storage device, wherein:

32. The chain structured system of claim 31, wherein said first chain system further comprises a consensus group;

33. The chain architecture system of claim 32, wherein the consensus group is further configured to store the data associated with the third key as input data or output data after the data associated with the third key is verified, wherein the data associated with the third key is stored as input data when the third key is used as part or all of the output information in the first chain, and the data associated with the third key is stored as output data when the third key is used as part or all of the input information in the first chain; the input data and the output data stored on the same consensus group are related according to the same connection information.

34. The chain structure system of claim 31, wherein the first chain system is further configured to sequentially sequence number for the ledger data, and a block header of block data corresponding to the ledger data includes an accumulated ledger data amount; the second chain system is also used for including the accumulated account book data amount in the block data in the block head of the block data of the second chain.

35. The chain architecture system of claim 31, wherein the data storage device verifies that the data associated with the first key is erroneous, including one or more of:

verifying the integrity of the second chain;

verifying whether the data is data on the second chain;

36. The chain structured system according to claim 31, further comprising: a data verification device; the data verification device is used for taking part or all of the connection information of the chain in the chain structure as a second key, acquiring data stored on the data storage device and associated with the second key from the data storage device, and verifying whether the data in the second chain has errors according to the acquired data.

37. The chain structure system of claim 31 or 36, wherein the first chain system is further configured to include a value of the current mapping of the common public key set in the block header of the first chain, so that the data storage device or the data verification device verifies whether the common public key in the block header of the second chain is valid according to the merkel tree certification or the accumulator by using the mapping value of the common public key set in the block header of the first chain.

38. The chain architecture system of claim 31, wherein the first chain system is further configured to generate a current management address of a user using a master key of a management address issued for the user and generation parameters in previous management data of the user, and write generation parameters for generating a next management address of the user in the current management data.

39. A computer-readable storage medium storing computer-executable instructions for performing the method of any of claims 1-2 or claims 3-6 or claims 7-9 or claims 10-25.

40. A computer arrangement comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the steps of the method as claimed in any one of claims 1-2 or claims 3-6 or claims 7-9 or claims 10-25 are implemented by the processor when executing the program.