CN117714089A

CN117714089A - Verification method and device for blockchain

Info

Publication number: CN117714089A
Application number: CN202311171251.1A
Authority: CN
Inventors: 黄方蕾; 邱炜伟; 乔沛杨; 张珂杰; 胡麦芳
Original assignee: Hangzhou Qulian Technology Co Ltd
Current assignee: Hangzhou Qulian Technology Co Ltd
Priority date: 2023-09-11
Filing date: 2023-09-11
Publication date: 2024-03-15

Abstract

The application is applicable to the technical field of blockchains, and provides a verification method for a blockchain (comprising a first layer of chain and a second layer of chain), which comprises the following steps: packaging N transactions in the second layer chain to generate a first data packet, wherein the first data packet comprises transaction information corresponding to each transaction in the N transactions, and the transaction information corresponding to each transaction comprises one or more of the following information: transaction result information, signature information and state update information, wherein N is a positive integer greater than 1; transmitting the first data packet to the first layer chain; and carrying out batch verification on the first data packet on the first layer chain to obtain a verification result. Compared with the mode of verifying single transaction one by one, the method and the device have the advantages that the packaged transaction is subjected to batch verification by packaging the plurality of transactions, and therefore throughput of the blockchain can be greatly improved.

Description

Verification method and device for blockchain

Technical Field

The application belongs to the technical field of blockchains, and particularly relates to a verification method and device for a blockchain.

Background

A blockchain is essentially a decentralized distributed database. Unlike dedicated third party authentication, in the blockchain, any user can participate in billing, and the system will verify the fastest uploading "data block" or "chunk" for a certain period of time, after verification is passed. The "data block" or "chunk" is added to the end of the blockchain and broadcast to all other users in the system for backup.

However, with the big fire of blockchain technology, the transaction information that blockchain needs to process increases dramatically, causing the blockchain network to become congested. Blockchain network congestion can cause the system to require longer time to process transaction information, greatly reduce throughput, waste a lot of computing resources, and also cause blockchain centralization. To solve the problem of blockchain congestion, developers have proposed solutions such as slicing, side-chain, and rolling techniques. However, the existing solutions still have a plurality of drawbacks, such as excessively long time for generating the proof, resulting in low efficiency of submitting the transaction data, and the main chain also needs to spend time for verifying the submitted proof, so that the problem of low verification efficiency exists, and the throughput of the blockchain main chain is greatly reduced.

Disclosure of Invention

In view of this, the embodiments of the present application provide a method and apparatus for verifying a blockchain, which can effectively improve the throughput of the blockchain. In a first aspect, an embodiment of the present application provides a method for verifying a blockchain, including:

packaging N transactions in the second layer chain to generate a first data packet, wherein the first data packet comprises transaction information corresponding to each transaction in the N transactions, and the transaction information corresponding to each transaction comprises one or more of the following information: transaction result information, signature information and state update information, wherein N is a positive integer greater than 1;

transmitting the first data packet to the first layer chain;

and carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

In the embodiment of the application, a plurality of transactions are initiated and executed on the second-layer chain, and after the transaction results, the state update information and the signature information corresponding to the plurality of transactions are packaged, the packaged transaction results, the state update information and the signature information are uploaded to the first-layer chain; the validity and authenticity of the multiple transactions are verified by means of batch verification of the signature information of the packaged multiple transactions in a first layer chain. Compared with the method of generating the certificate while packaging the data packet and submitting the certificate to the blockchain main chain for verification, the method provided by the embodiment of the application is to package the signature information related to each transaction into the first data packet, and then verify the signature information in the first data packet in batches. The method can effectively improve the submitting efficiency and the verification efficiency of transaction data, and save the transaction cost required to be paid for submitting the transaction, thereby effectively improving the throughput of the blockchain.

In one possible implementation manner, the packaging processing is performed on the N transactions in the second layer chain to generate a first data packet, including:

and packaging the first data packet in the second layer chain by using a rolling algorithm to generate the first data packet, and generating no evidence corresponding to the first data packet when the first data packet is generated.

The mode of compressing and packaging the plurality of transaction data of the second-layer chain by using the rolling algorithm can greatly reduce the transaction cost, greatly liberate the computing resources of the first-layer chain and improve the efficiency of processing the data of the first-layer chain. Moreover, compared with a scheme that a lot of time is consumed to generate the certification while packaging transaction data, the method and the device do not need to consume time to generate the relevant certification when generating the first data packet. Because the process of generating the certificate has extremely high requirements on hardware equipment, if the step of generating the certificate is omitted, the requirements on the hardware equipment are wider, the investment of transaction cost can be saved, the transaction packaging time is shortened, and the data packaging efficiency is higher.

In one possible implementation, the N transactions satisfy one or more of the following conditions: the transaction quantity of the N transactions meets a preset packaging threshold; the memory capacity occupied by the N transactions meets the preset memory capacity; the transaction time of the N transactions is within a preset time range.

In one possible implementation, the transaction result information is used to characterize a result of a change in an amount of an account associated with each transaction when the each transaction is executed; the signature information is used for representing a signature corresponding to each transaction when the transaction is executed; the state updating information is used for recording the corresponding state of each transaction on the second layer chain in real time when the transaction is executed.

The method for submitting the transaction results of the multiple transactions to the first-layer chain can avoid that the first-layer chain receives a large amount of redundant information, and signature information and state information of each transaction are attached to the first data packet, so that the verification and the assurance of the integrity and the legality of the transaction can be facilitated.

In one possible implementation manner, the batch verification of the first data packet on the first layer chain, to obtain a verification result, includes: and based on a batch signature verification algorithm, carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

Compared with a single signature verification mode, the method has the advantages that verification time is greatly shortened through the mode of verifying signature information in batches, verification speed is greatly improved while transaction data safety is ensured, throughput of block chains is further improved, and the number of transactions executed per second is increased.

In one possible implementation manner, the batch verification is performed on the first data packet on the first layer chain based on a batch verification algorithm to obtain a verification result, including: aggregating signature information corresponding to the N transactions, and verifying the aggregated signature information; if the aggregated signature information passes verification, outputting a verification result, wherein the verification result is that the first data packet passes verification; and if the aggregated signature information fails to pass the verification, outputting the verification result, wherein the verification result is that the first data packet fails to pass the verification.

In one possible implementation, the method further includes: storing the first data packet in the first layer chain under the condition that the verification result is that the first data packet passes verification; and carrying out data rollback processing on the block chain based on the first data packet under the condition that the verification result is that the first data packet fails the verification result.

In a second aspect, embodiments of the present application provide a validation apparatus for a blockchain, including: the system comprises a packaging unit, a data submitting unit and a verification unit.

The packaging unit is configured to perform packaging processing on N transactions in the second layer chain, and generate a first data packet, where the first data packet includes transaction information corresponding to each transaction in the N transactions, and the transaction information corresponding to each transaction includes one or more of the following information: transaction result information, signature information and state update information, wherein N is a positive integer greater than 1;

The data submitting unit is used for sending the first data packet to the first layer chain;

and the verification unit performs batch verification on the first data packet on the first layer chain to obtain a verification result.

Optionally, the packaging unit further comprises: and packaging the first data packet in the second layer chain by using a rolling algorithm to generate the first data packet, and generating no evidence corresponding to the first data packet when the first data packet is generated.

In a third aspect, embodiments of the present application provide a blockchain system including a first tier chain and a second tier chain. Optionally, the first layer chain includes a plurality of nodes, and the node type includes at least a first node and a second node; the second tier chain also includes a plurality of nodes, the node type including at least a third node. The blockchain system is configured to perform the verification method for blockchains according to any implementation manner of the first aspect of the embodiments of the present application.

In a fourth aspect, embodiments of the present application provide a verification apparatus for a blockchain, including a processor and a memory, the processor and the memory being coupled, the memory being configured to store a computer program, which when executed by the processor, causes the apparatus to perform the verification method for a blockchain according to any one of the implementations of the first aspect of the embodiments of the present application.

In a fifth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program, which when executed by a processor, implements the steps of the method of the first aspect.

In a sixth aspect, embodiments of the present application provide a computer program product that, when run on a validation apparatus for a blockchain, causes the validation apparatus for a blockchain to perform the method of any of the first aspects above.

It will be appreciated that the advantages of the second to sixth aspects may be found in the relevant description of the first aspect, and are not described here again.

Compared with the prior art, the embodiment of the application has the beneficial effects that: according to the verification method for the blockchain, after the transaction is executed on the second-layer chain, N transactions meeting the conditions are packaged, and the packaged first data packet is submitted to the first-layer chain for verification. However, when the first data packet is packed and submitted, a proof corresponding to the first data packet is not generated, but the validity and authenticity of the transaction is determined by verifying the signature information in the first data packet. The method can greatly reduce investment of transaction cost, and improve data submitting efficiency and verification efficiency on the premise of ensuring user information safety, so that throughput of a blockchain is greatly improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required for the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method for blockchain verification provided in an embodiment of the present application;

FIG. 2 is an exemplary diagram of a merck tree provided by an embodiment of the present application;

FIG. 3 is a schematic diagram of a block chain verification device according to an embodiment of the present disclosure;

fig. 4 is a schematic structural diagram of a blockchain verification device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It should be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It should also be understood that the term "and/or" as used in this specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.

As used in this specification and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".

In addition, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.

Reference in the specification to "one embodiment" or "some embodiments" or the like means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," and the like in the specification are not necessarily all referring to the same embodiment, but mean "one or more but not all embodiments" unless expressly specified otherwise. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless expressly specified otherwise.

In one possible application scenario, the method and the device for verifying a blockchain provided by the embodiments of the present application are applicable to a blockchain system involving two-layer expansion. As the name suggests, the two-tier capacity expanding blockchain system comprises at least a first tier chain and a second tier chain. The second-layer chain is used for reducing the calculation burden of the first-layer chain, and the first-layer chain only verifies the transaction result by moving the intersection calculation originally executed on the first-layer chain to the second-layer chain, so that the expandability of the first-layer chain can be increased, and the data processing efficiency of the first-layer chain is improved.

For ease of understanding, some terms or concepts related to the embodiments of the present application are briefly described before describing the embodiments of the present application.

Blockchain: a distributed billing system is formed based on a variety of techniques including cryptographic algorithms, consensus mechanisms, point-to-point transmission, mathematics, computer programming, and the like. The block includes a block header (including metadata) and a block body (including transaction information). The chain is formed by sequencing blocks according to time sequence and connecting hash values between a previous block and a subsequent block in series, and is not a real chain. The blockchains can be categorized into public chains (Public Blockchain), private chains (Private Blockchain), federated chains (Consortium Blockchain) according to the application scenario.

Alliance chain: a blockchain managed by multiple organizations together, wherein each organization or organization manages one or more nodes whose data only allows for reading, writing and sending by different organizations within the coalition chain. The read-write rights and accounting rights on the federation chain are defined by federation rules, and the consensus process is controlled by pre-selected nodes. All nodes on the alliance chain can be added into the alliance chain network after being checked by multiple parties and meeting the standards of identity awareness, credibility and technical reliability. The federation chain has a small number of nodes (e.g., a blockchain federation consisting of 40 banks with a number of nodes of 40) compared to public chains and has extremely high security. Transactions on the alliance chain do not need all network nodes to be verified, so the transaction speed is faster, and the read authority on the network nodes is limited to the inside of an organization, so the privacy guarantee is better.

First layer chain: also referred to as Layer1 or base Layer network, defines the new rules, consensus mechanisms and functions of a particular blockchain. The first tier chain may provide an infrastructure for other tiers or applications and the first tier chain is able to process and complete transactions on its own blockchain, with native tokens for payment of the transaction fee, while other tiers or applications need to resort to the first tier chain to complete the payment transaction. A common first layer chain includes: ethernet (abbreviated as ETH), coin-in intelligent chain.

Optionally, the first layer chain includes a plurality of nodes, which may be the same or different types of nodes. The node type at least comprises a first node (i.e. a consensus node) and a second node. The first node is used for verifying the transaction data to ensure that the transaction is correctly processed; and the first node is further configured to maintain an operational state of the entire blockchain (e.g., initiate and perform rollback processing when a transaction exception or a blockchain point itself occurs, where rollback processing includes data rollback processing and program rollback processing); the second node is used for verifying and recording the passing transaction data.

Second layer chain: also referred to as Layer2, is built on top of the first tier chain to reduce the load on the first tier chain and improve the scalability, transaction throughput and processing efficiency of the blockchain. The user may perform intelligent contracts and transactions on the second tier chain, submitting only the final transaction results to the first tier chain. It should be noted that the first layer chain and the second layer chain are both block chains that operate independently. And the second tier chain also has a state tree (or transaction tree) thereon, but unlike the decentralization of the first tier chain, the second tier chain allows presentation in a centralized form.

Optionally, the second tier chain includes a plurality of nodes, which may be the same or different types of nodes. The node type includes at least a third node for performing a user initiated transaction.

Alternatively, the first tier chain and the second tier chain may be linked by a smart contract. An intelligent contract is a contract written in code that can run autonomously on a first tier chain. Based on the smart contracts, the blockchain may perform operations on the second tier chain that would otherwise need to be done on the first tier chain, e.g., account amount variation between different users (i.e., "out-of-chain transactions") is performed on the second tier chain. And, the blockchain may also verify that all operations performed on the second tier chain adhere to the contract terms based on the smart contract. In addition, blockchains can also establish digital identity and authentication of users based on smart contracts.

Rolling and folding algorithm: for the second tier chain, including optimistic rolling algorithms (Optimistic Rollups) and Zero knowledge proof rolling algorithms (Zero-Knowledge proof Rollups, ZK-Rollups). The method is characterized in that a plurality of transaction information are packed and compressed into one transaction information, a certificate (the certificate generated by the optimistic rolling algorithm is a fraud certificate and the certificate generated by the zero-knowledge rolling algorithm is a validity certificate) is generated at the same time, and then the certificate and the packed transaction information are submitted to a first layer of chain for processing. This way the gas costs and the time required to process the transaction can be greatly reduced.

Transaction fee: also referred to as gas costs, can be understood as handling costs. Specifically, because the blockchain is a computing network formed by combining a plurality of virtual machines, the user a needs to process the transaction (e.g. workers acquire and package transaction information, other consensus nodes verify the packaged transaction information, broadcast the transaction results) through the blockchain user B, and the processing process needs to consume computing resources. To encourage workers to package transaction information, the user needs to pay the worker in addition to the normal transaction, which is the gas fee. When the submitted orders for the packaged transaction information increase, the worker may prefer to process the orders for which gas costs are high.

When using blockchain to record transaction information, if the transaction information to be processed is too much, the blockchain network is congested, so that the throughput of the blockchain (namely, the data quantity processed in a certain time) is reduced, the transaction cost is increased, and the blockchain is centralized, namely, extremely depending on a very individual central node, so that the situation of network congestion is aggravated. To solve the congestion of the blockchain network, developers have proposed solutions, however, these solutions have drawbacks.

Taking the zero knowledge proof rolling algorithm as an example, the zero knowledge proof rolling algorithm can transfer the calculation on the blockchain to the position below the chain, and the blockchain only needs to verify the calculation result, so that the pressure of the main chain is reduced. This approach, while relieving the computational pressure of the blockchain backbone, takes up to twenty-three minutes to generate a proof of validity of the data packet while packaging the data. The process of generating the certificate has extremely high requirements on hardware equipment. The known blockchain verifies the transaction data submitted first and broadcasts it to other nodes. If the data is submitted at a slow rate, there may be a risk that the transaction data cannot be linked. Therefore, zero knowledge proves that the rolling algorithm does not have the characteristic of high efficiency and universality.

In view of this, the present application proposes a method and apparatus for verifying a blockchain, by initiating and executing a plurality of transactions on a second layer chain, and packaging transaction results, status update information, and signature information corresponding to the plurality of transactions, and uploading the packaged transaction results, status update information, and signature information to a first layer chain; the validity and authenticity of the multiple transactions are verified by means of batch verification of the signature information of the packaged multiple transactions in a first layer chain. Compared with the method of generating the certificate while packaging the data packet and submitting the certificate to the blockchain main chain for verification, the method provided by the embodiment of the application is to package the signature information related to each transaction into the first data packet, and then verify the signature information in the first data packet in batches. The method can effectively improve the submitting efficiency and the verification efficiency of transaction data, and save the transaction cost required to be paid for submitting the transaction, thereby effectively improving the throughput of the blockchain.

In addition, the blockchain provided by the embodiment of the application has stricter admission principle and identity management from the aspects of construction, joining, operation and transaction. The technical scheme provided by the application does not need to generate a certificate, but directly uploads the first data packet to the first layer chain for verification. Based on the high security of the blockchain, the information security in the first data packet is ensured, the requirements on hardware equipment are naturally wide, and the transaction cost can be effectively reduced. In addition, the verification is performed by using a batch signature verification algorithm, so that the verification rate can be further improved, and the throughput of the blockchain is greatly improved.

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

Fig. 1 is a flowchart of a block chain verification method according to an embodiment of the present application. It should be appreciated that the methods provided by embodiments of the present application may be used with two-layer capacity-expanding blockchain systems, by way of example and not limitation. As shown in fig. 1, the method comprises the steps of:

step 110: packaging N transactions in the second layer chain to generate a first data packet, wherein the first data packet comprises transaction information corresponding to each transaction in the N transactions, and the transaction information corresponding to each transaction comprises one or more of the following information: transaction result information, signature information and state update information, wherein N is a positive integer greater than 1.

Illustratively, after the second-layer link receives a request for initiating a transaction, identity information (including but not limited to user account balance, user birth information, face recognition, certificate comparison, account address, company registration information, business license, business scope) and account information (including but not limited to account address, account balance) uploaded by the user are verified; after the verification is passed, calculating the amount, transfer path and the like related to the transaction; based on the calculation result, money variation between different users is performed.

Specifically, one of the transactions on the second tier chain is used to initiate a transfer transaction with the user B. The second layer chain creates related transaction and verifies the identity information and account information sent by the user A; after the verification is passed, the second-tier chain reduces a certain amount of crypto-currency in the A user account and simultaneously increases an equal amount of crypto-currency in the B user account based on the calculation result. After the transaction is completed, transaction information corresponding to the transaction is stored in a transaction pool.

It should be appreciated that other transactions initiated on the second tier chain may also refer to the transaction process described above in which the a user transfers to the B user. For brevity, no further description is provided herein.

The transaction executed on the second-tier chain needs to be verified by the first-tier chain to be authentic and valid, so that after the plurality of transactions are completed on the second-tier chain, transaction information of each transaction in the plurality of transactions needs to be sent to the first-tier chain for verification by the first-tier chain. In addition, in order to save transaction cost (i.e. handling fee), N transactions are compressed and packed into a first data packet, and then the first data packet is uploaded.

It should be appreciated that the foregoing transfer transactions between users a and B are introduced merely to explain the transaction operations on the second tier chain, but embodiments of the present application are not so limited. In fact, the users involved in a transaction may be one-to-one or many-to-many. Further, the users involved in a transaction may be individuals and/or business organizations, etc.

It should be noted that the specific transaction calculation process is not involved in the first data packet. The reason is that uploading all data involved in the transaction to the first tier chain creates a large amount of useless redundant information. Such as information related to user identity authentication, information related to calculating the number of transactions (including but not limited to user asset transfer information, contract execution information, time stamps, difficulty target information), etc. In the first tier chain validation transaction, only the change of the balance of accounts of both parties to the transaction is concerned, and specific transaction contents, such as occupation, residence and the like of both parties to the transaction, are not concerned. Taking the example of user a paying 20 cryptocurrencies to user B, the first layer chain, when validating the transaction, will only validate: whether 20 pieces of encrypted money are really available on the balance of the user A, whether the amount of money sent by the user A is equal to the amount of money received by the user B, and whether the corresponding 20 pieces of encrypted money on the account of the user A are really destroyed.

In one possible implementation manner, the packaging processing is performed on the N transactions in the second layer chain, so as to generate a first data packet, which includes: and packaging the first data packet in the second layer chain by using a rolling algorithm to generate the first data packet, and generating no evidence corresponding to the first data packet when the first data packet is generated.

It will be appreciated that common convolution algorithms include optimistic convolution algorithms and zero knowledge proof convolution algorithms. Based on the verification method for blockchains provided by the embodiment of the application, when the rolling algorithm is utilized to compress and package the transaction information of N transactions to obtain the first data packet, the rolling algorithm is only utilized to package the N transactions into one data packet (or one transaction), and no evidence (fraud evidence or validity evidence) is required to be generated; accordingly, when submitting to the first tier chain, only the first data packet is uploaded, and no proof need be submitted.

The signature information and the status update information related to the first packet will be explained below.

(1) Signature information

Signature information can be understood as an encrypted digital signature, which ensures the integrity and non-tamper ability of the information. In the transaction process, the signature information is used for binding the payer and the transaction information, so that the effects of identity authentication and repudiation prevention can be achieved. Each transaction has corresponding signature information. Besides uploading the transaction results corresponding to the N transactions, the signature information corresponding to the N transactions is also required to be packaged and uploaded. The reason is that the transaction is executed on the second-tier chain, and the first-tier chain (i.e., the main chain) is required to verify the transaction, the transaction information is recorded on the blockchain, and then the approval of all other nodes on the chain can be obtained, so that the transaction has authenticity and validity.

Optionally, in a possible implementation, the signature information is generated based on a serialization tool or an elliptic curve signature tool.

Illustratively, in response to a user selection, the blockchain generates signature information for each transaction using a serialization tool or elliptic curve signature tool.

(2) Status update information

The state updating information refers to the corresponding state of each transaction recorded in real time on the second layer chain when each transaction is executed. The corresponding state on the second-tier chain may be understood as a transaction data record of the transaction on the second-tier chain. The status update information of each transaction can be understood as update information of the transaction data record on the corresponding second layer chain after each transaction is executed. In addition, the corresponding state of each transaction on the second-layer chain can be understood as the progress of the transaction on the second-layer chain, for example, the transaction is to be confirmed, the transaction is in progress, the transaction is completed, and the transaction is closed.

The state updating information can ensure that each transaction is not tampered or lost, thereby ensuring the safety and the integrity of the transaction information. On the second tier chain, each time a transaction is executed, the state of the transaction on the second tier chain is updated.

Alternatively, the transaction tree on the second tier chain may be used to update the status information for each transaction. The state information of each transaction is updated by changing the tree root value of the transaction tree. Illustratively, the trade tree may employ a merkletree (merkletree), and the root of the trade tree may also be referred to as the merkletree root. The merck tree is a type of hash binary tree, which may also be referred to simply as a hash tree. The merck tree structure consists of a root node, a set of intermediate nodes, and a set of leaf nodes. The root node is the result of the merck tree construction, typically consisting of hash values of its two child node contents; the leaf nodes are the composing basis of the merck tree, and the leaf nodes are used for storing terms or corresponding hash values thereof; the intermediate node is composed of hash values of the contents of its corresponding two child nodes.

The very high number of transactions on the second tier chain means that account balance status of a large number of users is changing, and for this purpose, the integrity and validity of transaction information can be ensured by constructing a merck tree. In the embodiment of the application, the merck tree is adopted to combine multiple sets of transaction information into one data, and multiple sets of data summarization results are stored. Assuming that the number of the leaf nodes is 2N, the 2N leaf nodes can calculate and obtain N intermediate nodes by carrying out hash processing on hash values of every two adjacent leaf nodes; and continuing to hash the hash values of two adjacent intermediate nodes until N intermediate nodes are aggregated into one node, wherein the node obtained by the final aggregation is a root node, and the corresponding hash value is the root hash value. A root node, which may also be referred to as a merck tree root, is a unique identification of the entire merck tree. The root node contains the hash of all transaction information and has non-tamper-resistance (the merck root will take on completely different values if any data or transaction sequence changes in the transaction). Through the merck root, the user can quickly verify the integrity and validity of the transaction information. It should be noted that, the number of transaction information participating in the merck tree construction is even, and if the number of transaction information is odd, the number of transaction information is changed to even by copying the last group of transaction information.

For visual understanding of the merck tree, fig. 2 is an exemplary diagram of the merck tree provided in an embodiment of the present application. The merck tree shown in fig. 2 has a binary tree structure, and includes a leaf node a, a leaf node b, a leaf node c, and a leaf node d. Wherein transaction information TX1 is stored in leaf node a, transaction information TX2 is stored in leaf node b, transaction information TX3 is stored in leaf node c, and transaction information TX4 is stored in leaf node d. Calculating a generated hash value 0 by using transaction information TX1, calculating a generated hash value 1 by using transaction information TX2, calculating a generated hash value 2 by using transaction information TX3, and calculating a generated hash value 3 by using transaction information TX 4; then, carrying out hash processing again by utilizing the adjacent hash value 0 and the hash value 1 to obtain a hash value 01, wherein the hash value 01 is stored in the intermediate node A; performing hash processing by utilizing the adjacent hash value 2 and hash value 3 to obtain a hash value 23, wherein the hash value 23 is stored in the intermediate node B; continuing to hash the adjacent hash value 01 and hash value 23 to obtain a root hash value 0123, and storing the root hash value 0123 in the root node.

It should be noted that, each time a transaction is completed, the transaction information corresponding to the transaction is added into the merck tree. The change in transaction number to build the merck tree also causes the merck tree on the second level chain to produce a different state. Specifically, before and after each transaction is executed, 2 states exist in the merck tree corresponding to the second-layer chain, which are represented by the root value of the merck tree. The 2 states are respectively: the state of the merck tree on the second-tier chain before the current transaction is performed (i.e., the value of the first merck tree root, which is generated from several transaction data before the transaction), and the state of the merck tree on the second-tier chain after the current transaction is performed (i.e., the value of the second merck tree root, which is generated by adding new transaction data to the original merck tree). After each transaction is initiated, the state of the second-layer chain is updated, which can be understood that the value of the merck tree root of the second-layer chain is correspondingly changed when each transaction information is added.

Optionally, the update of transaction information may also be implemented using smart contracts. For example, the user A performs online shopping, the second layer chain creates related information of the transaction, and after the user A confirms the transaction content and pays the transaction amount, the intelligent closing date records the payment information in the second layer chain; then after the seller delivers the goods, the intelligent contract updates the delivery information of the transaction on the second layer chain; after the user A receives the commodity, the latest state of the transaction, namely the receiving information, is updated.

Illustratively, N transactions meeting a preset packing threshold are obtained from a memory pool, and the number of the N transactions is packed. Assuming that the preset packing threshold value is 50, packing transaction information corresponding to 50 transactions when the accumulated transaction number reaches 50 times, and generating a first data packet.

It should be appreciated that the preset packing threshold is a threshold that is preset taking into account the cumulative number of transactions. After each transaction is completed, the transaction is marked, e.g., 27 th completed transaction, 49 th completed transaction. When the transaction completion number meets the preset packing threshold (for example, a value of 50), the 1 st to 50 th transactions are packed. The preset packaging threshold value can be preset in combination with actual requirements.

Or, under the condition that the memory capacity occupied by the N transactions meets the preset memory capacity, packaging the transaction quantity of the N transactions. Generally, the bytes of each transaction information are about 250 bytes, and when the sum of N transaction information reaches 3 kilobytes under the condition that the preset memory capacity is 3000 bytes, the N transaction information is packed to generate a first data packet.

It should be appreciated that the preset memory capacity is a preset threshold value considering the memory occupied by a plurality of transactions. After each transaction is received, the memory pool accumulates the number of bytes occupied by the transaction information. The preset memory capacity is preset, and is used for packaging transaction information of a plurality of transactions when the accumulated byte number sum meets the preset memory capacity. The preset memory capacity can be preset in combination with actual requirements.

Or, setting a preset time range, and packaging N transactions completed in the preset time range.

It should be understood that the preset time range is a threshold value set in consideration of the transaction time. The preset time range is preset manually. By setting a fixed time period and acquiring transaction information in the time period, the blockchain system can be prevented from being in a packaging state for a long time, and the packaging efficiency of the data packet is improved.

It should be appreciated that only a scenario is exemplified herein in which N transactions are packaged when each satisfies one of the above conditions. The N transactions may also satisfy any two of the three conditions simultaneously, or all three conditions may be satisfied.

It should be appreciated that the term "first data packet" is introduced herein to embody the final compression of transaction information for multiple transactions into one transaction information. There may also be a second data packet, a third data packet, etc. on the second tier chain, where the second data packet is generated based on the transaction information of the plurality of transactions that satisfy the condition, and the third data packet is also generated based on the transaction information of the plurality of transactions that satisfy the condition. The generation of the other data packets may refer to the generation of the first data packet. For brevity, no further description is provided herein.

Based on step 110, the transaction calculations that were originally performed on the first tier chain may be moved to the second tier chain. The method greatly liberates the computing resources of the first-layer chain and improves the efficiency of processing the data of the first-layer chain. In addition, compared with the scheme that a large amount of time is consumed for generating the evidence while packaging the transaction data, the method and the device for generating the data package do not need to generate the evidence when the first data package is generated, which means that requirements on hardware equipment are wider, cost investment is saved, and data packaging efficiency is higher.

After the first packet is completed in step 110, it needs to be submitted to the consensus nodes on the first tier chain in step 120. Each consensus node thus acknowledges the submitted first data packet by a consensus mechanism to ensure the non-tamper-ability of the data.

Step 120: and sending the first data packet to the first layer chain.

When the first data packet is generated in step 110, the proof corresponding to the first data packet is not generated at the same time. And further, when the first data packet is submitted, the corresponding proof of the first data packet is not submitted.

Illustratively, the blockchain includes a first tier chain and a second tier chain. The first tier chain establishes a connection with the second tier chain through the smart contract. After the packaging of the first data packet is completed, the second-layer chain initiates a submitting application to a plurality of consensus nodes in the first-layer chain based on the intelligent contract, inquires whether the first data packet can be submitted, and after receiving 'agreeing' responses of the plurality of consensus nodes in the first-layer chain, the second-layer chain submits the first data packet to the plurality of consensus nodes on the first-layer chain, and waits for confirmation of the plurality of consensus nodes.

It should be understood that embodiments of the present application are not limited to a particular manner of submitting the first data packet.

It should be noted that, the transaction information on the second layer chain is submitted to the first layer chain, and each transaction information is submitted to pay additional transaction fees (i.e. gas fees). The transaction fee corresponds to a commission fee. For example, the user completes 5 transactions on the second tier chain, sends the 5 transactions one by one to the first tier chain for verification, and needs to pay 5 gas fees, but only needs to pay one gas fee when the 5 transactions are packed into 1 transaction and then uploaded.

Based on step 120, the transaction information of the second layer chain is packaged into the first data packet and then submitted to the first layer chain, so that the expenditure of transaction cost can be greatly reduced.

After submitting the first data packet to the first tier chain in step 120, each consensus node in the first tier chain receives the first data packet and enters the verification process of the first tier chain. A specific verification process is performed at step 130.

Step 130: and carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

Illustratively, all consensus nodes on the first tier chain receive the first data packet uploaded by the second tier chain to verify the validity of the transaction in the first data packet. If each transaction information in the first data packet is verified one by one, the problems of long verification time and low verification efficiency are unavoidable, and if the N transactions are verified at one time, the verification time can be effectively compressed, and the signature verification result can be rapidly given.

It should be noted that, in the embodiment of the present application, the blockchain refers to a federation chain, where nodes on the federation chain are formed by a special organization or inside an enterprise (for example, a blockchain federation formed by a plurality of banks), and read-write rights on the federation chain are limited to forming inside the nodes, which has extremely high security and privacy. The first data packet submitted in step 120 does not contain a certificate, but rather all transaction information is uploaded to the first tier chain, ensuring that user information is not compromised based on the security and privacy of the first tier chain. Moreover, not all nodes on the alliance chain participate in consensus, but part of nodes are selected as consensus nodes, and submitted data are verified and broadcast to all other nodes through the consensus nodes.

In one possible implementation, step 130 includes: and based on a batch signature verification algorithm, carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

Illustratively, the first data packet includes transaction information corresponding to N transactions, and each transaction includes at least signature information. Since the signature information can bind the payer with the transaction information (in the transaction in which the a user transfers to the B user, the signature information of the a user may prove not only the a user himself but also that the a user confirms the transaction behavior to be transferred to the B user), the validity of the transaction can be determined by verifying a plurality of signature information. Furthermore, the working principle of batch signature verification can be explained by assuming that the first data packet contains 5 transactions, if a one-to-one signature verification mode is adopted, the consensus nodes on the first layer chain need to verify 5 signature information respectively. If a batch signature verification algorithm is used, 5 signature information is preprocessed and aggregated into one signature information, so that the consensus node can verify, and the signature verification speed can be improved.

In one possible implementation manner, based on a batch signature verification algorithm, batch verification is performed on the first data packet on the first layer chain to obtain a verification result, including: aggregating signature information corresponding to the N transactions, and verifying the aggregated signature information; if the aggregated signature information passes verification, outputting a verification result, wherein the verification result is that the first data packet passes verification; and if the aggregated signature information fails to pass the verification, outputting the verification result, wherein the verification result is that the first data packet fails to pass the verification.

Illustratively, signature information corresponding to N transactions in a first data packet is obtained; preprocessing signature information of each transaction in N transactions based on a batch signature verification algorithm, and then carrying out aggregation processing on the preprocessed signature information of the N transactions to obtain aggregated signature information, wherein the aggregated signature information can be regarded as signature information of one transaction; and verifying the aggregated signature information, wherein a verification result of the verification is used for determining whether the first data packet can be stored in the first layer chain.

Rollback processing refers to restoring a program or data to a last correct state when an error occurs in the program or data processing. The rollback processing includes a data rollback processing and a program rollback processing.

In the blockchain system, the data rollback processing refers to the state of forcing each consensus node on the blockchain to rollback to the state before processing the transaction data when the transaction data is failed to check or the blockchain itself is abnormal in the process of checking the validity and the authenticity of the transaction data. For example, a user pays 20 crypto-currency transactions to user B, failing to verify the pass on the first tier chain, the data rollback process forces the first tier chain to return to the state before receiving the transaction data, and forces the second tier chain to return to the state before initiating the transaction, the user B has originally added 20 crypto-currencies to the user B's account, but the data rollback process returns the money to user a's account.

Illustratively, if the verification is passed, that is, each consensus node on the first layer chain confirms that all N transactions in the first data packet have authenticity and validity, each consensus node of the first layer chain records and broadcasts to all other nodes in the coalition chain, so that all other nodes store and update recorded transaction data. Furthermore, the first packet is validated, meaning that the second tier chain is functioning properly. If the verification is not passed, the problem transaction which is not passed is indicated to exist in the N transactions, and the operation of the second-layer chain is abnormal. Each consensus node on the first layer chain refuses to add the first data packet, and any consensus node on the first layer chain initiates a data rollback request, and after each consensus node achieves consensus (i.e. agrees to execute the data rollback request), the first layer chain and the second layer chain are forced to return to the state before the first data packet is generated.

Alternatively, in one possible implementation, the batch signing algorithm is an elliptic curve public key cryptography algorithm meeting the national cryptography specifications, i.e. a national cipher SM2 batch signing algorithm.

It should be understood that the national secret SM2 batch signature verification algorithm is only an example, and in another possible implementation, other batch signature verification algorithms may be used for verification, for example, elliptic curve pairing technology based on bilinear mapping (also referred to as Boneh-Lynn-shack signature algorithm, BLS signature algorithm). The embodiments of the present application are not limited to the type of algorithm used for batch verification.

In the embodiment of the application, a plurality of transactions are initiated in a second-layer chain, and based on a rolling algorithm, the transaction data are compressed and packed into a first data packet, and the first data packet is directly submitted to a first-layer chain for verification under the condition that a certificate is not generated; meanwhile, in order to improve the verification rate, a batch signature verification algorithm is used for carrying out batch verification on signature information corresponding to N transactions so as to obtain verification results; recording the plurality of transaction data in the first tier chain based on the results of the verification pass, and performing a data rollback process on the blockchain based on the first data packet based on the results of the verification fail.

Compared with the method that a large amount of time is spent for generating the evidence when the transaction data is packed, and then the evidence is verified on the first layer chain, the method for directly packing all the transaction data into one transaction data and uploading the transaction data to the first layer chain is quicker, the transaction cost is lower, and the requirement on hardware equipment is not high; compared with a single signature verification mode, the scheme of verifying by using batch signature verification can greatly compress verification time, ensure transaction data security and greatly improve verification speed, further improve throughput of a first layer chain and improve the number of transactions executed per second.

Corresponding to a verification method for a blockchain described in the above embodiments, fig. 3 shows a block diagram of a capacity expansion device for a blockchain provided in an embodiment of the present application, and for convenience of explanation, only a portion related to the embodiment of the present application is shown.

Referring to fig. 3, the capacity expansion device 2 for a blockchain includes: a packaging unit 21, a data submitting unit 22, a verifying unit 23.

In some possible implementations, the packing unit 21 is configured to perform a packing process on N transactions in the second layer chain, and generate a first data packet, where the first data packet includes transaction information corresponding to each transaction in the N transactions, and the transaction information corresponding to each transaction includes one or more of the following information: transaction result information, signature information and state update information, wherein N is a positive integer greater than 1.

Optionally, the N transactions satisfy one or more of the following conditions: the transaction quantity of the N transactions meets a preset packaging threshold; the memory capacity occupied by the N transactions meets the preset memory capacity; the transaction time of the N transactions is within a preset time range.

Optionally, the transaction result information is used for representing a result that the amount of the account related to each transaction changes when each transaction is executed; the signature information is used for representing a signature corresponding to each transaction when the transaction is executed; the state updating information is used for recording the corresponding state of each transaction on the second layer chain in real time when the transaction is executed.

In some possible implementations, the data submitting unit 22 is configured to send the first data packet to the first layer chain.

In some possible implementations, the verification unit 23 performs batch verification on the first data packet on the first layer chain to obtain a verification result.

Optionally, the batch verification of the first data packet on the first layer chain is performed to obtain a verification result, which includes: and based on a batch signature verification algorithm, carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

Optionally, the batch verification is performed on the first data packet on the first layer chain based on a batch verification algorithm to obtain a verification result, including: aggregating signature information corresponding to the N transactions, and verifying the aggregated signature information; if the aggregated signature information passes verification, outputting a verification result, wherein the verification result is that the first data packet passes verification; and if the aggregated signature information fails to pass the verification, outputting the verification result, wherein the verification result is that the first data packet fails to pass the verification.

Optionally, the device 2 further comprises: storing the first data packet in the first layer chain under the condition that the verification result is that the first data packet passes verification; and carrying out data rollback processing on the block chain based on the first data packet under the condition that the verification result is that the first data packet fails the verification result.

It should be understood that, according to the embodiment of the present application, the data disaster recovery device may correspond to the foregoing method embodiment, and the foregoing and other management operations and/or functions of each module in the data disaster recovery device are respectively for implementing corresponding steps of the method in the foregoing method embodiment, so that beneficial effects in the foregoing method embodiment may also be implemented, which is not repeated herein for brevity.

Fig. 4 is a schematic structural diagram of a verification device for blockchain according to an embodiment of the present application. As shown in fig. 4, the verification apparatus 3 for blockchain of this embodiment includes: at least one processor 30 (only one shown in fig. 4), a memory 31, and a computer program 32 stored in the memory 31 and executable on the at least one processor 30, the processor 30, when executing the computer program 32, implementing the steps in any of the various verification method embodiments for blockchain described above.

The verification device 3 for blockchain may be a computing device such as a desktop computer, a notebook computer, a palm computer, a cloud server, etc. The verification means for the blockchain may include, but is not limited to, a processor 30, a memory 31. It will be appreciated by those skilled in the art that fig. 4 is merely an example of a validation apparatus 3 for a blockchain and is not limiting of the validation apparatus 3 for a blockchain, and may include more or fewer components than shown, or may combine certain components, or different components, such as may also include input-output devices, network access devices, etc.

The processor 30 may be a central processing unit (Central Processing Unit, CPU), the processor 30 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 31 may in some embodiments be an internal storage unit of the verification device 3 for blockchain, such as a hard disk or a memory of the verification device 3 for blockchain. The memory 31 may also be an external storage device of the blockchain verification device 3 in other embodiments, for example, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash Card (Flash Card) or the like, which is provided on the blockchain verification device 3. Further, the memory 31 may also include both the internal storage unit and the external storage device of the verification apparatus 3 for blockchain. The memory 31 is used for storing an operating system, application programs, boot loader (BootLoader), data, other programs etc., such as program codes of the computer program etc. The memory 31 may also be used for temporarily storing data that has been output or is to be output.

It should be noted that, because the content of information interaction and execution process between the above devices/units is based on the same concept as the method embodiment of the present application, specific functions and technical effects thereof may be referred to in the method embodiment section, and will not be described herein again.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.

The embodiment of the application also provides a network device, which comprises: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, which when executed by the processor performs the steps of any of the various method embodiments described above.

Embodiments of the present application also provide a computer readable storage medium storing a computer program which, when executed by a processor, implements steps that may implement the various method embodiments described above.

Embodiments of the present application provide a computer program product which, when run on a mobile terminal, causes the mobile terminal to perform steps that may be performed in the various method embodiments described above.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application implements all or part of the flow of the method of the above embodiments, and may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, where the computer program, when executed by a processor, may implement the steps of each of the method embodiments described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to a photographing device/terminal apparatus, recording medium, computer Memory, read-Only Memory (ROM), random access Memory (RAM, random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. Such as a U-disk, removable hard disk, magnetic or optical disk, etc. In some jurisdictions, computer readable media may not be electrical carrier signals and telecommunications signals in accordance with legislation and patent practice.

In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/network device and method may be implemented in other manners. For example, the apparatus/network device embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions in actual implementation, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.

Claims

1. A method of validation for a blockchain, the blockchain including a first tier chain and a second tier chain, the method comprising:

Transmitting the first data packet to the first layer chain;

2. The method of verifying as in claim 1, wherein the step of packaging the N transactions at the second tier chain to generate the first data packet comprises:

3. The authentication method of claim 1, wherein the N transactions satisfy one or more of the following conditions:

the transaction quantity of the N transactions meets a preset packaging threshold;

the memory capacity occupied by the N transactions meets the preset memory capacity;

the transaction time of the N transactions is within a preset time range.

4. The method of verification of claim 1, wherein the transaction outcome information is used to characterize the outcome of a change in the amount of the account associated with each transaction as the transaction is performed; the signature information is used for representing a signature corresponding to each transaction when the transaction is executed; the state updating information is used for recording the corresponding state of each transaction on the second layer chain in real time when the transaction is executed.

5. The authentication method of claim 1, wherein the performing batch authentication on the first data packet on the first layer chain to obtain an authentication result includes:

and based on a batch signature verification algorithm, carrying out batch verification on the first data packet on the first layer chain to obtain a verification result.

6. The authentication method of claim 5, wherein the batch authentication of the first data packet on the first layer chain based on the batch authentication algorithm, to obtain an authentication result, comprises:

aggregating signature information corresponding to the N transactions, and verifying the aggregated signature information;

if the aggregated signature information passes verification, outputting a verification result, wherein the verification result is that the first data packet passes verification;

and if the aggregated signature information fails to pass the verification, outputting the verification result, wherein the verification result is that the first data packet fails to pass the verification.

7. The authentication method of claim 1 or 5, wherein the method further comprises:

storing the first data packet in the first layer chain under the condition that the verification result is that the first data packet passes verification;

And carrying out data rollback processing on the block chain based on the first data packet under the condition that the verification result is that the first data packet fails the verification result.

8. A validation apparatus for a blockchain, the blockchain including a first tier chain and a second tier chain, the validation apparatus comprising: the device comprises a packaging unit, a data submitting unit and a verification unit;

9. The authentication apparatus of claim 8, wherein the packing unit further comprises:

10. An authentication apparatus for a blockchain, comprising a processor and a memory, the processor and the memory coupled, the memory to store a computer program that, when executed by the processor, causes the apparatus to perform the method of any of claims 1 to 7.