WO2021135757A1

WO2021135757A1 - Method and apparatus for executing transaction correctness verification

Info

Publication number: WO2021135757A1
Application number: PCT/CN2020/132060
Authority: WO
Inventors: 林鹏
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-01-02
Filing date: 2020-11-27
Publication date: 2021-07-08
Also published as: CN111242617B; CN111242617A

Abstract

A method for executing transaction correctness verification. The method is executed by a lightweight node in a blockchain system. The method comprises: acquiring, from a full node, consensus proof information of a block to be verified (520), wherein the consensus proof information comprises a digital signature set, and the digital signature set is obtained by means of all consensus nodes that achieve a consensus with regard to the block to be verified signing a first signature data original text corresponding to the block to be verified; on the basis of the digital signature set and a public key set at a lightweight node, verifying the correctness of the consensus proof information (540), wherein the public key set comprises public keys of at least some blockchain nodes in a block system; and on the basis of a correctness verification result of the consensus proof information, determining the correctness of a transaction set in the block to be verified (560).

Description

Method and device for performing transaction correctness verification

Technical field

The embodiments of this specification relate to the field of blockchain technology, in particular, to methods and devices for performing transaction correctness verification.

Background technique

The blockchain system includes full nodes and lightweight nodes. The full amount of nodes maintains complete block chain information, while the lightweight nodes usually only need to maintain the block header information of each block chain. SPV (Simple Payment Verification) is a payment verification technology performed by lightweight nodes based on locally maintained block header information. Lightweight nodes usually use SPV verification technology to verify transactions. If you want to prove that the transaction has been executed correctly, SPV verification needs to include existence verification and correctness verification. SPV verification technology provides an existence verification method, but there are still many difficulties for lightweight nodes to prove that the transaction is executed by the correct consensus node in the correct consensus process. Therefore, there is an urgent need for effective and feasible means to verify the correctness of transactions.

Summary of the invention

In view of the foregoing, the embodiments of this specification provide a method and device for performing transaction correctness verification.

According to one aspect of the embodiments of the present specification, there is provided a method for performing transaction correctness verification. The method is executed by a lightweight node in a blockchain system, and the method includes: obtaining the to-be-verified node from the full amount of nodes. Consensus proof information of the block, the consensus proof information includes a digital signature set, and the digital signature set is the first signature data corresponding to the block to be verified by each consensus node that has reached a consensus on the block to be verified The original text is signed; based on the digital signature set and the public key set at the lightweight node to verify the correctness of the consensus proof information, the public key set includes at least part of the block system The public key of the block chain node; and based on the correctness verification result of the consensus certification information, the correctness of the transaction set in the block to be verified is determined.

Optionally, in an example, before determining the correctness of the transaction set in the block to be verified based on the verification result of the correctness of the consensus proof information, the method may further include: from the full node Obtaining the block body information of the block to be verified at any location; based on the block body information, verifying the correctness of the block header of the block to be verified at the lightweight node. Based on the verification result of the correctness of the consensus proof information, determining the correctness of the transaction set in the block to be verified includes: the correctness verification result based on the block header and the correctness verification result of the block proof information To determine the correctness of the transaction set in the block to be verified.

Optionally, in an example, verifying the correctness of the consensus certification information based on the digital signature set and the public key set at the lightweight node may include: using each consensus node to sign the original text of the first signature data The encryption algorithm used restores the public key of each consensus node from the set of digital signatures; and verifies the public key of each consensus node based on the restored public key of each consensus node and the set of public keys at the lightweight node. The stated consensus proves the correctness of the information.

Optionally, in an example, based on the restored public key of each consensus node and the public key set at the lightweight node, verifying the correctness of the transaction in the block to be verified may include: When at least part of the restored public keys are included in the public key set and the number of public keys included in the public key set meets the consensus rule, it is determined that the consensus certification information is correct.

Optionally, in an example, the set of public keys may include the public keys of all blockchain nodes participating in the consensus in the blockchain system, or the set of public keys may include The public key of all consensus nodes that conduct consensus at the trust anchor point at the location, and the trust anchor point indicates the trust block that has been verified as correct.

Optionally, in an example, before obtaining the consensus proof information of the block to be verified from the full number of nodes, the method may further include: receiving a transaction correctness verification request for a specified transaction in the transaction set. Obtaining the consensus proof information of the block to be verified from the full number of nodes may include: obtaining the consensus proof information of the block to be verified from the full number of nodes when the transaction correctness verification request is received. The method may further include: verifying whether the specified transaction exists in the transaction set; and based on the correctness verification result of the transaction set and the existence verification result of the specified transaction in the to-be-verified block To determine the correctness of the specified transaction.

Optionally, in an example, before obtaining the consensus proof information of the block to be verified from the full number of nodes, the method may further include: monitoring whether there is a block to be verified that includes the specified transaction. Obtaining the consensus certification information of the block to be verified from the full number of nodes includes: when the block to be verified including the specified transaction is monitored, obtaining the consensus certification information of the block to be verified that is monitored from the full number of nodes.

Optionally, in an example, the method may further include: receiving a transaction correctness verification request for a designated transaction in the transaction set; verifying whether the designated transaction exists in the transaction set; and The correctness verification result of the transaction set and the existence verification result of the designated transaction in the to-be-verified block determine the correctness of the designated transaction.

Optionally, in an example, the blockchain system may be a consortium chain system.

According to another aspect of the embodiments of this specification, a device for performing transaction correctness verification is used for a lightweight node in a blockchain system. The device includes: a consensus certification information acquisition unit, The node obtains the consensus proof information of the block to be verified. The consensus proof information includes a set of digital signatures. The set of digital signatures corresponds to each consensus node that has reached a consensus on the block to be verified. The first signature data is obtained by signing the original text; the consensus certification information verification unit verifies the correctness of the consensus certification information based on the digital signature set and the public key set at the lightweight node, the public key set It includes the public keys of at least part of the blockchain nodes in the block system; and a transaction set verification unit, which determines the correctness of the transaction set in the block to be verified based on the verification result of the correctness of the consensus certification information .

Optionally, in an example, the device may further include: a block body information obtaining unit, which determines the correctness of the transaction set in the block to be verified based on the correctness verification result of the consensus proof information Previously, the block body information of the block to be verified was obtained from the full node; the block header verification unit, based on the block body information, verifies the area of the block to be verified at the lightweight node The correctness of the bulk. The consensus proof information verification unit may determine the correctness of the transaction set in the block to be verified based on the correctness verification result of the block header and the correctness verification result of the block proof information.

Optionally, in an example, the transaction set verification unit may include: a public key restoration module, which uses the encryption algorithm used by each consensus node to sign the original text of the first signature data to restore from the digital signature set The public key of each consensus node; and the consensus certification information verification module verify the correctness of the consensus certification information based on the restored public key of each consensus node and the public key set at the lightweight node.

Optionally, in an example, the consensus certification information verification module may include at least part of the restored public key in the public key set and the public key included in the public key set When the quantity satisfies the consensus rule, it is determined that the consensus certification information is correct.

Optionally, in an example, the set of public keys includes the public keys of all blockchain nodes participating in the consensus in the blockchain system, or the set of public keys includes the The trust anchor is the public key of all consensus nodes that perform consensus, and the trust anchor indicates the trust block that has been verified as correct.

Optionally, in an example, before obtaining the consensus proof information of the block to be verified from the full number of nodes, the device may further include: a verification request receiving unit, which receives that the transaction for the specified transaction in the transaction set is correct Sexual verification request. The consensus proof information obtaining unit obtains the consensus proof information of the block to be verified from all nodes when receiving the transaction correctness verification request. The device may further include: an existence verification unit that verifies whether the specified transaction exists in the transaction set; and a specified transaction correctness determination unit based on the correctness verification result of the transaction set and the specified transaction The existence verification result in the to-be-verified block determines the correctness of the specified transaction.

Optionally, in an example, the device may further include: a block to be verified monitoring unit, which monitors whether there is a block to be verified that includes the specified transaction before obtaining the consensus proof information of the block to be verified from the full number of nodes . The consensus proof information obtaining unit may obtain the monitored consensus proof information of the block to be verified from the full number of nodes when it monitors that there is a block to be verified that includes the designated transaction.

Optionally, in an example, the device may further include: a verification request receiving unit to receive a transaction correctness verification request for a specified transaction in the transaction set; an existence verification unit to verify whether the specified transaction exists In the transaction set; and a designated transaction correctness determination unit, based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the to-be-verified block, determine the designated transaction Correctness.

According to another aspect of the embodiments of this specification, there is also provided a computing device, including: at least one processor; and a memory, the memory stores instructions, and when the instructions are executed by the at least one processor, the At least one processor executes the method as described above.

According to another aspect of the embodiments of the present specification, there is also provided a non-transitory machine-readable storage medium, which stores executable instructions, which when executed cause the machine to execute the method as described above.

Using the method and device of the embodiments of the present specification, the correctness of the transaction set on the block to be proven can be verified by verifying the consensus proof information of the block to be verified, so that the lightweight node can be used without accessing multiple full nodes. Verify the correctness of the transaction.

Description of the drawings

By referring to the following drawings, a further understanding of the nature and advantages of the contents of the embodiments of this specification can be achieved. In the drawings, similar components or features may have the same reference signs. The accompanying drawings are used to provide a further understanding of the embodiments of the present invention, and constitute a part of the specification. Together with the following specific implementations, they are used to explain the embodiments of the embodiments of the specification, but do not constitute an example of the embodiments of the specification. limit.

FIG. 1 shows a schematic diagram of an example of an environment that can be used to execute a method for performing transaction correctness verification according to an embodiment of the present specification;

FIG. 2 shows a schematic diagram of an example of a system architecture for executing the method for performing transaction correctness verification according to an embodiment of the present specification;

Figure 3 shows a flowchart of an example of a consensus process applicable to a blockchain system;

FIG. 4 shows a schematic diagram of an example of a blockchain system to which the method for performing transaction correctness verification according to an embodiment of the present specification is applicable;

Fig. 5 is a flowchart of a method for performing transaction correctness verification according to an embodiment of the present specification;

Fig. 6 is a flowchart of an example of a consensus proof information verification process in a method for performing transaction correctness verification according to an embodiment of the present specification;

Fig. 7 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification;

Fig. 8 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification;

FIG. 9 is a schematic diagram for explaining the transaction existence verification process in the method for performing transaction correctness verification according to an embodiment of the present specification;

Fig. 10 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification;

FIG. 11 is a structural block diagram of a device for performing transaction correctness verification according to an embodiment of the present specification;

FIG. 12 is a structural block diagram of the consensus proof verification process in the device for performing transaction correctness verification shown in FIG. 11; and

Fig. 13 is a structural block diagram of a computing device for implementing a method for verifying the correctness of a transaction according to an embodiment of the present specification.

Detailed ways

The subject described herein will be discussed below with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and realize the subject described herein, and is not to limit the scope of protection, applicability, or examples set forth in the claims. The function and arrangement of the discussed elements can be changed without departing from the protection scope of the content of the embodiments of this specification. Various examples can omit, substitute, or add various procedures or components as needed. In addition, features described with respect to some examples can also be combined in other examples.

As used herein, the term "including" and its variations mean open terms, meaning "including but not limited to". The term "based on" means "based at least in part on." The terms "one embodiment" and "an embodiment" mean "at least one embodiment." The term "another embodiment" means "at least one other embodiment." The terms "first", "second", etc. may refer to different or the same objects. Other definitions can be included below, whether explicit or implicit. Unless clearly indicated in the context, the definition of a term is consistent throughout the specification.

In this document, the term "connected" refers to direct mechanical connection, communication or electrical connection between two components, or indirect mechanical connection, communication or electrical connection through intermediate components. The term "electrically connected" refers to the possibility of electrical communication between two components for data/information exchange. Similarly, the electrical connection may refer to a direct electrical connection between two components, or an indirect electrical connection through an intermediate component. The electrical connection can be implemented in a wired manner or a wireless manner.

The method and device for performing transaction correctness verification according to the embodiments of this specification will now be described with reference to the accompanying drawings.

Blockchain is a chain data structure that connects and combines data blocks sequentially in chronological order, and cryptographically ensures that the data blocks cannot be tampered with or forged. The blockchain includes one or more blocks. Each block in the blockchain is linked to the previous block by including the cryptographic hash of the immediately preceding block in the blockchain. Each block also includes a timestamp, a cryptographic hash of the block, and one or more transactions. The transaction that has been verified by the blockchain node is hashed and a Merkle tree is formed. In the Merkle tree, the data at the leaf nodes is hashed, and for each branch of the Merkle tree, all the hash values of the branch are concatenated at the root of the branch. The above processing is performed on the Merkle tree until the root node of the entire Merkle tree. The root node of the Merkle tree stores hash values representing all data in the Merkle tree. When a hash value claims to be a transaction stored in the Merkle tree, it can be quickly verified by judging whether the hash value is consistent with the structure of the Merkle tree.

Blockchain is a data structure used to store transactions. The blockchain network is a network of computing nodes used to manage, update and maintain one or more blockchain structures. As mentioned above, the blockchain network can include a public blockchain network, a private blockchain network, or a consortium blockchain network.

In the public blockchain network, the consensus process is controlled by the nodes of the consensus network. For example, there may be thousands of entities in a public blockchain network for collaborative processing, and each entity operates at least one node in the public blockchain network. Therefore, the public blockchain network can be considered as a public network of participating entities. In some examples, most entities (nodes) must sign each block in sequence, and add the signed block to the blockchain of the blockchain network. Examples of public blockchain networks may include specific peer-to-peer payment networks. In addition, the term "blockchain" does not specifically refer to any particular blockchain.

The public blockchain network supports public transactions. Public transactions are shared among all nodes in the public blockchain network and stored in the global blockchain. A global blockchain refers to a blockchain that is replicated across all nodes. In order to reach a consensus (for example, agree to add a block to the blockchain), a consensus agreement is implemented in the public blockchain network. Examples of consensus protocols include but are not limited to: proof-of-work (POW), proof-of-stake (POS), and proof-of-authority (POA). In the embodiments of this specification, POW is used as a non-limiting example.

Private blockchain networks are provided for specific entities. The read and write permissions of each node in the private blockchain network are strictly controlled. Therefore, a private blockchain network is usually also called a permissioned network, which restricts who is allowed to participate in the network and the level of network participation (for example, only in certain transaction situations). In a private blockchain network, various types of access control mechanisms can be used (for example, existing participants vote to add new entities, regulatory agencies control permissions, etc.).

The alliance blockchain network is private among participating entities. In the alliance blockchain network, the consensus process is controlled by authorized nodes. For example, a consortium composed of several (for example, 10) entities (for example, financial institutions, insurance companies) can operate a consortium blockchain network, and each entity operates at least one node in the consortium blockchain network. Therefore, the consortium blockchain network can be considered as a private network of participating entities. In some examples, each participating entity (node) must sign each block in sequence and add the block to the blockchain. In some examples, each block may be signed by a subset of participating entities (nodes) (for example, at least 7 entities), and the block may be added to the blockchain.

Blockchain is a tamper-proof shared digital ledger that records transactions in a public or private peer-to-peer network. The ledger is distributed to all member nodes in the network, and the history of asset transactions that occurred in the network is permanently recorded in the block.

The consensus mechanism ensures that all blockchain nodes in the distributed blockchain network execute transactions in the same order and then write to the same ledger.

FIG. 1 shows a schematic diagram of an example of an environment 100 that can be used to execute a method for performing transaction correctness verification according to an embodiment of the present disclosure. In some examples, the environment 100 enables entities to participate in the blockchain network 102. As shown in FIG. 1, the environment 100 includes a network 104, and computing devices/

systems

106, 108. In some examples, the network 104 may include a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connect a website, a user device (eg, a computing device), and a back-end system. In some examples, the network 104 may be accessed through a wired and/or wireless communication link. In some examples, the computing devices/

systems

106 and 108 communicate with each other through the network 104, and communicate with the blockchain network 102 through the network 104, and the nodes (or node devices) in the blockchain network 102 pass through The network 104 communicates. Generally, the network 104 represents one or more communication networks. In some cases, the computing devices/

systems

106, 108 may be nodes of a cloud computing system (not shown), or each computing device/

system

106, 108 may be a separate cloud computing system, including interconnection through the network 104 Multiple computers and used as a distributed processing system.

In the illustrated example, each of the computing devices/

systems

106, 108 may include any suitable computing system capable of participating as a node in the blockchain network 102. Examples of computing devices/systems include, but are not limited to, servers, desktop computers, notebook computers, tablet devices, smart phones, etc. In some examples, one or more computer-implemented services for interacting with the blockchain network 102 may be installed on the computing device/

system

106, 108. For example, the computing device/system 106 may be installed with the services of the first entity (for example, user A), for example, the first entity is used to manage transactions with one or more other entities (for example, other users). Management system. The computing device/system 108 may be installed with services of a second entity (for example, user B), for example, a transaction management system used by the second entity to manage transactions with one or more other entities (for example, other users) . In the example of FIG. 1, the blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing devices/

systems

106, 108 serve as the nodes of the first entity and the second entity participating in the blockchain network 102, respectively.

FIG. 2 shows a schematic diagram of an example of a system architecture 200 that executes the method for performing transaction correctness verification according to an embodiment of the present disclosure. An example of the system architecture 200 includes the

participant systems

202, 204, and 206 corresponding to the participant A, the participant B, and the participant C, respectively. Each participant (eg, user, enterprise) participates in the blockchain network 212 provided as a peer-to-peer network. The blockchain network 212 includes a plurality of nodes 214, wherein at least some of the nodes 214 record information in the blockchain 216, and the recorded information cannot be changed. Although a single blockchain 216 is schematically shown within the blockchain network 212, multiple copies of the blockchain 216 may be provided, and multiple copies are maintained in the blockchain network 212, as described in detail later of.

In the example shown, each

participant system

202, 204, 206 is provided by participant A, participant B, and participant C, or provided as participant A, participant B, and participant C, respectively. And it serves as the corresponding node 214 in the blockchain network 212. As used herein, a node generally refers to a single system (for example, a computer, a server) connected to the blockchain network 212 and enables corresponding participants to participate in the blockchain network. In the example shown in FIG. 2, the participant corresponds to each node 214. However, one participant can operate multiple nodes 214 within the blockchain network 212, and/or multiple participants can share a single node 214. In some examples, the

participant systems

202, 204, 206 use protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and/or use remote procedure calls (RPC) to communicate with the blockchain network 212, or through the blockchain The chain network 212 communicates.

The degree of participation of the node 214 in the blockchain network 212 may vary. For example, some nodes 214 may participate in the consensus process (eg, as miner nodes that add blocks to the blockchain 216), while other nodes 214 do not participate in the consensus process. As another example, some nodes 214 store a complete copy of the blockchain 216, while other nodes 214 only store a partial copy of the blockchain 216. In the example of Figure 2, the

participant systems

202, 204, 206 each store a complete copy of the blockchain 216 216', 216", 216"'.

A blockchain (for example, the blockchain 216 in FIG. 2) is composed of a series of blocks, and each block stores data. Examples of data may include transaction data representing transactions between two or more participants. In this disclosure, transactions are used as a non-limiting example, and it is expected that any appropriate data can be stored in the blockchain (e.g., documents, images, videos, audios). Examples of transactions may include, but are not limited to, the exchange of valuable things (eg, assets, products, services, currency, etc.). Transaction data is stored immutably in the blockchain.

Before storing in the block, hash the transaction data. Hashing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). After the transaction data is hashed, even a slight change in the transaction data will result in a completely different hash value. The hash value is usually generated by hashing transaction data using a hash function. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

The transaction data of multiple transactions can be stored in the block after being hashed. For example, two transaction data are hashed to obtain two hash values, and then the two obtained hash values are hashed again to obtain another hash value. This process is repeated until a single hash value is obtained for all transactions to be stored in the block. This hash value is called the Merkle root hash and is stored at the head of the block. Any change in the transaction will cause its hash value to change, and eventually the Merkle root hash value will change.

The block is added to the blockchain through a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol, and after competition, blocks are added to the blockchain. Such nodes are called miner nodes (or accounting nodes). The POW introduced above serves as a non-limiting example.

Miner nodes perform a consensus process to add transactions (corresponding blocks) to the blockchain. Although multiple miner nodes participate in the consensus process, only one miner node can write a block to the blockchain. In other words, miner nodes compete in the consensus process to add their blocks to the blockchain. In more detail, the miner node periodically collects pending transactions from the transaction pool (for example, until a predetermined limit on the number of transactions that can be included in the block is reached, if any). The transaction pool includes transaction messages from participants in the blockchain network. Miner nodes create blocks and add transactions to the blocks. Before adding the transaction to the block, the miner node checks whether there is a transaction in the block of the blockchain among the transactions to be added. If the transaction has been added to another block, the transaction will be discarded.

The miner node generates a block header, hashes all transactions in the block, and combines the hash values in pairs to generate further hash values until a single hash value (Merkle root) is obtained for all transactions in the block. Hash). Then, add the Merkle root hash to the block header. The miner also determines the hash value of the latest block in the blockchain (ie, the last block added to the blockchain). Miner nodes can also add random values (noune values) and timestamps to the block header. During the mining process, the miner node tries to find a hash value that meets the required parameters. The miner node keeps changing the nonce value until it finds a hash value that meets the required parameters.

Every miner in the blockchain network tries to find a hash value that meets the required parameters and competes with each other in this way. Finally, a miner node finds a hash value that meets the required parameters and advertises the hash value to all other miner nodes in the blockchain network. Other miner nodes verify the hash value, and if it is determined to be correct, verify each transaction in the block, accept the block, and attach the block to their copy of the blockchain. In this way, the global state of the blockchain is agreed upon on all miner nodes within the blockchain network. The above process is a POW consensus protocol.

In the example provided in Figure 2, participant A wants to send a certain amount of funds to participant B. Participant A generates a transaction message and sends the transaction message to the blockchain network, and the transaction message is added to the transaction pool. Each miner node in the blockchain network creates a block, obtains transactions from the transaction pool, and adds the transaction to the block. In this way, the transaction issued by participant A is added to the block of the miner node.

In some blockchain networks, cryptography is implemented to maintain the privacy of transactions. For example, if two nodes want to maintain the privacy of the transaction so that other nodes in the blockchain network cannot learn the details of the transaction, the node can encrypt the transaction data. Examples of encryption methods include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to the encryption process that uses a single key to encrypt (generate ciphertext based on plaintext) and decrypt (generate plaintext based on ciphertext). In symmetric encryption, multiple nodes can use the same key, so each node can encrypt/decrypt transaction data.

In asymmetric encryption, a key pair is used for encryption and decryption, and each key pair includes a different private key and public key. For a node, the private key in its asymmetric encryption key pair needs to be stored confidentially; the public key can be made public for other nodes to obtain. If the data is encrypted with a public key, only the corresponding private key can be used to decrypt it. For example, refer to Figure 1 again. Participant A can use the public key of participant B to encrypt data, and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) sent from participant A and decrypt the original data (plaintext). Messages encrypted with the public key of the node can only be decrypted with the corresponding private key in the paired secret key.

Asymmetric encryption can also be used to provide digital signatures, which enable participants in a transaction to confirm other participants in the transaction and the validity of the transaction. For example, participant A can digitally sign the message, and another participant B can confirm that the message was sent by the participant A according to the digital signature of the participant A. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, refer to Figure 1 again. Participant A will send a message to participant B. Participant A generates a hash value of the message, and then uses its private key to encrypt the hash value to generate a digital signature. Participant A attaches the digital signature to the message, and sends the message with the digital signature to participant B. Participant B uses the public key of participant A to decrypt the digital signature, thereby decrypting the corresponding hash value. Participant B hashes the received message to obtain another hash value, and then compares the two hash values. If the hash value is the same, participant B can confirm that the message is indeed from participant A and has not been tampered with.

In the embodiment of this specification, the blockchain node can be any participant in FIG. 1 or FIG. 2.

FIG. 3 shows a schematic diagram of an example of a consensus process 300 applicable to a blockchain system. As shown in Figure 3, C represents the client (ie, lightweight node), R ₀ is the master node of the current consensus process of the blockchain system, and R ₁ , R ₂ and R ₃ are backup nodes.

In the request phase 310, the client C can _{send a transaction request (Request) to the master node R 0.} In addition, the client C can also send to other nodes in the blockchain system (for example, R ₁ , R ₂ and R ₃ ) The transaction request (not shown in FIG. 3), and then the other node forwards the received transaction request to the master node R ₀ .

After receiving the transaction request (Request), the master node R ₀ and the backup nodes R ₁ , R ₂ and R ₃ perform consensus processing. The process of consensus processing includes: a pre-prepare phase (pre-prepare) 320, a preparation phase (prepare) 330, and a confirmation phase (commit) 340.

In the pre-preparation stage 320, after receiving a certain number of transaction requests, the master node R ₀ sorts and packages the received transactions into a message m, and then generates a pre-prepare message (Pre-prepare), and in a given time interval Inside, the pre-prepare message (Pre-prepare) is sent (for example, broadcast) to the backup nodes R ₁ , R ₂ and R ₃ . The pre-prepare message (Pre-prepare) indicates that the master node R ₀ is starting the consensus process.

As shown in Figure 3, the master node R0 sends a Pre-prepare message to other blockchain nodes R1, R2, and R3 in the blockchain network. Note that the consensus process 300 is shown as including 4 blockchain nodes R0, R1, R2, and R3 for illustration purposes only, and the consensus process 300 may also include any suitable number of blockchain nodes.

In the preparation phase 330, for each backup node (R ₁ , R ₂ or R ₃ ), after receiving the pre-preparation message and verifying that the pre-preparation message is legal, the pre-preparation message can be stored in the local log and generated for In response to the preparation message Prepare of the pre-preparation message, the generated preparation message Prepare is broadcast to other nodes. The preparation message Prepare indicates that the backup node has received the pre-prepare message Pre-prepare from the master node, and is sending a response in response to the pre-prepare message Pre-prepare.

Correspondingly, each backup node will also receive pre-preparation messages sent by other backup nodes. In the backup nodes R ₁ as an example, then the backup nodes R ₁ R ₀ master node receives the message transmitted from a prepared, ready to broadcast a message will be generated to the master node R _0, R ₂ and backup node R _3. Correspondingly, the backup node R ₁ will also receive the preparation messages sent by the _{master node R 0} and the backup nodes R ₂ and R _3.

In the confirmation stage 340, when the blockchain node receives a sufficient number of prepare messages from other blockchain nodes, the blockchain node determines that a consensus has been reached. For example, if the master node R0 or the backup node R1, R2 or R3 receives a quorum (for example, 2f+1, where f represents multiple failed blockchain nodes) to prepare the message Prepare, it is determined to be in the blockchain A consensus is reached between nodes. Then, the master node R0 or the backup nodes R1, R2, or R3 will broadcast a confirmation message Commit to other nodes.

In the response stage 350, after reaching a consensus on the initiated proposal, each of all nodes participating in the consensus sequentially executes a set of ordered requests in the message m of the pre-prepare message in the local state machine, and returns a response Message reply to client C.

The format of the message data sent at each stage in FIG. 3 can refer to common knowledge in the art. In addition, FIG. 3 is only an example of the consensus process, and the blockchain system in the embodiment of this specification can adopt any suitable common adaptation process to perform consensus processing.

FIG. 4 shows a schematic diagram of an example of a blockchain system to which the method for performing transaction correctness verification according to an embodiment of the present specification is applicable.

As shown in FIG. 4, the blockchain system 400 includes light nodes and full nodes. The full nodes include

blockchain nodes

401, 402, etc., and the light nodes are connected to one or more full nodes. For example, the blockchain nodes 401a, 401b, and 401c, which are lightweight nodes, are connected to the full node 401, and the blockchain nodes 402a, 402b, and 402c are connected to the full node 402. Each full node in the blockchain system 400 is connected to each other, and each full node can be used as a bookkeeping node (that is, a consensus node) to jointly maintain a ledger of all transactions in the blockchain system based on the blockchain technology. The accounting node can perform accounting operations such as transaction verification, transaction consensus, and block generation. Full nodes usually maintain all the data of the blockchain locally, including the block body and block header of each block in the blockchain. Lightweight nodes can only store the block headers of each block in the blockchain locally for simple verification operations (for example, SPV verification). Lightweight nodes can always be connected to the same full number of nodes, and can also replace all connected nodes based on connection rules to reduce trust risks.

Transactions initiated by each blockchain node can be broadcast to the blockchain network for consensus processing. The transaction initiated by the full node can be broadcast to each other full node, and after each full node receives the transaction, it can be broadcast to the lightweight node it is connected to. The transaction initiated by the light-weight node can be sent to all nodes connected to the light-weight node, so as to be broadcast by the all-weight node to other full-weight nodes or light-weight nodes. Lightweight nodes can download block headers from the full number of nodes connected to it to maintain the local blockchain (blockchain that only includes block headers), and can also obtain the block body from the full number of nodes according to the needs of their own operations Various information. Lightweight nodes can connect to one or more clients (not shown in the figure). The transaction initiated by the client can be sent to the blockchain system via the lightweight node and all nodes connected to the lightweight node to perform accounting processing on the transaction.

The method for performing cross correctness verification in the embodiment of this specification is executed by a lightweight node.

Fig. 5 is a flowchart of a method for performing transaction correctness verification according to an embodiment of the present specification.

As shown in FIG. 5, at block 520, the consensus proof information of the block to be verified is obtained from all nodes. Consensus proof information can be included in the block body of the block to be verified. Lightweight nodes can obtain the consensus proof information of the block to be verified from any full node connected to it. Lightweight nodes can send consensus proof information acquisition requests to all nodes, so that all nodes can send the consensus proof information to the light nodes. In another example, the lightweight node may obtain consensus proof information from the block body after downloading the block body of the block to be verified. The consensus proof information includes a collection of digital signatures. The digital signature set is obtained by signing the original text of the first signature data corresponding to the block to be verified by each consensus node that has reached a consensus on the block to be verified. The consensus node can be any full node in the blockchain system. According to different consensus algorithms, the information in the original text of the first signature data can also be different. In an example, the original text of the first signature data may include proof summary information, and the proof summary information is generated at each consensus node based on the first proof basis information.

Consensus proof information is used to prove that the corresponding block has been executed by the correct consensus node in the correct consensus process. For example, in the PBFT-based consensus algorithm, it can be proved that the corresponding block has been confirmed by no less than a quorum of consensus nodes. Each consensus node can generate a digital signature when reaching a consensus on the corresponding block, and when the block is added to the blockchain, the digital signature of each consensus node can be assembled into a digital signature set to generate consensus proof information.

Taking the consensus process shown in Figure 3 as an example, when each consensus node receives a preparation message of no less than a statutory number in the confirmation phase 340, it can generate proof summary information based on the first proof basis information obtained locally, and then use each The private key to sign the certificate summary information to generate their respective digital signatures. After the digital signature is generated, each consensus node can include the digital signature in the confirmation message and broadcast it to other consensus nodes. After each consensus node receives a sufficient number (not less than f+1) of confirmation messages, it can assemble and generate consensus proof information based on the digital signatures of each consensus node confirming the block, and include the consensus proof information In the block body of the corresponding block.

As an example, the proof basis information used to generate the proof summary information may include the public key set identification information generated based on the public key set of the corresponding block, the number of public keys in the public key set, the parent hash of the block to be verified, and the The root hash of the transaction tree of the verification block and the timestamp of the block to be verified. The public key set includes the public keys of all consensus nodes participating in the consensus process of the corresponding block. When the corresponding block reaches a consensus, the public key of each consensus node that agrees on the block can be obtained to generate a public key set corresponding to the block, and then it can be generated based on each public key in the public key set Public key collection identification information and the number of public keys. In an example, the Merkel tree can be generated based on each public key, and the root hash of the Merkel tree can be used as the public key set identification information. In another example, a hash operation may be performed on the public key set, and the obtained hash value may be used as the public key set identifier. The parent hash of each block (the hash value of the parent block), the root hash of the transaction tree, and the timestamp can be obtained from the block header information of the locally maintained blockchain. In order to distinguish, in this specification, the proof basis information obtained locally by each consensus node when generating the signature data is described as the first proof basis information, and the proof basis information acquired locally by the lightweight node when verifying the correctness of the transaction is described as The second proof is based on information, but the categories of information included in the first and second proof based information are the same.

In an example, the consensus node may use a digest algorithm to perform a digest operation on the first proof basis information used to generate the proof summary information to obtain the proof summary information. The proof digest algorithm can be a hash operation or any other digest algorithm, which is not limited in this specification. After obtaining the proof summary information, the consensus node can generate the first original signature text information based on the proof summary information. For example, the proof summary information can be used as the first original signature text information, and the proof summary information can be further subjected to a predetermined calculation process (for example, a hash operation) to generate the first original signature text information. Then, the respective private keys can be used to sign the first signed original text information to obtain a digital signature.

The proof basis information may also include the serial number of the block to be verified in the blockchain. Depending on the consensus algorithm used in the blockchain system, the proof basis information can also include other information. For example, in a consortium chain, for a consensus algorithm such as PBFT that has a master node and node replacement, the proof basis information may also include the consensus era (View) identification of the block to be verified. The consensus era refers to the corresponding time period in which a certain consensus node acts as the master node in the blockchain system. Whenever the master node cannot normally perform the operations that the master node should perform, the blockchain system can trigger the master node replacement process. After the master node is replaced, the blockchain system enters another consensus era. The consensus node can hash the proof basis information, use the obtained hash value as the original text of the first signature data, and then use the respective private keys to encrypt the original text of the first signature data to generate the corresponding digital signature.

After the lightweight node obtains the consensus certification information of the block to be verified, in block 540, the correctness of the consensus certification information is verified based on the digital signature set and the public key set at the lightweight node. The lightweight node can store a set of public keys locally. The public key set at the lightweight node may include the public keys of all nodes participating in the consensus in the blockchain system, and may also include the public keys of each consensus node that agrees on the trust anchor. The trust anchor can indicate a trust block that has been verified as correct. The trust anchor can be the genesis block, and the set of public keys corresponding to the genesis block can be the public keys of all consensus nodes in the blockchain system when the genesis block is generated. When the trust block is not the genesis block, the trust block can be verified using the transaction correctness verification method in the embodiment of this specification. When the transaction set in the block to be verified is verified as correct, the block to be verified can be updated as a new trust anchor point, and the public key of each consensus node that agrees on the block to be verified can be updated to trust The anchor's public key collection.

Fig. 6 is a flowchart of an example of a consensus proof information verification process in a method for performing transaction correctness verification according to an embodiment of the present specification.

As shown in FIG. 6, in block 602, based on the digital signature set, the encryption algorithm used by each consensus node to sign the original text of the first signature data is used to restore the public key of each consensus node from the digital signature set. In the case of generating a public-private key pair using, for example, an elliptic curve algorithm, the public key is generated based on the private key. Therefore, the corresponding public key can be restored based on the digital signature. The digital signature can include information used to restore the public key. Taking the SM2 elliptic curve algorithm as an example, the digital signature can include the coordinates (x, y) of the elliptic curve point and the judgment identifier, which is used to judge the parity of the coordinate y of the elliptic curve point. Lightweight nodes can recover the public key of the corresponding consensus node based on the coordinates of the elliptic curve point and the judgment identifier. The consensus proof information may also include the original text of the first signature data, and the coordinates of the elliptic curve point and the judgment identifier may be included in the original text of the first signature data. The public key can be further recovered based on the original text of the first signature data.

After each public key is restored, in block 604, based on the restored public key of each consensus node and the public key set at the lightweight node, the correctness of the consensus certification information is verified. Lightweight nodes can verify the correctness of the consensus proof information based on the consensus rules corresponding to the block to be verified. For example, for certain consensus algorithms, it can be determined that the consensus certification information is correct when each restored public key is included in the public key set. If the restored public key is included in the public key set, it indicates that the block to be verified has passed the consensus of the correct consensus node. If the restored public key is not included in the public key set, or part of it is not included in the public key set, it indicates that the block to be verified is not in the correct consensus node consensus. In a consensus algorithm such as PDFT, it is possible to restore the public key from the digital signature when it is determined that the number of digital signatures in the consensus certification information is not less than the legal number. It can also be further determined whether the number of original public keys returned has reached a quorum. Then, it can be determined that the consensus certification information is correct when each of the restored public keys is included in the public key set and the number of public keys reaches a quorum.

In one example, even if the restored public key is not completely included in the public key set, if at least part of the restored public key is included in the public key set, and is included in the public key set The number of public keys meets the consensus rules of the consensus algorithm for reaching a consensus, and it can also be determined that the block to be verified has been correctly agreed. For example, for a consensus algorithm based on PDFT, if the number of public keys included in the public key set reaches a quorum, it can also prove that the block to be verified has been correctly agreed. Therefore, it can be determined that the consensus certification information is correct when the number of restored public keys included in the public key set reaches a quorum.

Lightweight nodes can determine the verification rules of the consensus proof information based on the consensus rules corresponding to the consensus algorithm. For example, if the consensus algorithm is the PBFT algorithm, it is necessary to confirm that the consensus certification information is correct when the restored public key is included in the public key set and the number of restored public keys reaches a quorum. The consensus algorithm may be known to lightweight nodes. In another example, the consensus algorithm can be included in the consensus proof information, so that the lightweight node can learn the verification rules from the consensus proof information.

In addition, when the consensus proof information includes the original text of the first signature data, the lightweight node can also verify the original text of the first signature data in the consensus proof information. The light-weight node may locally obtain the second proof basis information used to generate the original text of the signature data, and generate the second original signature data text based on the second proof basis information and the generation rules of the first signature data original text. However, it can be determined whether the original text of the first signature data is correct based on the consistency between the original text of the first signature data and the original text of the second signature data. When the two are consistent, it can be determined that the original text of the first signature data is correct. In an example, when the original text of the first signature data is verified as correct, the public key can be recovered from the digital signature.

After verifying the consensus proof information, in block 560, based on the correctness verification result of the consensus proof information, the correctness of the transaction set in the block to be verified is determined. When the consensus proof information is verified as correct, it indicates that the transactions in the block to be verified have gone through the correct consensus process. Therefore, it can be determined that the block body of the block to be verified is correct, and then each of the block bodies can be considered The transactions are all correct.

Through the above embodiments, the lightweight node does not need to visit multiple full nodes to verify the correctness of the transaction set on the block to be verified. For example, in a blockchain system that uses a consensus algorithm such as PBFT, if the correctness verification method in this manual is not used, the lightweight node needs to visit multiple full nodes to determine whether the block to be verified is quorum correct The nodes agree correctly. However, in practice, it is difficult for a lightweight node to connect to multiple full nodes, so it is difficult to successfully complete the correctness verification.

In another example, the block header of the block to be verified can also be verified, and it is determined that each transaction in the block to be verified is correct when both the block header and the transaction set in the block body are verified as correct. This example will be explained below with reference to FIG. 7. Fig. 7 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification.

As shown in FIG. 7, in

blocks

702 and 704, the correctness of the consensus certification information is verified. The verification process of the consensus certification information described in this manual can be used to verify the correctness of the consensus certification information. When the consensus proves that the information is correct, it can be determined that the block body is correct.

If the verification result of the consensus proof information is correct, then in block 706, the block body information of the block to be verified is obtained from all nodes. Then, in block 708, based on the block body information, the correctness of the block header of the block to be verified at the lightweight node is verified. And in block 710, it is determined whether the block header is correct.

All block body information can be downloaded from all nodes, and then the transaction tree information can be extracted from the block body information. It is also possible to obtain transaction tree information only from all nodes. After obtaining the transaction tree information, the transaction root in the block header can be verified based on the transaction tree information. The transaction tree may be generated based on a Merkle tree, for example. In the Merkle tree, the leaf nodes store transaction data of each transaction in the block to be verified. The upper node of the binary fork can be calculated layer by layer based on each leaf node, until the Merkle root is calculated. Then you can compare whether the calculated merkle root is consistent with the transaction root in the block header. When the two are consistent, it can be determined that the block header is correct. In addition, for the case where the block body also includes the receipt tree and the state tree, the block header also includes the receipt root and the state root. In this example, you can also verify the receipt root and state root in the block header after obtaining the receipt tree information and state tree information, and when the transaction root, receipt root, and state root are all verified as correct, determine the area The bulk is correct. The receipt tree and the state tree can also be generated based on the Merkle tree. The Merkle roots of the receipt tree and the state tree can be calculated based on the obtained receipt tree information and state tree information, and the Merkle roots obtained by the two can be compared with the zone respectively. The receipt root in the block header is consistent with the state root. When the calculated Merkle root is consistent with the receipt root and state root, it can be determined that the receipt root and state root are correct. In the case where the block body also includes the receipt tree and the state tree, the receipt root and the state root may not be verified.

When the block header and block body of the block to be verified are verified as correct, it can be determined that the block to be verified is correct, and then all transactions in the block body can be considered correct. Therefore, at block 712, it is determined that the set of transactions on the block to be verified is correct. If the verification result of the block header or the consensus proof information is incorrect, then in block 714, it is determined that the transaction set on the block to be verified is incorrect. In order to save storage space at the lightweight node, after verifying the transaction set on the block to be verified, the obtained block body information can be deleted. When the transaction set on the block to be verified is verified as correct, the block to be verified can be updated as a trust anchor.

Although FIG. 7 shows that the block header verification process is performed after the consensus certification information is verified as correct, there is no restriction on the execution sequence of the consensus certification information verification process and the block header verification process. In another example, the two can be executed in parallel, and the consensus proof information verification process can also be executed after the block header information is verified as correct.

When the set of transactions in the block to be verified is verified as correct, if you want to verify the correctness of the specified transaction in the block to be verified, you can verify whether the specified transaction exists in the block to be verified. If the designated transaction exists in the block to be verified (that is, the existence of the designated transaction is verified), since all transactions in the block to be verified have been determined to be correct, it can be determined that the designated transaction is also correct. Hereinafter, the process of verifying the correctness of the specified transaction will be described with reference to FIGS. 8 to 10.

Fig. 8 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification.

As shown in FIG. 8, at block 802, a transaction correctness verification request for a specified transaction in the transaction set is received. The transaction correctness verification request may be issued by a client connected to a lightweight node. The client can send a transaction correctness verification request to the lightweight node for the transaction initiated by it. The transaction correctness verification request may include the transaction hash of the designated transaction and the block number of the designated transaction in the block. The transaction hash and block number can be notified to the client through the lightweight node after the full node has packaged the specified transaction on the chain. The block number is used to determine the block in which the specified exchange is located, and the transaction hash can be used to verify the existence of the specified transaction. In another example, the transaction correctness verification request may not include the block number. The lightweight node can query the full node based on the transaction hash for the block in which the specified transaction is located, and the full node can send the block number to the lightweight node. node. After determining the block in which the designated exchange is located, the lightweight node determines the block as a block to be verified.

After receiving the transaction correctness verification request, in block 804, the consensus proof information of the block to be verified is obtained from all nodes. Then, in block 806, the correctness of the transaction set in the block body of the block to be verified is determined based on the consensus proof information.

Next, at block 808, the existence of the specified transaction in the block to be verified is verified. After the transaction set verification result and the existence verification result are obtained, in block 810, the correctness of the designated transaction is determined based on the correctness verification result of the transaction set and the existence verification result of the designated transaction. It can be determined that the specified transaction is correct when the transaction set and the existence verification result are correct, that is, the specified transaction has been executed correctly. The execution sequence of the correctness verification process and the existence verification process of the transaction set on the block to be verified is not particularly limited, and the two may also be parallel.

Existence verification (also referred to as existence proof) can be performed by adopting any existence verification methods in the prior art. An example of existence verification will be described below with reference to FIG. 9.

FIG. 9 is a schematic diagram for explaining the transaction existence verification process in the method for performing transaction correctness verification according to the embodiment of the present specification.

Fig. 9 shows an example of a transaction tree generated based on a Merkle tree. The block including the transaction tree includes transactions A to P. Leaf node is stored in each transaction to transaction hash H _A H _P. Lightweight nodes can obtain transaction tree information from the downloaded block body information, and then obtain each leaf node data in the query path of the specified transaction from the transaction tree. Without downloading block body information, lightweight nodes can send transaction tree path query requests for specified transactions to all nodes. The full node can send the leaf node data included in the transaction query path of the specified transaction in the transaction tree to the light node.

Taking transaction K in Figure 9 as an example, the leaf node data in the transaction query path from the leaf node _{where the transaction hash H K of transaction K} is located to the transaction root H _{ABCDEFGHIJKLMNOP} _{includes H L} , H _IJ , H _MNOP , and H _ABCDEFGH. After obtaining the leaf node data, binary calculations can be performed layer by layer to determine whether the obtained transaction root is consistent with the transaction root in the block header of the block to be verified. Specifically, the transaction hash H _K of the designated transaction K is known. Accordingly, it is possible to obtain H _KL H _K H _L is calculated based on, then can be H _IJKL H _KL and H _IJ calculated based on the acquired and can be _H IJKLMNOP H _IJKL and H _MNOP calculated based on the acquired and then, based _H IJKLMNOP H _ABCDEFGH calculated and acquired obtained _H aBCDEFGHIJKLMNOP. Then you can compare whether H _{ABCDEFGHIJKLMNOP} is consistent with the transaction root in the block header. When the two are consistent, it can be determined that the transaction H _{K of the} specified transaction K exists in the transaction tree, which indicates that the transaction K exists in the transaction set of the block to be verified. When the two are inconsistent, it indicates that transaction K is not in the transaction set of the block to be verified.

The verification of the transaction set may be performed before receiving the transaction correctness verification request for the specified transaction. As the transactions processed by the blockchain system increase, new blocks will be continuously generated on the blockchain. Lightweight nodes can download block headers from all nodes according to their own conditions to update local blockchain data. For example, lightweight nodes can download block headers from full nodes periodically and quantitatively. Lightweight nodes can verify the correctness of the transaction set of the block in the process of updating the local blockchain. For example, the correctness of the transaction set can be verified one by one for the blocks added to the local blockchain. In order to reduce the burden of lightweight nodes, lightweight nodes can only verify the associated blocks. The associated block is a block related to the lightweight node. For example, it may include a transaction initiated by a client connected to the lightweight node, and may also include a transaction concerned by the client connected to the lightweight node. After verifying the transaction set, if a transaction correctness verification request for a specified transaction is received, the existence of the specified transaction can be further verified to verify the correctness of the specified transaction. This example will be described below with reference to FIG. 10.

Fig. 10 is a flowchart of a method for performing transaction correctness verification according to another embodiment of the present specification.

As shown in FIG. 10, at block 1002, it is monitored whether there is a block to be verified that includes a specified transaction. And at block 1004, it is determined whether a block to be verified including the specified transaction is monitored. The block header may include transaction receipt identification information, and the transaction receipt identification information may be generated based on the transaction address information in the transaction receipt, for example. The transaction receipt identification information may be generated based on a Bloom filter, for example. After the transaction is executed, the consensus node will write the transaction record into the transaction receipt. The transaction receipt includes information related to the transaction. Lightweight nodes can monitor whether there are blocks that include specified transactions based on Bloom filters. The listening rules can be set by the client. The client can set up and monitor information related to the transaction initiated by the lightweight node. For example, you can monitor transactions where the address of the transaction initiator corresponds to the account address of the client. It is also possible to monitor a specific transaction. For example, if a customer initiates a transaction that transfers money from account address A to account address B, it can be set to monitor the transaction where the transaction initiator address is A and the transaction object address is B. Lightweight nodes can also monitor transactions related to all clients connected to it, for example, can monitor transactions where the address of the transaction initiator corresponds to the account address of the client connected to it. When the monitoring rule is generated based on other information in the transaction information, the transaction receipt identifier can be generated based on the corresponding information in the transaction receipt information.

When the block to be verified including the specified transaction is monitored, at block 1006, the consensus proof information of the block to be verified is obtained from all nodes. Then, in block 1008, the correctness of the transaction set in the block body of the block to be verified is determined based on the consensus proof information. After verifying the correctness of the transaction set on the block to be verified, if the client requests verification of a specific transaction on the block to be verified, it does not need to perform the correctness verification process of the transaction set again, but can only verify whether the specified transaction Exist in the block to be verified for verification.

The lightweight node can verify the transaction correctness request sent by the monitoring client, and in block 1010, determine whether the transaction correctness verification request for the specified transaction has been received. If a transaction correctness verification request is received, in block 1012, the existence of the specified transaction is verified. The existence verification process can be performed using the method described in the above example.

After obtaining the existence verification result and the correctness verification result of the transaction set, in block 1014, the correctness of the designated transaction is determined based on the correctness verification result of the transaction set and the existence verification result of the designated transaction. When the set of transactions on the block to be verified is verified as correct, and the specified transaction exists on the block to be verified, it can be determined that the specified transaction is correct.

After receiving the transaction correctness request, the lightweight node can first determine whether the block in which the designated exchange is located has been subjected to the transaction set correctness verification process. If the block where the designated exchange is located has not performed the transaction set correctness verification process, the example shown in Figure 8 can be used to verify the transaction correctness.

Fig. 11 is a structural block diagram of an apparatus for performing transaction correctness verification according to an embodiment of the present specification. As shown in FIG. 11, the transaction correctness verification execution device 1100 includes a consensus certification information acquisition unit 1110, a consensus certification information verification unit 1120, a transaction set verification unit 1130, a block body information acquisition unit 1140, a block header verification unit 1150, and a verification unit to be verified. The block monitoring unit 1160, the verification request receiving unit 1170, the existence verification unit 1180, and the designated transaction correctness determining unit 1190.

The consensus proof information obtaining unit 1110 obtains the consensus proof information of the block to be verified from all nodes. The consensus proof information includes a set of digital signatures, which are obtained by signing the original text of the first signature data corresponding to the block to be verified by each consensus node that has reached a consensus on the block to be verified. The consensus certification information verification unit 1120 verifies the correctness of the consensus certification information based on the digital signature set and the public key set at the lightweight node. The public key set includes the public keys of at least part of the blockchain nodes in the block system. In an example, the set of public keys may include the public keys of all blockchain nodes participating in the consensus in the blockchain system. In another example, the set of public keys may include the public keys of all consensus nodes that agree on the trust anchors at the lightweight nodes, and the trust anchors indicate the trust blocks that are verified as correct. The transaction set verification unit 1130 determines the correctness of the transaction set in the block to be verified based on the verification result of the correctness of the consensus certification information.

The block body information obtaining unit 1140 obtains the block body information of the block to be verified from all nodes before determining the correctness of the transaction set in the block to be verified based on the correctness verification result of the consensus proof information. The block header verification unit 1150 verifies the correctness of the transaction root of the block to be verified at the lightweight node based on the block body information. The transaction set verification unit 1130 may determine the correctness of the transaction set in the block to be verified based on the correctness verification result of the transaction root and the correctness verification result of the block proof information.

The to-be-verified block monitoring unit 1160 monitors whether there is a to-be-verified block that includes the specified transaction before obtaining the consensus proof information of the to-be-verified block from all nodes. The consensus proof information obtaining unit 1110 can obtain the monitored consensus proof information of the block to be verified from all nodes when it monitors that there is a block to be verified that includes the specified transaction.

The verification request receiving unit 1170 receives a transaction correctness verification request for a specified transaction in the transaction set. The existence verification unit 1180 verifies whether the specified transaction exists in the transaction set. The designated transaction correctness determination unit 1190 determines the correctness of the designated transaction based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the block to be verified.

The verification request receiving unit 1170 may also receive a transaction correctness verification request for a specified transaction in the transaction set before obtaining the consensus proof information of the block to be verified from the full number of nodes. In this example, the consensus proof information obtaining unit 1110 may obtain the consensus proof information of the block to be verified from all nodes when receiving the transaction correctness verification request.

The units in FIG. 11 are not all necessary, and the transaction correctness verification execution device may not include some of the units. For example, in an example, the block monitoring unit to be verified may not be included, the verification request receiving unit, the existence verification unit, the specified transaction correctness determination unit, etc. may not be included, and the block body information acquisition unit and Block header verification unit.

Fig. 12 is a structural block diagram of the consensus proof verification process in the device for performing transaction correctness verification shown in Fig. 11. As shown in FIG. 12, the consensus certification information verification unit 1120 includes a public key restoration module 1121 and a consensus certification information verification module 1122.

The public key restoration module 1121 uses the encryption algorithm used by each consensus node to sign the original text of the first signature data to restore the public key of each consensus node from the digital signature set. The consensus certification information verification module 1122 verifies the correctness of the consensus certification information based on the restored public key of each consensus node and the public key set at the lightweight node. In an example, the consensus proof information verification module 1122 may be included when at least part of the restored public keys are included in the public key set and the number of public keys included in the public key set meets the consensus rules , To confirm that the consensus proof information is correct.

The embodiments of the method and device for performing transaction correctness verification according to the embodiments of the present specification are described above with reference to FIGS. 1 to 12. The details mentioned in the above description of the method embodiment are also applicable to the embodiment of the device in the embodiment of this specification.

The device for performing transaction correctness verification in the embodiments of this specification can be implemented by hardware, or by software or a combination of hardware and software. The various embodiments in this specification are described in a progressive manner, and the same or similar parts among the various embodiments are referred to each other.

The device for performing transaction correctness verification in the embodiments of this specification can be implemented by hardware, or by software or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the memory into the memory through the processor of the device where it is located. In the embodiment of this specification, the means for performing transaction correctness verification can be implemented by using a computing device, for example.

Fig. 13 is a structural block diagram of a computing device for implementing a method for verifying the correctness of a transaction according to an embodiment of the present specification. As shown in FIG. 13, the computing device 1300 includes a processor 1313, a memory 1320, a memory 1330, a communication interface 1340, and an internal bus 1350, and a processor 1213, a memory (for example, a non-volatile memory) 1320, a memory 1330, and a communication interface 1340 is connected together via a bus 1350. According to an embodiment, the computing device 1300 may include at least one processor 1313 that executes at least one computer readable instruction (ie, the aforementioned Elements implemented in software).

In one embodiment, computer-executable instructions are stored in the memory 1320, which, when executed, cause at least one processor 1313 to: obtain consensus proof information of the block to be verified from all nodes, the consensus proof information including a set of digital signatures The digital signature set is obtained by signing the original text of the first signature data corresponding to the block to be verified by each consensus node that reached a consensus on the block to be verified; based on the digital signature set and the The public key set at the lightweight node verifies the correctness of the consensus proof information, the public key set includes the public keys of at least part of the blockchain nodes in the block system; and the correctness of the proof information based on the consensus The result of the sexual verification determines the correctness of the transaction set in the block to be verified. .

It should be understood that the computer-executable instructions stored in the memory 1320, when executed, cause at least one processor 1313 to perform the various operations and functions described above in conjunction with FIGS. 1-12 in the various embodiments of the embodiments of this specification.

According to one embodiment, a program product such as a non-transitory machine-readable medium is provided. The non-transitory machine-readable medium may have instructions (ie, the above-mentioned elements implemented in the form of software), which when executed by a machine, cause the machine to execute the above described in conjunction with FIGS. 1-12 in the various embodiments of the embodiments of this specification. Various operations and functions.

Specifically, a system or device equipped with a readable storage medium may be provided, and the software program code for realizing the function of any one of the above-mentioned embodiments is stored on the readable storage medium, and the computer or device of the system or device The processor reads and executes the instructions stored in the readable storage medium.

In this case, the program code itself read from the readable medium can realize the function of any one of the above embodiments, so the machine readable code and the readable storage medium storing the machine readable code constitute the present invention a part of.

Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tape, Volatile memory card and ROM. Alternatively, the program code can be downloaded from a server computer or cloud via a communication network.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Not all steps and units in the above processes and system structure diagrams are necessary, and some steps or units can be omitted according to actual needs. The order of execution of each step is not fixed and can be determined as needed. The device structure described in the foregoing embodiments may be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or may be implemented by multiple physical entities. Some components in independent devices are implemented together.

The term "exemplary" used throughout this specification means "serving as an example, instance, or illustration", and does not mean "preferred" or "advantageous" over other embodiments. The detailed description includes specific details for the purpose of providing an understanding of the described technology. However, these techniques can be implemented without these specific details. In some instances, in order to avoid incomprehensibility to the concepts of the described embodiments, well-known structures and devices are shown in the form of block diagrams.

The above describes in detail the optional implementation manners of the embodiments of the embodiments of this specification with reference to the accompanying drawings. However, the embodiments of the embodiments of this specification are not limited to the specific details in the above-mentioned embodiments. Within the scope of the conception, a variety of simple modifications can be made to the technical solutions of the embodiments of the embodiments of the present specification, and these simple modifications all belong to the protection scope of the embodiments of the embodiments of the present specification.

The foregoing description of the content of the embodiments of this specification is provided to enable any person of ordinary skill in the art to implement or use the content of the embodiments of this specification. It is obvious to a person of ordinary skill in the art that various modifications made to the content of the embodiments of this specification are obvious, and the general principles defined herein can also be used without departing from the scope of protection of the content of the embodiments of this specification. Apply to other variants. Therefore, the contents of the embodiments of this specification are not limited to the examples and designs described herein, but are consistent with the widest scope that conforms to the principles and novel features disclosed herein.

Claims

A method for performing transaction correctness verification, the method is executed by a lightweight node in a blockchain system, and the method includes:

Obtain the consensus proof information of the block to be verified from the full number of nodes. The consensus proof information includes a set of digital signatures. The corresponding first signature data is obtained by signing the original text;

Verifying the correctness of the consensus proof information based on the digital signature set and the public key set at the lightweight node, the public key set including the public keys of at least part of the blockchain nodes in the block system; as well as

Based on the verification result of the correctness of the consensus proof information, the correctness of the transaction set in the block to be verified is determined.
The method according to claim 1, wherein, before determining the correctness of the transaction set in the block to be verified based on the correctness verification result of the consensus proof information, the method further comprises:

Obtain the block body information of the block to be verified from the full number of nodes;

Based on the block body information, verify the correctness of the transaction root of the block to be verified at the lightweight node,

Based on the verification result of the correctness of the consensus proof information, determining the correctness of the transaction set in the block to be verified includes:

Based on the correctness verification result of the transaction root and the correctness verification result of the block proof information, the correctness of the transaction set in the block to be verified is determined.
The method of claim 1, wherein verifying the correctness of the consensus proof information based on the digital signature set and the public key set at the lightweight node comprises:

Using the encryption algorithm used by each consensus node to sign the original text of the first signature data, restore the public key of each consensus node from the digital signature set; and

Based on the restored public key of each consensus node and the public key set at the lightweight node, the correctness of the consensus certification information is verified.
The method of claim 3, wherein, based on the restored public key of each consensus node and the public key set at the lightweight node, verifying the correctness of the transaction in the block to be verified comprises:

When at least part of the restored public keys is included in the public key set and the number of public keys included in the public key set meets the consensus rule, it is determined that the consensus certification information is correct.
The method according to any one of claims 1-4, wherein the set of public keys includes the public keys of all blockchain nodes participating in the consensus in the blockchain system, or

The set of public keys includes the public keys of all consensus nodes that agree on the trust anchors at the lightweight nodes, and the trust anchors indicate the trust blocks that are verified as correct.
The method according to any one of claims 1-4, wherein, before obtaining the consensus proof information of the block to be verified from the full number of nodes, the method further comprises:

Receiving a transaction correctness verification request for a specified transaction in the transaction set,

Obtaining the consensus proof information of the block to be verified from all nodes includes:

Upon receiving the transaction correctness verification request, obtain the consensus proof information of the block to be verified from the full number of nodes,

The method also includes:

Verify whether the specified transaction exists in the transaction set; and

Based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the to-be-verified block, the correctness of the designated transaction is determined.
The method according to any one of claims 1-4, wherein, before obtaining the consensus proof information of the block to be verified from the full number of nodes, the method further comprises:

Monitor whether there is a block to be verified including the specified transaction;

Obtaining the consensus proof information of the block to be verified from all nodes includes:

When it is monitored that there is a block to be verified that includes the specified transaction, the consensus proof information of the block to be verified that is monitored is obtained from all nodes.
The method of claim 7, further comprising:

Receiving a transaction correctness verification request for a specified transaction in the transaction set;

Verify whether the specified transaction exists in the transaction set;

Based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the to-be-verified block, the correctness of the designated transaction is determined.
The method according to any one of claims 1 to 4, wherein the blockchain system is a consortium chain system.
A device for performing transaction correctness verification. The device is used for a lightweight node in a blockchain system. The device includes:

The consensus proof information obtaining unit obtains consensus proof information of the block to be verified from all nodes, the consensus proof information includes a digital signature set, and the digital signature set is a pair of consensus nodes that reach a consensus on the block to be verified Obtained by signing the original text of the first signature data corresponding to the block to be verified;

The consensus certification information verification unit verifies the correctness of the consensus certification information based on the digital signature set and the public key set at the lightweight node, and the public key set includes at least part of the blocks in the block system The public key of the chain node; and

The transaction set verification unit determines the correctness of the transaction set in the block to be verified based on the verification result of the correctness of the consensus certification information.
The device of claim 10, further comprising:

The block body information acquisition unit, before determining the correctness of the transaction set in the block to be verified based on the correctness verification result of the consensus proof information, obtains the information of the block to be verified from the full amount of nodes Block body information;

The block header verification unit verifies the correctness of the block header of the block to be verified at the lightweight node based on the block body information,

The consensus proof information verification unit determines the correctness of the transaction set in the block to be verified based on the correctness verification result of the block header and the correctness verification result of the block proof information.
The apparatus of claim 10, wherein the transaction set verification unit comprises:

The public key restoration module uses the encryption algorithm used by each consensus node to sign the original text of the first signature data to restore the public key of each consensus node from the digital signature set; and

The consensus certification information verification module verifies the correctness of the consensus certification information based on the restored public key of each consensus node and the public key set at the lightweight node.
The apparatus according to claim 12, wherein at least part of the public key recovered by the consensus certification information verification module is included in the public key set and the public key included in the public key set When the number of keys meets the consensus rule, it is determined that the consensus certification information is correct.
The device according to any one of claims 10-13, wherein the set of public keys includes the public keys of all blockchain nodes participating in consensus in the blockchain system, or

The set of public keys includes the public keys of all consensus nodes that agree on the trust anchors at the lightweight nodes, and the trust anchors indicate the trust blocks that are verified as correct.
The device according to any one of claims 10-13, wherein, before obtaining the consensus proof information of the block to be verified from all nodes, the device further comprises:

The verification request receiving unit receives a transaction correctness verification request for a specified transaction in the transaction set,

The consensus proof information obtaining unit obtains the consensus proof information of the block to be verified from the full number of nodes when receiving the transaction correctness verification request,

The device also includes:

An existence verification unit to verify whether the specified transaction exists in the transaction set; and

The designated transaction correctness determining unit determines the correctness of the designated transaction based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the block to be verified.
The device according to any one of claims 10-13, wherein the device further comprises:

The block to be verified monitoring unit monitors whether there is a block to be verified that includes the specified transaction before obtaining the consensus proof information of the block to be verified from the full number of nodes;

When the consensus proof information acquisition unit monitors that there is a block to be verified that includes the designated transaction, it acquires the monitored consensus proof information of the block to be verified from all nodes.
The device of claim 16, further comprising:

A verification request receiving unit, which receives a transaction correctness verification request for a specified transaction in the transaction set;

An existence verification unit to verify whether the specified transaction exists in the transaction set; and

The designated transaction correctness determining unit determines the correctness of the designated transaction based on the correctness verification result of the transaction set and the existence verification result of the designated transaction in the block to be verified.
A computing device including:

At least one processor; and

A memory, where the memory stores instructions, and when the instructions are executed by the at least one processor, the at least one processor executes the method according to any one of claims 1 to 9.
A machine-readable storage medium storing executable instructions, which when executed, cause the machine to execute the method according to any one of claims 1-9.