Block chain-based transaction processing method and related device

Abstract

The embodiment of the invention provides a transaction processing method based on a block chain and a related device, and relates to the technical field of block chains and cloud computing. The method comprises the following steps: a second block chain node obtains at least one transaction in a transaction memory pool, executes each transaction in the at least one transaction, obtains a transaction related message set obtained in the transaction execution process, constructs a transaction related message tree based on the transaction related message set, and stores the transaction related message tree in the transaction memory pool; determining a message root hash value of the transaction-related message set based on the first hash value corresponding to each first node, storing the transaction-related message tree and the message root hash value to a target block, and sending the target block to a first block chain node, and if yes, the first block chain node can perform consensus verification on the target transaction related message based on the transaction related message tree and the message root hash value stored in the target block, so that the technical problem of relatively low transaction verification efficiency of the block chain can be solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, for example, blockchain and cloud computing technology. Specifically, the present application relates to a transaction processing method based on blockchain and related devices. Background Art

[0002] Blockchain technology can solve the problem of trust establishment between nodes in a decentralized system through distributed node verification and consensus mechanisms, and realize a decentralized and distributed trust establishment mechanism, thereby completing the transfer of value while transmitting information. The transaction privacy, security, data immutability and auditability, integrity, system transparency and fault tolerance of blockchain make blockchain widely used in many fields, including identity management, intelligent transportation, supply chain management, Internet of Things, Industrial Internet, Energy Internet, etc.

[0003] The operation of blockchain nodes depends on the verification of transactions. In related technologies, a full node is mainly used to fully verify transactions and synchronize transactions, which leads to the problem of low efficiency of blockchain transaction verification. Summary of the invention

[0004] The embodiments of the present application provide a transaction processing method and related devices based on blockchain, which are used to solve the technical problem of low efficiency of transaction verification of blockchain, so as to achieve the technical effect of improving the efficiency of transaction verification of blockchain.

[0005] On the one hand, the embodiment of the present application provides a transaction processing method based on blockchain, including:

[0006] Get at least one transaction in the transaction memory pool;

[0007] Execute each transaction of at least one transaction, and obtain a transaction-related message set obtained in the process of executing the transaction, the transaction-related message set including a transaction-related message corresponding to each transaction, and the transaction-related message including transaction data, source information of the transaction data, and destination information of the transaction data;

[0008] Constructing a transaction-related message tree based on the transaction-related message set, the transaction-related message tree comprising first nodes, second nodes connected to each first node, and transaction-related messages connected to each second node in a one-to-one correspondence, wherein a first node represents a first hash value of a transaction, and each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction;

[0009] Determine a message root hash value of a transaction-related message set based on the first hash value corresponding to each first node;

[0010] The transaction-related message tree and the message root hash value are stored in the target block, and the target block is sent to the first blockchain node, so that the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

[0011] Optionally, the second hash value corresponding to each second node of the transaction-related message tree is determined in the following manner:

[0012] Determine a first sub-hash value of transaction data, a second sub-hash value of source information, and a third sub-hash value of destination information in a transaction-related message connected to the second node;

[0013] Based on the first sub-hash value, the second sub-hash value, and the third sub-hash value corresponding to the transaction-related message connected to the second node, a second hash value corresponding to the second node is determined, wherein the second hash value is positively correlated with the first sub-hash value, the second sub-hash value, and the third sub-hash value, respectively.

[0014] Optionally, the target block pre-stores at least one transaction, and the method further includes:

[0015] determining a third hash value for each transaction in the at least one transaction;

[0016] Determining a transaction root hash value of at least one transaction based on the third hash value of each transaction;

[0017] Store the transaction-related message tree and message root hash value in the target block, including:

[0018] The transaction-related message tree, the message root hash value, and the transaction root hash value are stored in the target block, so that when the first blockchain node performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, it also performs consensus verification on the target transaction-related message based on the transaction root hash value.

[0019] Optionally, the target block includes a block header, a block body and a block body attachment, the transaction root hash value is stored in the block header, at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, and the message root hash value is stored in at least one item in the block header or the block body.

[0020] Optionally, store the transaction-related message tree and message root hash value in the target block, including:

[0021] If one of the full nodes synchronized by the first blockchain node is an untrusted node, the complete transaction-related message tree and the message root hash value are stored in the target block;

[0022] If any full node synchronized by the first blockchain node is a trusted node, a target transaction-related message that meets a preset condition is determined in the transaction-related message tree, and other transaction-related messages except the target transaction-related message are deleted from the transaction-related message tree, and the transaction-related message tree and the message root hash value after deleting other transaction-related messages are stored in the target block.

[0023] Optionally, determining a target transaction-related message that meets a preset condition in the transaction-related message tree includes:

[0024] Determine the target account that the first blockchain node is following;

[0025] Based on the target account, determine the target transaction-related message that meets the preset conditions from the transaction-related message tree;

[0026] The source information includes the source account, the destination information includes the destination account, and the preset conditions include:

[0027] At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

[0028] Optionally, determining a target account that the first blockchain node is following includes:

[0029] Obtain a preset account set associated with the first blockchain node, where the preset account set includes all accounts followed by the first blockchain node;

[0030] At least one account in the preset account set is used as a target account;

[0031] The method also includes:

[0032] In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained;

[0033] The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

[0034] On the other hand, the embodiment of the present application also provides a transaction processing method based on blockchain, including:

[0035] Obtain a target block from a second blockchain node, the target block storing a message root hash value and a transaction-related message tree, the transaction-related message tree stored in the target block including a first node, second nodes connected to each first node, and transaction-related messages connected in a one-to-one correspondence with at least one second node, a first node representing a first hash value of a transaction in at least one transaction, each second node connected to a first node representing a second hash value of each transaction-related message corresponding to a transaction, at least one transaction is obtained from a transaction memory pool, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data;

[0036] Determine the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block;

[0037] Consensus verification of target transaction-related messages is performed based on the transaction-related message tree and message root hash value stored in the target block.

[0038] Optionally, consensus verification of target transaction-related messages is performed based on the transaction-related message tree and message root hash value stored in the target block, including:

[0039] For each target transaction-related message, determining a fourth hash value of the target transaction-related message;

[0040] For each target transaction-related message, using the fourth hash value of the target transaction-related message as the hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree;

[0041] For each first node in the transaction-related message tree stored in the target block, determine a fifth hash value corresponding to the first node based on a hash value corresponding to each second node connected to the first node;

[0042] Determine a hash value of the message to be verified based on the fifth hash value corresponding to each first node;

[0043] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed;

[0044] If the hash value of the message to be verified is inconsistent with the message root hash value, it is determined that the consensus verification of the target transaction related message has failed.

[0045] Optionally, determining a fourth hash value of the target transaction-related message includes:

[0046] Determine a fourth sub-hash value of the transaction data, a fifth sub-hash value of the source information, and a sixth sub-hash value of the destination information in the target transaction-related message;

[0047] Based on the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value corresponding to the target transaction-related message, a fourth hash value of the target transaction-related message is determined, wherein the fourth hash value is positively correlated with the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value, respectively.

[0048] Optionally, the target block further stores at least one transaction and a transaction root hash value, and the method further includes:

[0049] determining a sixth hash value for each transaction in the at least one transaction;

[0050] Determine a hash value of the transaction to be verified based on the sixth hash value of each transaction;

[0051] If the hash value of the transaction to be verified is inconsistent with the transaction root hash value, it is determined that the consensus verification of the target transaction related message has failed;

[0052] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed, including:

[0053] If the hash value of the message to be verified is consistent with the message root hash value and the hash value of the transaction to be verified is consistent with the transaction root hash value, then the consensus verification of the target transaction-related message is determined to have passed.

[0054] Optionally, applied to a first blockchain node, the target block includes a block header, a block body, and a block body attachment, the transaction root hash value is stored in the block header, at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, and the message root hash value is stored in the block header or the block body attachment, and the method further includes:

[0055] When the consensus verification of the target transaction-related messages is passed, the transaction is executed based on the transaction data, source information and destination information in each target internal transaction message, and the data in the block body attachment is deleted, and the blockchain stored in the first blockchain node is updated based on the target block after the data is deleted.

[0056] Optionally, the method applied to the first blockchain node to determine a target transaction-related message that satisfies a preset condition in a transaction-related message tree stored in a target block includes any of the following:

[0057] Each transaction-related message in the transaction-related message tree is used as a target transaction-related message, wherein the transaction-related message tree stored in the target block is obtained by determining the target transaction-related message that meets the preset conditions in the transaction-related message tree and deleting other transaction-related messages except the target transaction-related message;

[0058] Determine a target account that the first blockchain node is concerned about, and based on the target account, determine a target transaction-related message that meets a preset condition from a transaction-related message tree stored in a target block;

[0059] The source information includes the source account, the destination information includes the destination account, and the preset conditions include:

[0060] At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

[0061] Optionally, determining a target account that the first blockchain node is following includes:

[0062] Obtain a preset account set associated with the first blockchain node, where the preset account set includes all accounts followed by the first blockchain node;

[0063] At least one account in the preset account set is used as a target account;

[0064] The method also includes:

[0065] In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained;

[0066] The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

[0067] On the other hand, an embodiment of the present application provides a blockchain network, including a first blockchain node and a second blockchain node, wherein:

[0068] The second blockchain node is used to obtain at least one transaction in the transaction memory pool, execute each transaction in the at least one transaction, and obtain a transaction-related message set obtained in the process of executing the transaction, the transaction-related message set includes a transaction-related message corresponding to each transaction, the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data, a transaction-related message tree is constructed based on the transaction-related message set, the transaction-related message tree includes a first node, second nodes connected to each first node, and transaction-related messages connected to each second node in a one-to-one correspondence, a first node represents a first hash value of a transaction, each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction, a message root hash value of the transaction-related message set is determined based on the first hash value corresponding to each first node, the transaction-related message tree and the message root hash value are stored in a target block, and the target block is sent to the first blockchain node;

[0069] The first blockchain node is used to determine the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and perform consensus verification on the target transaction-related message based on the transaction-related message tree stored in the target block and the message root hash value.

[0070] On the other hand, the embodiment of the present application also provides a transaction processing device based on blockchain, including:

[0071] A first acquisition module, used to acquire at least one transaction in the transaction memory pool;

[0072] a second acquisition module, configured to execute each transaction of at least one transaction and acquire a transaction-related message set obtained in the process of executing the transaction, wherein the transaction-related message set includes a transaction-related message corresponding to each transaction, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data;

[0073] A message tree construction module, used to construct a transaction-related message tree based on a transaction-related message set, wherein the transaction-related message tree includes a first node, second nodes connected to each first node, and transaction-related messages connected to each second node in a one-to-one correspondence, wherein a first node represents a first hash value of a transaction, and each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction;

[0074] A hash value determination module, configured to determine a message root hash value of a transaction-related message set based on a first hash value corresponding to each first node;

[0075] The first transaction processing module is used to store the transaction-related message tree and the message root hash value in the target block, and send the target block to the first blockchain node, so that the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

[0076] On the other hand, the embodiment of the present application also provides a transaction processing device based on blockchain, including:

[0077] A third acquisition module is used to acquire a target block from a second blockchain node, the target block stores a message root hash value and a transaction-related message tree, the transaction-related message tree stored in the target block includes a first node, a second node connected to each first node, and a transaction-related message connected in a one-to-one correspondence with at least one second node, a first node represents a first hash value of a transaction in at least one transaction, each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction, at least one transaction is acquired from a transaction memory pool, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data;

[0078] A target message determination module, used to determine a target transaction-related message that meets a preset condition in a transaction-related message tree stored in a target block;

[0079] The second transaction processing module is used to perform consensus verification on the target transaction related messages based on the transaction related message tree and the message root hash value stored in the target block.

[0080] On the other hand, an embodiment of the present application further provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method of any embodiment of the application.

[0081] On the other hand, an embodiment of the present application further provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, the steps of the method of any embodiment of the application are implemented.

[0082] On the other hand, an embodiment of the present application further provides a computer program product, including a computer program, which implements the steps of the method of any embodiment of the application when the computer program is executed by a processor.

[0083] In an embodiment of the present application, at least one transaction in a transaction memory pool is obtained through a second blockchain node, each transaction in the at least one transaction is executed, and a transaction-related message set obtained in the process of executing the transaction is obtained, the transaction-related message set includes a transaction-related message corresponding to each transaction, and a transaction-related message tree is constructed based on the transaction-related message set. The transaction-related message tree includes a first node, a second node connected to each first node, and a transaction-related message connected to each second node in a one-to-one correspondence. The message root hash value of the transaction-related message set is determined based on the first hash value corresponding to each first node, the transaction-related message tree and the message root hash value are stored in a target block, and the target block is sent to the first blockchain node. The first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and consensus verification is performed on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block. Since the first blockchain node only verifies the target transaction-related message that meets the preset conditions in the transaction-related message set, the technical problem of low efficiency of blockchain transaction verification and low data security and availability can be solved, so as to achieve the technical effect of improving the efficiency of blockchain transaction verification and taking into account data security and availability. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in describing the embodiments of the present application are briefly introduced below.

[0085] Figure 1AA schematic diagram of an implementation environment of a transaction processing method based on blockchain provided in an embodiment of the present application;

[0086] Figure 1B A schematic diagram of a blockchain provided in an embodiment of the present application;

[0087] Figure 1C A schematic diagram of a process of generating a new block provided in an embodiment of the present application;

[0088] Figure 2 A flowchart of a transaction processing method based on blockchain provided in an embodiment of the present application;

[0089] Figure 3 A schematic diagram of a transaction-related message tree provided in an embodiment of the present application;

[0090] Figure 4 A schematic diagram of a data structure of a target block provided in an embodiment of the present application;

[0091] Figure 5 A schematic diagram of a transaction-related message tree stored in a target block provided in an embodiment of the present application;

[0092] Figure 6 A flowchart of a block packaging solution based on transaction-related message set generation provided in an embodiment of the present application;

[0093] Figure 7 A flowchart of a transaction-related message verification solution provided in an embodiment of the present application;

[0094] Figure 8 A schematic diagram of the structure of a blockchain-based transaction processing device provided in an embodiment of the present application;

[0095] Fig. 9 A schematic diagram of the structure of another blockchain-based transaction processing device provided in an embodiment of the present application;

[0096] Fig.10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0097] The embodiments of the present application are described below in conjunction with the drawings in the present application. It should be understood that the implementation methods described below in conjunction with the drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0098] Those skilled in the art will appreciate that, unless specifically stated, the singular forms "one", "an", and "the" used herein may also include plural forms. It should be further understood that the terms "including" and "comprising" used in the embodiments of the present application refer to that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude the implementation as other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the technical field. It should be understood that when we call an element "connected" or "coupled" to another element, the one element may be directly connected or coupled to the other element, or it may refer to that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein indicates at least one of the items defined by the term, such as "A and / or B" indicates implementation as "A", or implementation as "A", or implementation as "A and B".

[0099] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0100] The following is an explanation of the terms and related technologies involved in this application:

[0101] Blockchain: A data structure consisting of several blocks connected by hash values. Each block consists of transactions generated within a period of time, packaged by computer nodes that have obtained the right to record accounts, and independently verified by each computer node.

[0102] Full node: refers to a complete node that maintains the blockchain, which can independently complete the packaging and verification of transactions, and process the client's read and write requests for the status of smart contracts.

[0103] Account: refers to the account on the blockchain of the state model, including external accounts (i.e. user-controlled accounts) and contract accounts (i.e. accounts controlled by contract code)

[0104] Block header: generally refers to the information describing the main content of the block located at the head of the block in a single block structure, including the hash value of the block body, the hash of the previous block, the number of transactions, the timestamp, etc.

[0105] Transaction: Blockchain transactions are generally manifested as the transfer of certain resources from certain specific accounts to other specific accounts, and are also manifested as the call of a smart contract.

[0106] See also Figure 1A , Figure 1A A schematic diagram of an implementation environment of a transaction processing method based on blockchain provided in an embodiment of the present application. Figure 1AThe operating environment includes a client, multiple nodes (any form of computing devices connected to the network, such as servers, user terminals) connected through network communication to form a data sharing system

[0107] Take the data sharing system as a blockchain system as an example, see Figure 1A The data sharing system shown, the data sharing system 100 refers to a system for sharing data between blockchain nodes (hereinafter referred to as nodes) and blockchain nodes. The data sharing system may include multiple nodes 101, and multiple nodes 101 may refer to each client in the data sharing system. Each node 101 can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the information intercommunication within the data sharing system, there may be an information connection between each node in the data sharing system, and information can be transmitted between nodes through the above information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0108] Each node in the data sharing system has a corresponding node identifier, and each node in the data sharing system can store the node identifiers of other nodes in the data sharing system, so that the generated blocks can be broadcast to other nodes in the data sharing system according to the node identifiers of other nodes. A node identifier list as shown in the following table can be maintained in each node, and the node name and node identifier are stored in the node identifier list accordingly. Among them, the node identifier can be an IP (Internet Protocol, a protocol for interconnecting networks) address and any other information that can be used to identify the node. Table 1 only takes the IP address as an example for illustration.

[0109]

[0110]

[0111] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks, see Figure 1BThe blockchain consists of multiple blocks. The genesis block includes a block header and a block body. The block header stores the input information characteristic value, version number, timestamp and difficulty value, and the block body stores the input information; the next block of the genesis block takes the genesis block as the parent block, and the next block also includes a block header and a block body. The block header stores the input information characteristic value of the current block, the block header characteristic value, version number, timestamp and difficulty value of the parent block, and so on, so that the block data stored in each block in the blockchain is associated with the block data stored in the parent block, ensuring the security of the input information in the block.

[0112] When generating each block in the blockchain, see Figure 1C When the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool and the hash tree used to record the input information is updated. After that, the update timestamp is updated to the time when the input information is received, and different random numbers are tried to calculate the eigenvalue multiple times so that the calculated eigenvalue can satisfy the following formula:

[0113] SHA256(SHA256(version+prev_hash+merkle_root+ntime+nbits+x))<TARGET

[0114] Among them, SHA256 is the eigenvalue algorithm used to calculate the eigenvalue; version (version number) is the version information of the relevant block protocol in the blockchain; prev_hash is the block header eigenvalue of the parent block of the current block; merkle_root is the eigenvalue of the input information; ntime is the update time of the update timestamp; nbits is the current difficulty, which is a fixed value within a period of time and is determined again after exceeding the fixed time period; x is a random number; TARGET is the eigenvalue threshold, which can be determined based on nbits.

[0115] In this way, when the random number that satisfies the above formula is calculated, the information can be stored accordingly, the block header and block body can be generated, and the current block can be obtained. Subsequently, the node where the blockchain is located sends the newly generated block to other nodes in the data sharing system according to the node identification of other nodes in the data sharing system. Other nodes verify the newly generated block and add the newly generated block to the blockchain stored in them after the verification is completed.

[0116] Among them, some nodes of the blockchain network can be accounting nodes, and other nodes can be non-accounting nodes.

[0117] In the related art, a full node is generally used to fully verify transactions and synchronize transactions. The full node synchronizes all transactions and world states, and uses cryptographic methods such as Merkle trees to ensure that transactions and state data cannot be tampered with. However, the efficiency of transaction verification of synchronized ledgers, transactions, and world states is low, and it requires very high bandwidth and very large storage, which is very costly. Therefore, in order to reduce costs, some solutions introduce light nodes. Light nodes do not need to verify transactions, but light nodes need to quickly synchronize all block headers of the blockchain, use cryptographic methods such as Merkle trees, and rely on full nodes to obtain some required data to prove that a certain world state data on the chain is correct. However, since light nodes rely on full nodes, there are problems with low security and availability, that is, running a blockchain light node requires relying on a sufficiently secure full node in the network, and when critical business data is needed, it needs to be transferred to the full node, and the availability of data is also reduced.

[0118] Therefore, in view of at least one of the above technical problems or areas that need to be improved in the related technology, the present application proposes a transaction processing method and related device based on blockchain, obtaining at least one transaction in the transaction memory pool through the accounting node in the blockchain system; executing each transaction in at least one transaction, and obtaining the transaction-related message set obtained in the process of executing the transaction, constructing a transaction-related message tree based on the transaction-related message set, and determining the message root hash value of the transaction-related message set based on the first hash value corresponding to each first node; storing the transaction-related message tree and the message root hash value in the target block, and sending the target block to the non-accounting node in the blockchain system, so that the non-accounting node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, which can solve the technical problem of low efficiency of blockchain transaction verification and solve the technical problem of low data security and availability, so as to achieve the technical effect of improving the efficiency of blockchain transaction verification and taking into account data security and availability. The following describes several exemplary embodiments to illustrate the technical solution of the embodiment of the present application and the technical effect of the technical solution of the present application. It should be pointed out that the following implementation modes may refer to, draw on or combine with each other, and the same terms, similar features and similar implementation steps in different implementation modes will not be described repeatedly.

[0119] Optionally, embodiments of the present application may involve cloud technology, such as deploying the first blockchain node and the second blockchain node on the cloud.

[0120] Among them, cloud technology is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. based on the cloud computing business model. It can form a resource pool, which is used on demand and is flexible and convenient. Cloud computing technology will become an important support. Cloud storage is a new concept extended and developed from the concept of cloud computing. Distributed cloud storage system (hereinafter referred to as storage system) refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of different types of storage devices (storage devices are also called storage nodes) in the network through application software or application interfaces to work together and provide data storage and target business access functions to the outside world.

[0121] Figure 2 A flowchart of a transaction processing method based on blockchain provided in an embodiment of the present application. Figure 2 The method shown can be applied to an electronic device, which can include at least one of a first blockchain node (also called a non-accounting node) or a second blockchain node (also called an accounting node). Figure 2 The blockchain-based transaction processing method shown includes:

[0122] S210. The second blockchain node obtains at least one transaction in the transaction memory pool.

[0123] Among them, the transaction memory pool is a group of Ethereum transactions that have been broadcast to the network and are waiting to be mined into a block. The transaction memory pool service provides direct insight into the life cycle of a transaction. After a transaction is broadcast to a node by a user, it waits in the transaction memory pool. From there, the transaction will be mined into a block, replaced by another transaction, or discarded by the blockchain network. A transaction is also called a transaction, including but not limited to at least one of a transfer, a storage call for a contract, or a bookkeeping call for an invoice.

[0124] In this embodiment, optionally, the second blockchain node may directly obtain at least one transaction from the transaction memory pool, or may obtain it from a block storing at least one transaction, which is not limited here.

[0125] S220. The second blockchain node executes each transaction in the at least one transaction, and obtains a transaction-related message set obtained in the process of executing the transaction, where the transaction-related message set includes a transaction-related message corresponding to each transaction.

[0126] Among them, the transaction-related messages include transaction data, source information of transaction data, and destination information of transaction data. Transaction data refers to specific data that needs to be traded, such as the specific amount of the transfer, the contract stored or called, or at least one of the invoices stored or called, which is not limited here. Source information refers to the source of transaction data, that is, where the transaction data comes from. Destination information refers to the destination of transaction data, that is, where the transaction data is going. Taking a transaction as an example, account A transfers amount C to account B, then the transaction data can be amount C, the source information can include account A, and the destination information can include account B. Optionally, the transaction-related message set is traced after each transaction of at least one transaction is executed.

[0127] In this embodiment, when the second blockchain node executes each transaction, it will obtain at least one transaction-related message corresponding to each transaction. Based on the transaction-related messages corresponding to each transaction, a transaction-related message set can be obtained, that is, the transaction-related message set can include the transaction-related messages corresponding to each transaction.

[0128] Specifically, the transaction-related message corresponding to a transaction may be the transaction itself, or may include the transaction itself and other transaction messages triggered by the transaction itself. For example, taking a transaction as a transfer, account A transfers amount C to account B. If account B is a user account, the transaction-related message corresponding to the transaction includes the transaction itself, that is, the amount C transferred from account A to account B. If account B is a contract account, it will automatically trigger transactions initiated by account B to other accounts, such as account B transferring amount C1 to account D and amount C2 to account E. At this time, the transaction-related message corresponding to the transaction includes the transaction itself and other transaction messages triggered by the transaction itself, and includes the amount C transferred from account A to account B and transaction messages initiated by account B to other accounts.

[0129] S230. The second blockchain node constructs a transaction-related message tree based on the transaction-related message set. The transaction-related message tree includes the first node, the second nodes connected to each first node, and the transaction-related messages connected to each second node in a one-to-one correspondence.

[0130] A first node represents a first hash value of a transaction, and each second node connected to the first node represents a second hash value of each transaction-related message corresponding to the transaction.

[0131] See also Figure 3 , Figure 3 A schematic diagram of a transaction-related message tree provided in an embodiment of the present application. Figure 3 The transaction-related message tree shown may be a Merkle tree.

[0132] like Figure 3As shown, H(1,:), H(2,:) and H(3,:) can represent a first node respectively. H(1,1), H(1,2) and H(1,3) are the second nodes connected to H(1,:). H(2,1) and H(2,2) are the second nodes connected to H(2,:). H(3,1), H(3,2) and H(3,3) are the second nodes connected to H(3,:).

[0133] In this embodiment, the first nodes such as H(1,:), H(2,:), and H(3,:) can be equivalent to H(N,:). The "N" in H(N,:) can represent a transaction in at least one transaction, and the ":" in H(N,:) can represent that it is a first node.

[0134] Optionally, each transaction-related message has a first identifier and a second identifier. The first identifier indicates the transaction to which it belongs, and the second identifier of a transaction-related message indicates its transaction order in the transaction-related message set. Specifically, the second node connected to it can be determined by the first identifier. The transaction order of the transaction-related messages in the transaction-related message tree can be determined by the second identifier.

[0135] Specifically, H(1,1), H(2,1) and H(3,1) can be equivalent to H(N,n). Among them, "N" in H(N,n) can represent a transaction to which it belongs in at least one transaction, and "n" in H(N,n) can represent one of the transaction-related messages in the transaction to which it belongs. Optionally, "n" in H(N,n) can also represent the transaction order in the transaction to which it belongs, that is, N is the first identifier and n is the second identifier.

[0136] In this embodiment, the first hash value corresponding to the first node is determined based on the second hash value corresponding to each second node connected to it. Optionally, the first hash value corresponding to the first node can be calculated by continuous XOR method using the second hash value corresponding to each second node connected to the first node. For example, the first hash value corresponding to the first node can be calculated by the following method:

[0137]

[0138] S240. The second blockchain node determines the message root hash value of the transaction-related message set based on the first hash value corresponding to each first node.

[0139] Optionally, the transaction-related message tree may further include a root node H_root, which represents the message root hash value of the transaction-related message tree. The message root hash value of the root node H_root is determined based on the first hash value corresponding to each first node connected to it, using a continuous XOR method. For example, the message root hash value corresponding to the root node may be calculated in the following manner:

[0140]

[0141] S250. The second blockchain node stores the transaction-related message tree and the message root hash value in the target block, and sends the target block to the first blockchain node.

[0142] In this embodiment, specifically, if the transaction-related message tree does not include a root node, the transaction-related message tree can be stored in the target block; if the transaction-related message tree includes a root node, the portion of the transaction-related message tree excluding the root node can be stored in the target block.

[0143] S260. The first blockchain node determines a target transaction-related message that meets a preset condition in a transaction-related message tree stored in a target block.

[0144] Among them, the preset condition may refer to a condition that prompts the first blockchain node to filter the target transaction-related message from the transaction-related message tree. The preset condition can be set as needed and is not limited here. Specifically, the target transaction-related message is part or all of the transaction-related messages stored in the target block, that is, the number of target transaction-related messages is less than or equal to the number of transaction-related messages stored in the target block, which is determined according to actual conditions and is not limited here. Specifically, if the transaction-related messages stored in the target block are all target transaction-related messages, the number of transaction-related messages stored in the target block is consistent with the number of target transaction-related messages; if part or all of the transaction-related messages stored in the target block are not target transaction-related messages, the number of transaction-related messages stored in the target block is more than the number of target transaction-related messages.

[0145] S270. The first blockchain node performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

[0146] The technical solution of this embodiment is to obtain at least one transaction in the transaction memory pool through the second blockchain node, execute each transaction in the at least one transaction, and obtain a transaction-related message set obtained in the process of executing the transaction, the transaction-related message set includes the transaction-related message corresponding to each transaction, and construct a transaction-related message tree based on the transaction-related message set. The transaction-related message tree includes the first node, the second node connected to each first node, and the transaction-related message connected to each second node in a one-to-one correspondence. The message root hash value of the transaction-related message set is determined based on the first hash value corresponding to each first node, the transaction-related message tree and the message root hash value are stored in the target block, and the target block is sent to the first blockchain node. The first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block. Since the first blockchain node only verifies the target transaction-related message that meets the preset conditions in the transaction-related message set, the technical problem of low efficiency of blockchain transaction verification and low data security and availability can be solved, so as to achieve the technical effect of improving the efficiency of blockchain transaction verification and taking into account data security and availability.

[0147] In a possible implementation, the first blockchain node performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, which may include:

[0148] For each target transaction-related message, determining a fourth hash value of the target transaction-related message;

[0149] For each target transaction-related message, using the fourth hash value of the target transaction-related message as the hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree;

[0150] For each first node in the transaction-related message tree stored in the target block, determine a fifth hash value corresponding to the first node based on a hash value corresponding to each second node connected to the first node;

[0151] Determine a hash value of the message to be verified based on the fifth hash value corresponding to each first node;

[0152] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed;

[0153] If the hash value of the message to be verified is inconsistent with the message root hash value, it is determined that the consensus verification of the target transaction related message has failed.

[0154] The method for determining the fourth hash value of the target transaction-related message may be consistent with the method for determining the second hash value of the transaction-related message. The fifth hash value corresponding to the first node may be calculated based on the hash value corresponding to each second node connected to it, using a continuous XOR method. The hash value of the message to be verified may be calculated based on the hash value corresponding to each first node, using a continuous XOR method.

[0155] Specifically, in the present embodiment, since the hash value of the message to be verified is determined based on the fifth hash value corresponding to each first node, and the fifth hash value corresponding to the first node is determined based on the hash value corresponding to each second node connected thereto, and the hash value corresponding to the second node connected thereto with the target transaction-related message is determined based on the target transaction-related message connected thereto, therefore, if the target transaction-related message is tampered with, then the hash value of the message to be verified calculated at this time may be inconsistent with the message root hash value stored in the target block, and the consensus verification of the target transaction-related message fails at this time; if the target transaction-related message is not tampered with, then the hash value of the message to be verified calculated at this time may be consistent with the message root hash value stored in the target block, and the consensus verification of the target transaction-related message passes at this time.

[0156] Optionally, in this embodiment, the hash value of the message to be verified and the root hash value of the message stored in the target block can be compared bit by bit. If the result of the bit by bit comparison is consistent, it is considered that the hash value of the message to be verified is consistent with the root hash value of the message stored in the target block.

[0157] In some example scenarios, a hash value may be calculated based on part of the transaction-related message data. However, if a hash value is calculated based on part of the transaction-related message data, the other part of the data for which the hash value is not calculated still has the risk of being tampered with.

[0158] Therefore, in a possible implementation, the second hash value corresponding to each second node of the transaction-related message tree is determined in the following manner:

[0159] Determine a first sub-hash value of transaction data, a second sub-hash value of source information, and a third sub-hash value of destination information in a transaction-related message connected to the second node;

[0160] Based on the first sub-hash value, the second sub-hash value, and the third sub-hash value corresponding to the transaction-related message connected to the second node, a second hash value corresponding to the second node is determined, wherein the second hash value is positively correlated with the first sub-hash value, the second sub-hash value, and the third sub-hash value, respectively.

[0161] Optionally, a transaction-related message is an array, and the j-th element (transaction-related message) in the array for transaction i is the following tuple:

[0162] TX i [j]=<From,To,Data> .

[0163] Among them, Data represents transaction data, From represents source information, and To represents destination information.

[0164] The second hash value corresponding to the second node can be calculated as follows:

[0165] H(i, j) = HASH(TX i [j].From+TX i [j].To+TX i [j].Data).

[0166] Here HASH is any hash function, such as md5, sha256, etc.

[0167] Accordingly, the first blockchain node determines the fourth hash value of the target transaction-related message, which may include:

[0168] Determine a fourth sub-hash value of the transaction data, a fifth sub-hash value of the source information, and a sixth sub-hash value of the destination information in the target transaction-related message;

[0169] Based on the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value corresponding to the target transaction-related message, a fourth hash value of the target transaction-related message is determined, wherein the fourth hash value is positively correlated with the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value, respectively.

[0170] Similarly, the calculation method of the fourth hash value corresponding to the target transaction-related message can be consistent with the calculation method of the second hash sub-value corresponding to the second node connected to the transaction-related message, which will not be elaborated here.

[0171] It can be understood that by calculating the second hash value through the transaction data, source information and destination information of the transaction-related message, and calculating the fourth hash value based on the transaction data, source information and destination information of the target transaction-related message during consensus verification, that is, taking the transaction data, source information and destination information into consideration when calculating the hash value, the security of the transaction can be improved.

[0172] In a possible implementation, the target block pre-stores at least one transaction, and the second blockchain node further performs the following steps:

[0173] determining a third hash value for each transaction in the at least one transaction;

[0174] Determining a transaction root hash value of at least one transaction based on the third hash value of each transaction;

[0175] The second blockchain node stores the transaction-related message tree and the message root hash value in the target block, including:

[0176] Store the transaction-related message tree, message root hash value, and transaction root hash value into the target block

[0177] The third hash value of the transaction can be calculated based on the transaction message corresponding to the transaction itself. Specifically, the third hash value can refer to the description of calculating the second hash value in the above embodiment, and is not limited here. The transaction root hash value can be calculated based on the third hash value of each transaction using a continuous XOR method.

[0178] Accordingly, the first blockchain node also performs the following steps:

[0179] determining a sixth hash value for each transaction in the at least one transaction;

[0180] Determine a hash value of the transaction to be verified based on the sixth hash value of each transaction;

[0181] If the hash value of the transaction to be verified is inconsistent with the transaction root hash value, it is determined that the consensus verification of the target transaction related message has failed;

[0182] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed, including:

[0183] If the hash value of the message to be verified is consistent with the message root hash value and the hash value of the transaction to be verified is consistent with the transaction root hash value, then the consensus verification of the target transaction-related message is determined to have passed.

[0184] Among them, the calculation method of the sixth hash value can refer to the calculation method of the third hash value, and the calculation method of the transaction hash value to be verified can refer to the calculation method of the transaction root hash value, which will not be repeated here.

[0185] In this embodiment, specifically, if the transaction is tampered with, the transaction hash value to be verified may be inconsistent with the transaction root hash value; if the transaction is not necessarily tampered with, the transaction hash value to be verified is consistent with the transaction root hash value.

[0186] According to the technical solution of this embodiment, if the hash value of the message to be verified is consistent with the message root hash value and the transaction hash value to be verified is consistent with the transaction root hash value, the consensus verification of the target transaction-related message is considered to have passed. If the hash value of the message to be verified is inconsistent with the message root hash value or the transaction hash value to be verified is inconsistent with the transaction root hash value, it is considered that the transaction has been tampered with. At this time, the consensus verification of the target transaction-related message fails. By combining the transaction root hash value and the message root hash value to perform consensus verification on the target transaction-related message, the accuracy of the verification can be improved, thereby improving the security of the transaction.

[0187] It should be noted that, generally speaking, a block includes a block header and a block body. The block body is generally used to store at least one transaction, and the block header is generally used to store the transaction and hash value. In this embodiment, the message root hash value and the transaction-related message tree can be stored in the block header or the block body. However, in some example situations, after the first blockchain node passes the consensus verification of the target transaction-related message, it is necessary to update the target block to the blockchain stored by the first blockchain node, but at this time, the message root hash value and the transaction-related message tree are stored in the block header or the block body, which causes the amount of chain data of the blockchain to be too large.

[0188] Therefore, in one possible implementation, the target block includes a block header, a block body, and a block body attachment, the transaction root hash value is stored in the block header, at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, and the message root hash value is stored in at least one item in the block header or the block body.

[0189] In another possible implementation, the block body attachment and the block header and block body may be configured in different blocks. For example, the block body attachment is configured in the target block, and the block header and block body are configured in other blocks. Then, the second blockchain node may send the target block and the other blocks to the first blockchain node respectively.

[0190] See also Figure 4 , Figure 4 A data structure diagram of a target block provided in an embodiment of the present application. Figure 4 As shown, at least one transaction is stored in the block body, a transaction-related message tree is stored in the block body attachment, and a message root hash value is stored in at least one item in the block header or the block body.

[0191] Accordingly, the first blockchain node is further used to perform the following steps:

[0192] When the consensus verification of the target transaction-related messages is passed, the transaction is executed based on the transaction data, source information and destination information in each target internal transaction message, and the data in the block body attachment is deleted, and the blockchain stored in the first blockchain node is updated based on the target block after the data is deleted.

[0193] In this embodiment, for example, the target transaction-related message is a transfer of C amount from account A to account B, and the executed transaction may be to reduce the C amount of account A and increase the C amount of account B.

[0194] Optionally, in the case where there are at least two target transaction-related messages, each target transaction-related message may be executed in sequence according to the second identifier corresponding to each of the at least two target transaction-related messages.

[0195] The technical solution of this embodiment stores the transaction-related message tree in the block body attachment, and stores the message root hash value in at least one of the block header or the block body. Then, when the consensus verification of the target transaction-related message is passed, the first blockchain node executes the transaction based on the transaction data, source information and destination information in each target internal transaction message, deletes the data in the block body attachment, and updates the blockchain stored by the first blockchain node based on the target block after the data is deleted, thereby reducing the amount of chain data of the blockchain.

[0196] It should be noted that the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, which may be that the second blockchain node determines the target transaction-related message and then sends it to the first blockchain node, or the first blockchain node determines the target transaction-related message from the transaction message tree in the target block sent by the second blockchain. The following embodiments are described respectively.

[0197] In one possible implementation, the second blockchain node stores the transaction-related message tree and the message root hash value in the target block, including:

[0198] If one of the full nodes synchronized by the first blockchain node is an untrusted node, the complete transaction-related message tree and the message root hash value are stored in the target block.

[0199] Accordingly, the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, including:

[0200] Determine a target account that the first blockchain node is paying attention to, and based on the target account, determine a target transaction-related message that meets a preset condition from a transaction-related message tree stored in the target block.

[0201] In this embodiment, the full node synchronized by the first blockchain node may be the full node connected to the first blockchain node in the blockchain network. Specifically, if one of the full nodes synchronized by the first blockchain node is an untrusted node, it means that there is a certain security risk at this time, so the second blockchain node is required to send the complete transaction-related message tree and the message root hash value to the first blockchain node, so that the first blockchain node can determine the target transaction-related message that meets the preset conditions from the transaction-related message tree stored in the target block based on the target account it is concerned about.

[0202] Optionally, the source information includes a source account, the destination information includes a destination account, and the preset conditions include:

[0203] At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

[0204] The technical solution of this embodiment is that when one of the full nodes synchronized by the first blockchain node is an untrusted node, the second blockchain node stores the complete transaction-related message tree and the message root hash value in the target block, so that the first blockchain node determines the target account that the first blockchain node is paying attention to, and based on the target account, determines the target transaction-related message that meets the preset conditions from the transaction-related message tree stored in the target block, thereby improving the security of the transaction.

[0205] Optionally, in this embodiment, the first blockchain node may send a trusted node identifier or an untrusted node identifier to the second blockchain node, the trusted node identifier indicating that the full node synchronized by the first blockchain node is a trusted node, and the untrusted node identifier indicating that the full node synchronized by the first blockchain node is an untrusted node. The second blockchain node may determine whether the full node synchronized by the first blockchain node is a trusted node or an untrusted node based on the trusted node identifier or the untrusted node identifier sent by the first blockchain node.

[0206] In another possible implementation, the second blockchain node stores the transaction-related message tree and the message root hash value in the target block, including:

[0207] If any full node synchronized by the first blockchain node is a trusted node, a target transaction-related message that meets a preset condition is determined in the transaction-related message tree, and other transaction-related messages except the target transaction-related message are deleted from the transaction-related message tree, and the transaction-related message tree and the message root hash value after deleting other transaction-related messages are stored in the target block.

[0208] Accordingly, the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, including:

[0209] Each transaction-related message in the transaction-related message tree serves as a target transaction-related message.

[0210] In this embodiment, the transaction-related messages in the transaction-related message tree stored in the target block may only include the target transaction-related messages.

[0211] See also Figure 5 , Figure 5 A schematic diagram of a transaction-related message tree stored in a target block provided in an embodiment of the present application. Figure 5As shown, assuming that the target transaction-related messages determined by the second blockchain node include transaction-related messages 1-1 and transaction-related messages 1-3, the transaction-related messages in the transaction-related message tree stored in the target block may only include transaction-related messages 1-1 and transaction-related messages 1-3. Then the hash value corresponding to H(1,1) is determined based on transaction-related message 1-1, and the hash value corresponding to H(1,3) is determined based on transaction-related message 1-3. As for the hash values ​​corresponding to H(1,2), H(2,1), H(2,2), H(3,1), H(3,2) and H(3,2), they have been determined by the second blockchain node and stored in the target block, from which the hash value of the message to be verified can be calculated.

[0212] According to the technical solution of this embodiment, since the second blockchain node only retains the target transaction-related messages before storing the transaction-related message tree in the target block, the first blockchain node can directly use any transaction-related message in the transaction-related message tree stored in the target block as the target transaction-related message, which not only reduces the bandwidth required to send the target block from the second blockchain node to the first blockchain node, but also reduces the storage and computing resources required for the first blockchain node to perform consensus verification.

[0213] In a possible implementation, if any full node synchronized by the first blockchain node is a trusted node, the transaction-related message tree and the message root hash value are stored in the target block, further comprising:

[0214] Deleting the second hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree;

[0215] The transaction-related message tree and the message root hash value after deleting other transaction-related messages are stored in the target block, including:

[0216] The transaction-related message tree and the message root hash value after deleting the second hash value corresponding to the second node connected to other transaction-related messages and the target transaction-related message are stored in the target block.

[0217] In this embodiment, since the second hash value corresponding to the second node connected to the target transaction-related message calculated by the second blockchain node does not need to be used by the first blockchain node in the consensus verification stage, the second hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree can also be deleted, thereby further reducing the transmission bandwidth and further reducing the computing resources of the first blockchain node for consensus verification.

[0218] In some example scenarios, since different blockchain nodes have different computing capabilities, in a possible implementation, the preset conditions also include:

[0219] The amount of transaction data is less than or equal to the data amount threshold corresponding to the first blockchain node.

[0220] It should be noted that the stronger the computing power of the first blockchain node, the larger the corresponding data volume threshold.

[0221] The technical solution of this embodiment, the preset conditions also include: the data volume of the transaction data is less than or equal to the data volume threshold corresponding to the first blockchain node, that is, the determined target transaction-related message is adapted to the computing power of the first blockchain node, thereby further reducing the bandwidth required for the target block transmission and improving the efficiency of the first blockchain node in consensus verification.

[0222] In a possible implementation, determining a target account that the first blockchain node is concerned about includes:

[0223] Obtain a preset account set associated with the first blockchain node, where the preset account set includes all accounts followed by the first blockchain node;

[0224] At least one account in the preset account set is used as a target account;

[0225] The method also includes:

[0226] In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained;

[0227] The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

[0228] In this embodiment, the preset account set may also optionally include all accounts that the first blockchain node does not pay attention to, so each account in the preset account set corresponds to a pay attention mark or a do not pay attention mark. Specifically, the accounts in the preset account set that correspond to the pay attention mark indicate that the account is an account that the first blockchain node pays attention to; the accounts in the preset account set that correspond to the do not pay attention mark indicate that the account is an account that the first blockchain node does not pay attention to.

[0229] For example, an example of a preset account set may be as follows:

[0230] IsWanted = {

[0231] Addr1=>True,

[0232] Addr2=>False,

[0233] Addr3=>True,

[0234] Addr4=>True,

[0235] …

[0236] }

[0237] Among them, IsWanted represents the preset account set, True represents the attention mark, and False represents the non-attention mark.

[0238] That is, the newly added account is set to True, and if the user no longer needs to follow the account in future operations, it is set to False.

[0239] The technical solution of this embodiment obtains a preset account set associated with the first blockchain node, and the preset account set includes all accounts followed by the first blockchain node; at least one account in the preset account set is used as a target account, and the accounts in the preset account set can be updated. Therefore, the preset account set can be updated as needed, that is, the target account followed by the first blockchain node can be adjusted as needed, thereby improving the flexibility of transaction verification.

[0240] It should be noted that the process of blockchain network maintenance is mainly divided into two stages. One is that the accounting node that obtains the accounting right packages the transactions within a period of time and then verifies the chain broadcast. The other is that the non-accounting node that does not obtain the accounting right synchronizes the block and verifies it. In the latter verification process, the relevant technology requires a complete verification of all transactions in the block, which requires a large amount of computing and storage resources. The purpose of the embodiment of the present application is to reduce the consumption of non-accounting nodes while retaining the security and availability of their data. In order to achieve this goal, the embodiment of the present application can improve the accounting node and the non-accounting node, and the two are interrelated. Therefore, for ease of understanding, the part executed by the accounting node is a block packaging scheme generated based on the transaction-related message set, and the other part executed by the non-accounting node is a block partial or full transaction-related message verification scheme. Since the non-accounting node is a block partial or full transaction-related message verification, that is, the non-accounting node verifies the message of concern, so the non-accounting node can also be understood as a concern node. Therefore, when broadcasting in the network, the block does not need to be broadcast to all nodes, but only needs to be broadcast to the concerned nodes.

[0241] For ease of understanding, the following embodiments illustrate the block packaging verification generated by the accounting node based on the transaction-related message set, and the verification of part or all transaction-related messages of the block of the non-accounting node.

[0242] See 6 and Figure 7 . Figure 6 A flowchart of a block packaging solution based on the generation of a transaction-related message set provided in an embodiment of the present application. Figure 7A flowchart of a transaction-related message verification solution provided in an embodiment of the present application.

[0243] First, the process of the block packaging scheme generated based on the transaction-related message set is as follows:

[0244] The modules are explained as follows:

[0245] Block body: Blockchain transactions that need to be uploaded to the chain within a period of time are packaged and obtained by the blockchain accounting node from the transaction memory pool.

[0246] Transaction Execution Tracker: A module that tracks the specific execution of accounts and smart contracts during the execution of blockchain transactions.

[0247] Transaction-related message set: A blockchain transaction is specifically reflected in a number of transaction messages during the execution process. The collection of all messages obtained is called the transaction-related message set.

[0248] Merkle tree corresponding to the transaction-related message set: The Merkle tree constructed by the transaction-related message set is described below.

[0249] Internal tree Merkle root: the hash value of the root of the Merkle tree corresponding to the transaction-related message set. The calculation method will be explained below.

[0250] Based on the above modules, such as Figure 6 The various steps in the process are described in detail as follows:

[0251] Step 1. Transaction execution:

[0252] At the beginning of a block consensus cycle, the blockchain accounting node obtains N transactions to be packaged within a period of time from the transaction memory pool, forms a block body, and executes all transactions one by one.

[0253] TXs = {TX1, TX2, ..., TX N}

[0254] In the following description, the block body is denoted as TXs, and the i-th transaction is denoted as TX i .

[0255] Step 2. Track transaction-related messages:

[0256] During the transaction execution process, the blockchain smart contract virtual machine is tracked, and a transaction-related message tracking module is implanted to obtain the transaction-related message InterMsg (TX i ),as follows:

[0257] InterMsg(TX i )=Trace(TX i)

[0258] Among them, Trace() is a tracing function executed in the smart contract virtual machine, which is used to obtain transaction-related messages. The transaction-related messages finally obtained are an array. For transaction i, the jth element in the array is the following tuple:

[0259] TX i [j]=<From,To,Data>

[0260] Among them, From is the initiating user account address after the signature is decoded for blockchain transactions, and for internal transactions triggered by transactions, it is the triggering contract account address. To is the target user or contract account address, and Data is the input to the smart contract.

[0261] Step 3. Build a transaction-related message tree:

[0262] This Merkle tree has three layers from the root node downwards, namely the transaction-related message hash layer, the transaction-related message hash layer, and the transaction-related message layer. Each layer has different forks, and the transaction-related message tree is constructed from the bottom up.

[0263] Step 4. Write to block attachment storage:

[0264] The transaction-related messages formed by the InterMsg obtained above, as well as each intermediate node in the tree, are serialized and encoded and written into the block body for storage as attachments.

[0265] Step 5. Generate the tree root:

[0266] First, take the overall hash value H for each transaction-related message.

[0267] H(i, j) = HASH(TX i [j].From+TX i [j].To+TX i [j].Data)

[0268] Here HASH is any hash function, such as md5, sha256, etc.

[0269] Then, for transaction i containing k transaction-related messages, the transaction-related messages are regarded as K-fork leaf nodes at the end of the transaction-related message tree. Therefore, for each transaction, the hash values ​​of the k transaction-related messages of the transaction are taken by continuous XOR:

[0270]

[0271] Finally, for a block with N transactions, construct H_root,

[0272]

[0273] Step 6. Write block header:

[0274] Write the generated H_root into the block header, and perform other writes such as status root, transaction root, receipt root, etc., and the packaging is completed.

[0275] Secondly, the flowchart of the transaction-related message verification scheme is as follows:

[0276] Each module is explained as follows: Follow-up account and follow-up account set: that is, the account whose status changes and transactions the first blockchain node needs to pay attention to and the set of accounts.

[0277] Transaction-related message executor: This is the module that ultimately verifies and executes specific smart contract messages.

[0278] Account execution result: that is, the final result obtained through the execution of transaction-related messages. It is necessary to ensure that for the account being followed, the result is consistent with the account status after the complete execution.

[0279] Based on the above modules, Figure 7 The steps in the following are described in detail:

[0280] Step 1. Input:

[0281] The user sets up a follow account AddrX, which can be a user account or a smart contract account, and enters it into the follow account collection.

[0282] Step 2. Preset account set:

[0283] Based on the multiple account addresses entered, the following preset account set IsWanted is generated:

[0284]

[0285]

[0286] That is, the newly added account is set to True, and if the first blockchain node no longer needs to pay attention to the account in future operations, it is set to False.

[0287] Step 3. Input block body:

[0288] Input the block body, i.e. the block transaction, into the transaction-related message executor.

[0289] Step 4. Verify the transaction tree root:

[0290] TX_root′ calculated according to the traditional blockchain transaction tree root verification method is compared with TX_root in the block header:

[0291] CHECK=EQUAL(TX_root,TX_root′)

[0292] Among them, TX_root′ indicates that CHECK is the hash value of the transaction to be verified, TX_root indicates the transaction root hash value, and the result of bitwise comparison of the two transaction tree roots by the EQUAL function. If CHECK is true, the execution continues; if CHECK is false, the block is illegal and the verification is abandoned.

[0293] Step 5. Enter the transaction-related message set:

[0294] Input the transaction-related message set in the block body attachment storage into the transaction-related message executor.

[0295] Step 6. Verify the transaction-related message tree root:

[0296] According to step 5 of the packaging scheme, calculate the transaction-related message tree and its root H_root′ by yourself, and compare it with H_root in the block header:

[0297] CHECK=EQUAL(H_root,H_root′)

[0298] Among them, H_root′ represents the hash value of the message to be verified, H_root represents the message root hash value, and CHECK is the result of bitwise comparison of the roots of two transaction-related message trees through the EQUAL function. If CHECK is true, the execution continues. If CHECK is false, the block is illegal and the verification is abandoned.

[0299] It should be noted that in the input and verification of steps 5 and 6, this patent does not require the synchronization of the complete block attachment storage, because this consumes a certain amount of network bandwidth. When the full node synchronized by the concerned node is untrusted, it is necessary to synchronize the complete block attachment storage and perform the process of steps 5 and 6 in full. However, when the full node synchronized by the concerned node is a trusted node, it is not necessary to synchronize. Figure 3 The bottom layer in the transaction-related message tree, that is, the transaction-related messages themselves of the incomplete synchronization transaction-related message tree, but only synchronize the penultimate layer and the required transaction-related messages, and the concerned node builds and verifies the internal tree root by itself to complete step 6, which can also achieve a certain security verification effect.

[0300] Step 7. Match and execute the account information:

[0301] According to the account table in step 2, traverse the transaction-related message tree (or partially synchronized transaction-related message tree) in the order of transaction order and transaction-related message subscripts. For account AddrX, if IsWanted[AddrX] is true, apply the transaction-related message in the local world state. Note that in the process of executing through the transaction-related message execution set, there is no need for signature verification as in traditional blockchain transaction execution, because the From of the signature verification result has been transmitted through the block body attachment storage. At this time, the block transaction itself only serves as an auxiliary verification of the legitimacy of the block.

[0302] In this embodiment, the block packaging scheme based on the generation of the internal message set and the block partial verification scheme for the user's concerned account are combined, so that in the process of blockchain synchronization, the concerned node does not need to fully verify all transactions, saving the computing resources of the central processing unit (CPU) and memory of the concerned node, and also saving the storage resources of the state, reducing the cost of verifying transactions. In addition, at the concerned node end, the accounts and transaction-related messages required to be concerned are verified, and the legitimacy of its blocks and the changes in account status are based on the results of its own independent execution. Compared with the light node mode that does not verify transactions at all, the concerned node has higher data security, local status, and higher data availability.

[0303] See also Figure 8 , Figure 8 A schematic diagram of a transaction processing device based on blockchain provided in an embodiment of the present application. Figure 8 The blockchain-based transaction processing device 800 shown may include a first acquisition module 810, a second acquisition module 820, a message tree construction module 830, a hash value determination module 840 and a first transaction processing module 850, wherein:

[0304] A first acquisition module 810, configured to acquire at least one transaction in a transaction memory pool;

[0305] A second acquisition module 820 is used to execute each transaction of the at least one transaction and acquire a transaction-related message set obtained in the process of executing the transaction, wherein the transaction-related message set includes a transaction-related message corresponding to each transaction, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data;

[0306] A message tree construction module 830 is used to construct a transaction-related message tree based on the transaction-related message set, wherein the transaction-related message tree includes first nodes, second nodes connected to each first node, and transaction-related messages connected to each second node in a one-to-one correspondence, wherein each first node represents a first hash value of a transaction, and each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction;

[0307] A hash value determination module 840, configured to determine a message root hash value of a transaction-related message set based on the first hash value corresponding to each first node;

[0308] The first transaction processing module 850 is used to store the transaction-related message tree and the message root hash value in the target block, and send the target block to the first blockchain node, so that the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

[0309] Optionally, the message tree construction module 830 determines the second hash value corresponding to each second node of the transaction-related message tree in the following manner:

[0310] Determine a first sub-hash value of transaction data, a second sub-hash value of source information, and a third sub-hash value of destination information in a transaction-related message connected to the second node;

[0311] Based on the first sub-hash value, the second sub-hash value, and the third sub-hash value corresponding to the transaction-related message connected to the second node, a second hash value corresponding to the second node is determined, wherein the second hash value is positively correlated with the first sub-hash value, the second sub-hash value, and the third sub-hash value, respectively.

[0312] Optionally, the hash value determination module 840 is further configured to determine a third hash value for each transaction in the at least one transaction;

[0313] Determining a transaction root hash value of at least one transaction based on the third hash value of each transaction;

[0314] When storing the transaction-related message tree and the message root hash value in the target block, the first transaction processing module 850 may be used to:

[0315] The transaction-related message tree, the message root hash value, and the transaction root hash value are stored in the target block, so that when the first blockchain node performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, it also performs consensus verification on the target transaction-related message based on the transaction root hash value.

[0316] Optionally, the target block includes a block header, a block body and a block body attachment, the transaction root hash value is stored in the block header, at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, and the message root hash value is stored in at least one item in the block header or the block body.

[0317] Optionally, the first transaction processing module 850 can be used to store the transaction-related message tree and the message root hash value in the target block:

[0318] If one of the full nodes synchronized by the first blockchain node is an untrusted node, the complete transaction-related message tree and the message root hash value are stored in the target block;

[0319] If any full node synchronized by the first blockchain node is a trusted node, a target transaction-related message that meets a preset condition is determined in the transaction-related message tree, and other transaction-related messages except the target transaction-related message are deleted from the transaction-related message tree, and the transaction-related message tree and the message root hash value after deleting other transaction-related messages are stored in the target block.

[0320] Optionally, when determining the target transaction-related message that meets the preset condition in the transaction-related message tree, the first transaction processing module 850 may be used to:

[0321] Determine the target account that the first blockchain node is following;

[0322] Based on the target account, determine the target transaction-related message that meets the preset conditions from the transaction-related message tree;

[0323] The source information includes the source account, the destination information includes the destination account, and the preset conditions include:

[0324] At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

[0325] Optionally, when determining the target account that the first blockchain node is following, the first transaction processing module 850 may be used to:

[0326] Obtain a preset account set associated with the first blockchain node, where the preset account set includes all accounts followed by the first blockchain node;

[0327] At least one account in the preset account set is used as a target account;

[0328] The first transaction processing module 850 may also be used to:

[0329] In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained;

[0330] The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

[0331] See also Fig. 9 , Fig. 9 A schematic diagram of the structure of another blockchain-based transaction processing device provided in an embodiment of the present application. Fig. 9The blockchain-based transaction processing device 900 shown may include a third acquisition module 910, a target message determination module 920, and a second transaction processing module 930, wherein:

[0332] The third acquisition module 910 is used to acquire a target block from the second blockchain node, the target block stores a message root hash value and a transaction-related message tree, the transaction-related message tree stored in the target block includes a first node, a second node connected to each first node, and a transaction-related message connected to at least one second node in a one-to-one correspondence, a first node represents a first hash value of a transaction in at least one transaction, each second node connected to a first node represents a second hash value of each transaction-related message corresponding to a transaction, at least one transaction is acquired from a transaction memory pool, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data;

[0333] A target message determination module 920, configured to determine a target transaction-related message that meets a preset condition in a transaction-related message tree stored in a target block;

[0334] The second transaction processing module 930 is used to perform consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

[0335] Optionally, when the second transaction processing module 930 performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, it can be used to:

[0336] For each target transaction-related message, determining a fourth hash value of the target transaction-related message;

[0337] For each target transaction-related message, using the fourth hash value of the target transaction-related message as the hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree;

[0338] For each first node in the transaction-related message tree stored in the target block, determine a fifth hash value corresponding to the first node based on a hash value corresponding to each second node connected to the first node;

[0339] Determine a hash value of the message to be verified based on the fifth hash value corresponding to each first node;

[0340] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed;

[0341] If the hash value of the message to be verified is inconsistent with the message root hash value, it is determined that the consensus verification of the target transaction related message has failed.

[0342] Optionally, when determining the fourth hash value of the target transaction-related message, the second transaction processing module 930 may be used to:

[0343] Determine a fourth sub-hash value of the transaction data, a fifth sub-hash value of the source information, and a sixth sub-hash value of the destination information in the target transaction-related message;

[0344] Based on the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value corresponding to the target transaction-related message, a fourth hash value of the target transaction-related message is determined, wherein the fourth hash value is positively correlated with the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value, respectively.

[0345] Optionally, the target block further stores at least one transaction and a transaction root hash value, and the second transaction processing module 930 can also be used to:

[0346] determining a sixth hash value for each transaction in the at least one transaction;

[0347] Determine a hash value of the transaction to be verified based on the sixth hash value of each transaction;

[0348] If the hash value of the transaction to be verified is inconsistent with the transaction root hash value, it is determined that the consensus verification of the target transaction related message has failed;

[0349] If the hash value of the message to be verified is consistent with the message root hash value, the consensus verification of the target transaction-related message is determined to have passed, including:

[0350] If the hash value of the message to be verified is consistent with the message root hash value and the hash value of the transaction to be verified is consistent with the transaction root hash value, then the consensus verification of the target transaction-related message is determined to have passed.

[0351] Optionally, the target block includes a block header, a block body, and a block body attachment, the transaction root hash value is stored in the block header, at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, the message root hash value is stored in the block header or the block body attachment, and the second transaction processing module 930 is further used to:

[0352] When the consensus verification of the target transaction-related messages is passed, the transaction is executed based on the transaction data, source information and destination information in each target internal transaction message, and the data in the block body attachment is deleted, and the blockchain stored in the first blockchain node is updated based on the target block after the data is deleted.

[0353] Optionally, when determining the target transaction-related message that meets the preset condition in the transaction-related message tree stored in the target block, the second transaction processing module 930 may be used for any of the following:

[0354] Each transaction-related message in the transaction-related message tree is used as a target transaction-related message, wherein the transaction-related message tree stored in the target block is obtained by determining the target transaction-related message that meets the preset conditions in the transaction-related message tree and deleting other transaction-related messages except the target transaction-related message;

[0355] Determine a target account that the first blockchain node is concerned about, and based on the target account, determine a target transaction-related message that meets a preset condition from a transaction-related message tree stored in a target block;

[0356] The source information includes the source account, the destination information includes the destination account, and the preset conditions include:

[0357] At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

[0358] Optionally, when determining the target account that the first blockchain node is following, the second transaction processing module 930 may be used to:

[0359] Obtain a preset account set associated with the first blockchain node, where the preset account set includes all accounts followed by the first blockchain node;

[0360] At least one account in the preset account set is used as a target account;

[0361] The second transaction processing module 930 may also be used for:

[0362] In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained;

[0363] The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

[0364] The device of the embodiments of the present application can execute the method provided by the embodiments of the present application, and the implementation principles are similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed functional description of each module of the device, please refer to the description in the corresponding method shown in the previous text, which will not be repeated here.

[0365] An embodiment of the present application provides an electronic device, including a memory, a processor, and a computer program stored in the memory, and the processor executes the above computer program to implement the steps of any embodiment of the present application.

[0366] In an alternative embodiment, an electronic device is provided, such as Fig.10 As shown, Fig.10 The electronic device 1000 shown includes: a processor 1001 and a memory 1003. The processor 1001 and the memory 1003 are connected, such as through a bus 1002. Optionally, the electronic device 1000 may also include a transceiver 1004, which may be used for data interaction between the electronic device and other electronic devices, such as data transmission and / or data reception. It should be noted that in actual applications, the transceiver 1004 is not limited to one, and the structure of the electronic device 1000 does not constitute a limitation on the embodiments of the present application.

[0367] Processor 1001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 1001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0368] The bus 1002 may include a path to transmit information between the above components. The bus 1002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 1002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0369] The memory 1003 may be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, without limitation herein.

[0370] The memory 1003 is used to store the computer program for executing the embodiment of the present application, and the execution is controlled by the processor 1001. The processor 1001 is used to execute the computer program stored in the memory 1003 to implement the steps shown in the above method embodiment.

[0371] An embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps and corresponding contents of the aforementioned method embodiment can be implemented.

[0372] The embodiment of the present application also provides a computer program product, including a computer program, which can implement the steps and corresponding contents of the aforementioned method embodiment when executed by a processor.

[0373] It should be understood that, although each operation step is indicated by arrows in the flowchart of the embodiment of the present application, the implementation order of these steps is not limited to the order indicated by the arrows. Unless clearly stated herein, in some implementation scenarios of the embodiment of the present application, the implementation steps in each flowchart can be performed in other orders according to demand. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on actual implementation scenarios. Some or all of these sub-steps or stages may be executed at the same time, and each sub-step or stage in these sub-steps or stages may also be executed at different times respectively. In different scenarios of execution time, the execution order of these sub-steps or stages may be flexibly configured according to demand, and the embodiment of the present application does not limit this.

[0374] The above are only optional implementation methods for some implementation scenarios of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the technical concept of the scheme of the present application, other similar implementation methods based on the technical ideas of the present application are also within the protection scope of the embodiments of the present application.

Claims

1. A transaction processing method based on blockchain, characterized in that: include: Get at least one transaction in the transaction memory pool; Execute each transaction of the at least one transaction, and obtain a transaction-related message set obtained in the process of executing the transaction, wherein the transaction-related message set includes a transaction-related message corresponding to each transaction, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data; Constructing a transaction-related message tree based on the transaction-related message set, the transaction-related message tree comprising first nodes, second nodes connected to each of the first nodes, and the transaction-related messages connected to each of the second nodes in a one-to-one correspondence, one of the first nodes representing a first hash value of a transaction, and each of the second nodes connected to one of the first nodes representing a second hash value of each transaction-related message corresponding to a transaction; Determine a message root hash value of the transaction-related message set based on the first hash value corresponding to each of the first nodes; The transaction-related message tree and the message root hash value are stored in a target block, and the target block is sent to a first blockchain node, so that the first blockchain node determines a target transaction-related message that meets a preset condition in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

2. The method according to claim 1, characterized in that The second hash value corresponding to each second node of the transaction-related message tree is determined in the following manner: Determine a first sub-hash value of the transaction data, a second sub-hash value of the source information, and a third sub-hash value of the destination information in the transaction-related message connected by the second node; Based on the first sub-hash value, the second sub-hash value, and the third sub-hash value corresponding to the transaction-related message connected to the second node, determine the second hash value corresponding to the second node, wherein the second hash value is positively correlated with the first sub-hash value, the second sub-hash value, and the third sub-hash value, respectively.

3. The method according to claim 1, characterized in that The target block pre-stores the at least one transaction, and the method further includes: determining a third hash value for each transaction of the at least one transaction; Determining a transaction root hash value of the at least one transaction based on the third hash value of each transaction; The storing the transaction-related message tree and the message root hash value into a target block includes: The transaction-related message tree, the message root hash value and the transaction root hash value are stored in the target block, so that when the first blockchain node performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block, it also performs consensus verification on the target transaction-related message based on the transaction root hash value.

4. The method according to claim 3, characterized in that The target block includes a block header, a block body and a block body attachment, the transaction root hash value is stored in the block header, the at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, and the message root hash value is stored in at least one of the block header or the block body.

5. The method according to any one of claims 1 to 4, characterized in that: The storing the transaction-related message tree and the message root hash value into a target block includes: If one of the full nodes synchronized by the first blockchain node is an untrusted node, storing the complete transaction-related message tree and the message root hash value in the target block; If any full node synchronized by the first blockchain node is a trusted node, a target transaction-related message that meets a preset condition in the transaction-related message tree is determined, and other transaction-related messages except the target transaction-related message in the transaction-related message tree are deleted, and the transaction-related message tree and the message root hash value after deleting the other transaction-related messages are stored in the target block.

6. The method according to claim 5, characterized in that The determining of a target transaction-related message that meets a preset condition in the transaction-related message tree includes: Determine a target account followed by the first blockchain node; Based on the target account, determining a target transaction-related message that meets a preset condition from the transaction-related message tree; The source information includes a source account, the destination information includes a destination account, and the preset conditions include: At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

7. The method according to claim 6, characterized in that The determining a target account followed by the first blockchain node includes: Obtain a preset account set associated with the first blockchain node, wherein the preset account set includes all accounts followed by the first blockchain node; Using at least one account in the preset account set as the target account; The method further comprises: In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained; The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

8. A transaction processing method based on blockchain, characterized in that: include: Obtain a target block from a second blockchain node, wherein the target block stores a message root hash value and a transaction-related message tree, wherein the transaction-related message tree stored in the target block includes a first node, second nodes connected to each of the first nodes, and the transaction-related messages connected to at least one of the second nodes in a one-to-one correspondence, wherein one of the first nodes represents a first hash value of a transaction in at least one transaction, and each of the second nodes connected to the first node represents a second hash value of each transaction-related message corresponding to a transaction, wherein the at least one transaction is obtained from a transaction memory pool, and the transaction-related messages include transaction data, source information of the transaction data, and destination information of the transaction data; Determine a target transaction-related message that meets a preset condition in the transaction-related message tree stored in the target block; Consensus verification is performed on the target transaction-related message based on the transaction-related message tree stored in the target block and the message root hash value.

9. The method according to claim 8, characterized in that The consensus verification of the target transaction-related message based on the transaction-related message tree stored in the target block and the message root hash value includes: For each target transaction-related message, determining a fourth hash value of the target transaction-related message; For each target transaction-related message, using the fourth hash value of the target transaction-related message as the hash value corresponding to the second node connected to the target transaction-related message in the transaction-related message tree; For each first node in the transaction-related message tree stored in the target block, determine a fifth hash value corresponding to the first node based on a hash value corresponding to each second node connected to the first node; Determine a hash value of the message to be verified based on the fifth hash value corresponding to each first node; If the hash value of the message to be verified is consistent with the message root hash value, it is determined that the consensus verification of the target transaction-related message has passed; If the hash value of the message to be verified is inconsistent with the message root hash value, it is determined that the consensus verification of the target transaction related message fails.

10. The method according to claim 9, characterized in that The determining of the fourth hash value of the target transaction-related message includes: Determine a fourth sub-hash value of the transaction data, a fifth sub-hash value of the source information, and a sixth sub-hash value of the destination information in the target transaction-related message; Based on the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value corresponding to the target transaction-related message, a fourth hash value of the target transaction-related message is determined, wherein the fourth hash value is positively correlated with the fourth sub-hash value, the fifth sub-hash value, and the sixth sub-hash value, respectively.

11. The method according to claim 9, characterized in that The target block also stores the at least one transaction and the transaction root hash value, and the method further includes: determining a sixth hash value for each transaction of the at least one transaction; Determine a hash value of the transaction to be verified based on the sixth hash value of each transaction; If the hash value of the transaction to be verified is inconsistent with the transaction root hash value, it is determined that the consensus verification of the target transaction related message fails; If the hash value of the message to be verified is consistent with the message root hash value, then determining that the consensus verification of the target transaction-related message has passed includes: If the hash value of the message to be verified is consistent with the message root hash value and the hash value of the transaction to be verified is consistent with the transaction root hash value, it is determined that the consensus verification of the target transaction-related message has passed.

12. The method according to claim 11, characterized in that Applied to a first blockchain node, the target block includes a block header, a block body, and a block body attachment, the transaction root hash value is stored in the block header, the at least one transaction is stored in the block body, the transaction-related message tree is stored in the block body attachment, the message root hash value is stored in the block header or the block body attachment, and the method further includes: When the consensus verification of the target transaction-related message is passed, the transaction is executed based on the transaction data, the source information and the destination information in each target internal transaction message, and the data in the block body attachment is deleted, and the blockchain stored in the first blockchain node is updated based on the target block after the data is deleted.

13. The method according to any one of claims 8 to 12, characterized in that: Applied to the first blockchain node, the determining of the target transaction-related message that satisfies the preset condition in the transaction-related message tree stored in the target block includes any one of the following: Taking each transaction-related message in the transaction-related message tree as a target transaction-related message, wherein the transaction-related message tree stored in the target block is obtained by determining the target transaction-related message that meets the preset conditions in the transaction-related message tree and deleting other transaction-related messages except the target transaction-related message; Determine a target account that the first blockchain node is following, and based on the target account, determine a target transaction-related message that meets a preset condition from a transaction-related message tree stored in the target block; The source information includes a source account, the destination information includes a destination account, and the preset conditions include: At least one of the source account or the destination account in the transaction-related message is consistent with the account followed by the first blockchain node.

14. The method according to claim 13, characterized in that The determining a target account followed by the first blockchain node includes: Obtain a preset account set associated with the first blockchain node, wherein the preset account set includes all accounts followed by the first blockchain node; Using at least one account in the preset account set as the target account; The method further comprises: In response to the update operation on the preset account set, the preset account set is updated to obtain a new preset account set, so that when the preset account set associated with the first blockchain node is obtained, the new preset account set associated with the first blockchain node is obtained; The update operation includes increasing or decreasing the accounts followed by the first blockchain node in the preset account set.

15. A blockchain network, characterized in that: It includes a first blockchain node and a second blockchain node, wherein: The second blockchain node is used to obtain at least one transaction in the transaction memory pool, execute each transaction in the at least one transaction, and obtain a transaction-related message set obtained in the process of executing the transaction, wherein the transaction-related message set includes a transaction-related message corresponding to each transaction, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data; a transaction-related message tree is constructed based on the transaction-related message set, wherein the transaction-related message tree includes a first node, a second node connected to each of the first nodes, and the transaction-related messages connected to each of the second nodes in a one-to-one correspondence; one of the first nodes represents a first hash value of a transaction, and each of the second nodes connected to one of the first nodes represents a second hash value of each transaction-related message corresponding to a transaction; a message root hash value of the transaction-related message set is determined based on the first hash value corresponding to each of the first nodes; the transaction-related message tree and the message root hash value are stored in a target block, and the target block is sent to the first blockchain node; The first blockchain node is used to determine the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and perform consensus verification on the target transaction-related message based on the transaction-related message tree stored in the target block and the message root hash value.

16. A transaction processing device based on blockchain, characterized in that: include: A first acquisition module, used to acquire at least one transaction in the transaction memory pool; a second acquisition module, configured to execute each transaction of the at least one transaction, and acquire a transaction-related message set obtained in the process of executing the transaction, wherein the transaction-related message set includes a transaction-related message corresponding to each transaction, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data; a message tree construction module, configured to construct a transaction-related message tree based on the transaction-related message set, wherein the transaction-related message tree includes first nodes, second nodes connected to each of the first nodes, and the transaction-related messages connected to each of the second nodes in a one-to-one correspondence, wherein each of the first nodes represents a first hash value of a transaction, and each of the second nodes connected to each of the first nodes represents a second hash value of each of the transaction-related messages corresponding to a transaction; A hash value determination module, configured to determine a message root hash value of the transaction-related message set based on the first hash values ​​corresponding to the first nodes; The first transaction processing module is used to store the transaction-related message tree and the message root hash value in a target block, and send the target block to a first blockchain node, so that the first blockchain node determines the target transaction-related message that meets the preset conditions in the transaction-related message tree stored in the target block, and performs consensus verification on the target transaction-related message based on the transaction-related message tree and the message root hash value stored in the target block.

17. A transaction processing device based on blockchain, characterized in that: include: A third acquisition module is used to acquire a target block from a second blockchain node, wherein the target block stores a message root hash value and a transaction-related message tree, wherein the transaction-related message tree stored in the target block includes a first node, second nodes connected to each of the first nodes, and the transaction-related message connected to at least one of the second nodes in a one-to-one correspondence, wherein one of the first nodes represents a first hash value of a transaction in at least one transaction, and each of the second nodes connected to the first node represents a second hash value of each transaction-related message corresponding to a transaction, wherein the at least one transaction is acquired from a transaction memory pool, and the transaction-related message includes transaction data, source information of the transaction data, and destination information of the transaction data; A target message determination module, used to determine a target transaction-related message that meets a preset condition in the transaction-related message tree stored in the target block; The second transaction processing module is used to perform consensus verification on the target transaction-related message based on the transaction-related message tree stored in the target block and the message root hash value.

18. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 14.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

20. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images