Block chain transaction processing method and system

Abstract

The invention discloses a block chain transaction processing method and system, and the method comprises the steps: enabling an archive node to carry out the pre-execution transaction according to a transaction request when the archive node in a block chain receives the transaction request, and generating transaction packaging data; a plurality of consensus nodes in the block chain determine a block consensus node based on a preset consensus algorithm; the block discharger consensus node verifies the transaction packaging data by adopting a preset digital signature algorithm; if the verification is passed, the block discharger consensus node judges whether the data type of the transaction packed data is a frozen type or not based on a preset freezing protocol condition; if yes, updating a data storage tree of the block discharger consensus node by the block discharger consensus node, determining a data storage tree at a future moment, and stopping the transaction; if not, the block discharger consensus node carries out transaction by adopting the transaction packaging data, and a target transaction result is generated; the technical problems that the transaction execution efficiency is lower and lower and the storage overhead is higher and higher due to an existing scheme of executing the transaction in the block chain are solved.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a blockchain transaction processing method and system. Background Art

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm.

[0003] Blockchain usually combines data blocks in a sequential manner in chronological order to form a chain data structure, and at the same time uses cryptography to ensure that it is a distributed ledger that cannot be tampered with or forged. Due to the characteristics of blockchain such as decentralization, information cannot be tampered with, and autonomy, blockchain has also received more and more attention and application.

[0004] In the existing solution for executing transactions in the blockchain, each time a node executes a transaction, it will bring about a change in the blockchain state, which requires modifying the state tree. For example, if a new account needs to be created in a transaction, the state tree will add a new state to the leaf node, thereby increasing the storage capacity of the blockchain state tree. As the number of blockchain states continues to increase, the height of the state tree also continues to increase, which reduces the efficiency of reading and writing states during transaction execution, resulting in lower and lower efficiency of transaction execution and higher and higher storage overhead. Summary of the invention

[0005] The present invention provides a blockchain transaction processing method and system, which are used to solve the technical problems that the existing solution for executing transactions in the blockchain leads to lower and lower transaction execution efficiency and higher and higher storage overhead.

[0006] A first aspect of the present invention provides a blockchain transaction processing method, comprising:

[0007] When an archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction packaging data;

[0008] The multiple consensus nodes in the blockchain determine the block producer consensus node based on a preset consensus algorithm;

[0009] The block producer consensus node verifies the transaction package data using a preset digital signature algorithm;

[0010] If the verification is successful, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions;

[0011] If so, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at the future time, and stops the transaction;

[0012] If not, the block producer consensus node uses the transaction packaging data to conduct transactions and generate the target transaction result.

[0013] Optionally, the transaction request includes transaction data and a digital signature; the transaction packaged data includes first transaction packaged data and second transaction packaged data; the archive node performs a pre-execution transaction according to the transaction request to generate the transaction packaged data, including:

[0014] The archive node verifies the digital signature based on the preset digital signature algorithm;

[0015] If the verification is successful, the archive node determines whether the data type of the transaction data is a frozen type based on the preset freezing protocol conditions;

[0016] If the data type of the transaction data is not a frozen type, the archive node determines whether a transaction read set corresponding to the transaction data exists in the current storage tree or cache storage tree of the archive node;

[0017] If neither the current storage tree nor the cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node generates a Merkle proof according to the state data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node;

[0018] The archive node uses the transaction data and the Merkle proof to perform a pre-transaction and generate a transaction write set;

[0019] The archive node packages the transaction write set, the transaction read set corresponding to the transaction data in the global storage tree of the archive node, the transaction data, the digital signature and the Merkle proof to generate first transaction package data;

[0020] If the current storage tree or cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the state data of the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node to perform a pre-transaction and generate a transaction write set;

[0021] The archive node packages the transaction write set, the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node, the transaction data and the digital signature to generate second transaction package data.

[0022] Optionally, the transaction packaging data further includes third transaction packaging data; and the method further includes:

[0023] If the data type of the transaction data is a frozen type, the archive node packages the transaction data and the digital signature to generate third transaction packaged data.

[0024] Optionally, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on a preset freezing protocol condition, including:

[0025] The block producer consensus node determines whether the transaction data in the transaction packaging data has a frozen identifier;

[0026] If so, the block producer consensus node determines that the data type of the transaction data is a frozen type;

[0027] If not, the block producer consensus node determines that the data type of the transaction data is not a frozen type.

[0028] Optionally, the data storage tree of the producer consensus node includes the current storage tree of the producer consensus node and the cache storage tree of the producer consensus node; the future-time data storage tree includes the cache storage tree at the future time and the current storage tree at the future time; the producer consensus node updates the data storage tree of the producer consensus node to determine the data storage tree at the future time, including:

[0029] The block producer consensus node uses the current storage tree of the block producer consensus node as the cache storage tree at the future moment;

[0030] The block producer consensus node clears data on the current storage tree of the block producer consensus node to determine the current storage tree at a future time.

[0031] Optionally, the block producer consensus node uses the transaction packaging data to conduct a transaction to generate a target transaction result, including:

[0032] The block producer consensus node determines whether the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data;

[0033] If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node has the transaction read-write set corresponding to the transaction data, the block producer consensus node uses the Merkel proof in the transaction package data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to perform the transaction and generate the target transaction result;

[0034] If the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, the block producer consensus node uses the status data of the transaction read-write set corresponding to the transaction data and the transaction data in the transaction packaging data to perform the transaction and generate the target transaction result.

[0035] Optionally, after the block producer consensus node uses the transaction packaging data to conduct a transaction and generate a target transaction result, the following steps are included:

[0036] The block producer consensus node constructs an initial block, and merges the target transaction result with the initial block to determine the target block;

[0037] The block producer consensus node broadcasts the target block to multiple nodes of the blockchain;

[0038] Multiple nodes of the blockchain verify the target block;

[0039] If the verification is successful, multiple nodes in the blockchain add the target block to the local blockchain of each node to determine a new blockchain.

[0040] A second aspect of the present invention provides a blockchain transaction processing system, comprising:

[0041] A pre-transaction module, which is used for, when an archive node in the blockchain receives a transaction request, the archive node performs a pre-transaction according to the transaction request and generates transaction packaging data;

[0042] A determination module, used for multiple consensus nodes in the blockchain to determine a block producer consensus node based on a preset consensus algorithm;

[0043] A verification module, used for the block producer consensus node to verify the transaction packaging data using a preset digital signature algorithm;

[0044] A judgment module, used for judging whether the data type of the transaction package data is a frozen type based on a preset freezing protocol condition if the verification is passed;

[0045] An update module, used for, if yes, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction;

[0046] The transaction module is used for, if not, the block producer consensus node uses the transaction packaging data to conduct transactions and generate a target transaction result.

[0047] A third aspect of the present invention provides a blockchain transaction processing method, which is applied to an archive node in a blockchain, comprising:

[0048] When receiving a transaction request, performing a pre-execution transaction according to the transaction request and generating transaction packaging data;

[0049] In response to the received target request, the transaction packaging data is sent to the block producer consensus node in the blockchain.

[0050] A fourth aspect of the present invention provides a blockchain transaction processing method, which is applied to a block producer consensus node in a blockchain, comprising:

[0051] Sending a target request to an archive node in the blockchain, and obtaining transaction package data sent by the archive node in the blockchain;

[0052] Using a preset digital signature algorithm to verify the transaction package data;

[0053] If the verification is successful, based on the preset freezing protocol conditions, determine whether the data type of the transaction packaged data is a frozen type;

[0054] If so, update the data storage tree of the consensus node of the block producer, determine the data storage tree at the future time, and stop the transaction;

[0055] If not, the transaction is performed using the transaction packaging data to generate a target transaction result.

[0056] It can be seen from the above technical solutions that the present invention has the following advantages:

[0057] The above technical scheme of the present invention provides a blockchain transaction processing method, when the archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction package data; multiple consensus nodes in the blockchain determine the block producer consensus node based on a preset consensus algorithm; the block producer consensus node uses a preset digital signature algorithm to verify the transaction package data; if the verification is passed, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on a preset freezing protocol condition; if so, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction; if not, the block producer consensus node uses the transaction package data to trade and generate a target transaction result; based on the above scheme, the data type of the transaction package data is determined by presetting the freezing protocol condition, and the corresponding transaction processing is performed according to the corresponding data type, which can reduce the data stored by the consensus node, improve the efficiency of executing transactions, and further reduce storage overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0059] Figure 1 A flowchart of a blockchain transaction processing method provided in Embodiment 1 of the present invention;

[0060] Figure 2 A schematic diagram of the structure of an Ethereum account model provided in Embodiment 1 of the present invention;

[0061] Figure 3 A schematic diagram of the protocol architecture and steps provided in the first embodiment of the present invention;

[0062] Figure 4 A flowchart of a blockchain transaction processing method provided in Embodiment 2 of the present invention;

[0063] Figure 5 A schematic diagram of the structure of a new contract account model provided in the second embodiment of the present invention;

[0064] Figure 6 A structural diagram of a data storage tree update mode of a block producer consensus node provided in Embodiment 2 of the present invention;

[0065] Figure 7 A block diagram of a blockchain transaction processing system provided in Embodiment 3 of the present invention;

[0066] Figure 8 A flowchart of the steps of a blockchain transaction processing method for an archive node in a blockchain provided in Embodiment 4 of the present invention;

[0067] Fig. 9 A flowchart of the steps of a blockchain transaction processing method applied to a block producer consensus node in a blockchain provided in Embodiment 5 of the present invention. DETAILED DESCRIPTION

[0068] The embodiments of the present invention provide a blockchain transaction processing method and system, which are used to solve the technical problems that the existing solution for executing transactions in the blockchain leads to lower and lower transaction execution efficiency and higher and higher storage overhead.

[0069] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0070] Terminology explanation:

[0071] Blockchain: A shared database in which the data or information stored has the characteristics of "unforgeable", "leaving traces throughout the process", "traceable", "open and transparent", and "collectively maintained".

[0072] Blockchain node: A node in a blockchain network that needs to store data in the blockchain, including the blockchain status.

[0073] Blockchain status: account data in the blockchain, including account name, account balance, etc. Accounts include external accounts and contract accounts.

[0074] Smart Contract (SC): A program deployed in the blockchain that realizes the automated processing of traditional contracts in the form of computer instructions, that is, a piece of code that is triggered and executed when the two parties trade on the blockchain. It has a code part and a state part. The state part is the variables that need to be stored in the code.

[0075] Ethereum: A mainstream blockchain application.

[0076] State tree: Ethereum generally stores the blockchain state in a tree structure for faster indexing and verification. The leaf nodes of the state tree store the blockchain state.

[0077] Storage tree: Saves variables that need to be saved for a long time in the smart contract (i.e. the state part). Each smart contract account will save a storage tree.

[0078] See also Figure 1 , Figure 1 A flowchart of a blockchain transaction processing method provided in accordance with the first embodiment of the present invention.

[0079] The present invention provides a blockchain transaction processing method, comprising:

[0080] Step 101: When the archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction packaging data.

[0081] It should be noted that a transaction request containing a digital signature is submitted by an Ethereum account to the archive node. The transaction request contains transaction data. The digital signature of the transaction with the account After receiving it, the archive node uses the transaction request to pre-execute the transaction and generate transaction packaging data. The transaction write set in the transaction packaging data will be stored in the current storage tree and cache storage tree of the archive node; when the archive node receives the target request sent by the block producer consensus node, the archive node sends the transaction packaging data to the block producer consensus node; among them, the pre-execution transaction is to simulate the transaction execution, resulting in a series of state changes, the transaction data is maintained by the transaction tree, and the state data is maintained by the state tree. The transaction tree root and the state tree root are both separate fields in the block header, and they are all Merkle trees. However, since it is a pre-execution result, the archive node is not responsible for the consensus function, so these results are only to provide data for the consensus node when needed, and the function of producing blocks is still performed by the consensus node.

[0082] For further information, see Figure 2 Currently, Ethereum accounts are divided into external accounts and contract accounts, such as Figure 2 As shown, the external account contains the total number of transactions Nonce and the balance Balance executed by the account, and the contract account contains the total number of transactions Nonce executed by the account, the balance Balance, the storage tree root StorageRoot and the code area hash value CodeHash, where the storage tree root is the root node of the storage tree, and the storage tree is used to save variables that need to be saved for a long time in the smart contract (the storage tree is part of the state tree). The present invention mainly focuses on the storage tree area of ​​the contract account.

[0083] It is worth mentioning that the status data of the transaction read set and the status data of the transaction write set corresponding to the transaction data on the current storage tree and cache storage tree of the archive node are the same as the status data of the transaction read set and the status data of the transaction write set corresponding to the transaction data on the current storage tree and cache storage tree of the consensus node, that is, if the status data of the transaction read set and the status data of the transaction write set corresponding to the transaction data exist on the current storage tree and cache storage tree of the archive node, the status data of the transaction read set and the status data of the transaction write set corresponding to the transaction data will also exist on the current storage tree and cache storage tree of the consensus node.

[0084] Furthermore, for the status data of the read-write set (i.e., the status data of the transaction read set and the status of the transaction write set), the transaction read set refers to the account status information read from the world state of the blockchain during the execution of a transaction. For example, when a smart contract is executed, the contract may read the storage data of other accounts (such as balances, variable values, etc.) to perform corresponding logical judgments.

[0085] Each transaction in Ethereum involves reading the balance and random number of the initiator's account to ensure that the initiator has enough balance to pay the transaction fee and that the transaction is not repeated. For contract calls, the read set may also include information such as the contract's storage slot.

[0086] The transaction write set is the changes made to the world state after the transaction is executed. These changes will be reflected in the transaction write set and eventually submitted to the blockchain. For example, a transfer transaction will change the balance of the initiator and receiver accounts, and calling a smart contract will modify the contract storage. In Ethereum, the main function of the write set is to update the on-chain data. Write operations include: updating the balance of an account (such as a transfer transaction) and updating the storage variables of a smart contract (such as a contract call).

[0087] Ethereum's transaction execution limits the amount of computation and storage modification of each transaction by consuming Gas. Each modification of storage consumes a certain amount of Gas, so write operations are relatively expensive in the blockchain. In the concept of read-write sets, read operations usually consume less Gas, while write operations consume more Gas because they will cause changes in the blockchain state.

[0088] Step 102: Multiple consensus nodes in the blockchain determine the block producer consensus node based on a preset consensus algorithm.

[0089] It should be noted that every preset step of the blockchain, all consensus nodes in the blockchain elect a consensus node as the block producer consensus node according to the consensus algorithm, that is, miners (in PoW) or validators (in PoS) elect the block producer of the next block through a consensus algorithm (such as Ethash, Casper, etc.). For example, every 12 seconds, all consensus nodes select the block producer consensus node according to the consensus algorithm; while the archive node is performing pre-execution transactions during the election, it is possible that the block producer consensus node needs data but the archive node has not yet completed the execution. At this time, the consensus node needs to wait for the archive node to complete the pre-execution transaction before receiving the transaction package data sent by the archive node.

[0090] It is worth mentioning that after the block producer consensus node is determined, the block producer consensus node will generate a target request and send it to the archive node when data is needed. The archive node responds to the target request and sends the transaction package data to the block producer consensus node.

[0091] In this embodiment, according to the consensus algorithm of the blockchain, for example, Ethereum used the POW (proof of work) consensus before the 2.0 upgrade, which requires miners to calculate a random number to determine who is the current block producer of the blockchain. After the block producer pre-executes the transactions during this period (the process is basically the same as the principle of the pre-execution step of the above-mentioned archive node), the transactions are packaged into blocks and broadcast to the entire network. For the POS consensus algorithm, there are no miners in the blockchain network, but the verifiers pledge their assets to the smart contract on Ethereum through Ethereum, which is responsible for checking whether the new blocks propagated on the network are valid, and occasionally they also create and propagate new blocks themselves; when the network attempts to be deceived (for example, proposing multiple blocks when one block should be sent, or sending conflicting authentications), some or all of the Ethereum pledged by the deceiver may be destroyed.

[0092] Step 103: The block producer consensus node uses a preset digital signature algorithm to verify the transaction package data.

[0093] The transaction packaging data includes first transaction packaging data, second transaction packaging data and third transaction packaging data; wherein, the first transaction packaging data consists of a transaction write set, a transaction read set corresponding to the transaction data in the global storage tree of the archive node, transaction data, a digital signature and a Merkel proof; the second transaction packaging data consists of a transaction write set, a transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node, transaction data and a digital signature; the third transaction packaging data consists of transaction data and a digital signature.

[0094] It should be noted that the block producer consensus node verifies the digital signature according to the preset digital signature algorithm. If the verification passes, that is, the digital signature is valid, the transaction is executed. If the verification fails, that is, the digital signature is invalid, the transaction is abandoned. Among them, to verify whether the digital signature of the transaction is valid, it is only necessary to use the signer's public key to verify. The signature is the result of the signer using the private key to encrypt the signed information, which can be verified with the public key. The preset digital signature algorithm used in the present invention is a digital signature algorithm based on the elliptic curve secp256k1 (Elliptic Curve Digital SignatureAlgorithm, ECDSA-secp256k1).

[0095] Step 104: If the verification is successful, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions.

[0096] It should be noted that if the verification digital signature is valid, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions; wherein the preset freezing protocol conditions are to determine whether there is a freezing identifier in the transaction data; if so, the block producer consensus node determines that the data type of the transaction data is a frozen type; if not, the block producer consensus node determines that the data type of the transaction data is not a frozen type.

[0097] Step 105: If yes, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at the future time, and stops the transaction.

[0098] It should be noted that after the block producer consensus node determines that the data type of the transaction data is a frozen type, it needs to execute the frozen transaction In essence, a freeze transaction is a contract-calling transaction in Ethereum. It can be initiated by external users and contracts and executed by consensus nodes. Executing a freeze transaction means that the contract variables involved need to be frozen. The consensus node does not need to save these contract variables. The specific process is to overwrite the cache tree with the current storage tree and clear it. That is, the current storage tree of the block producer consensus node is used as the cache storage tree at the future moment, and the data of the current storage tree of the block producer consensus node is cleared to determine the current storage tree at the future moment.

[0099] In this embodiment, the frozen transaction is essentially a message call (there are two types of transactions in Ethereum: creating a contract and message call), which is used for interaction between external accounts, external accounts and smart contracts. The frozen transaction is essentially a call to the Frozen function of a smart contract. In the eth_sendTransaction JSON RPC method of Ethereum, there is a field called data when sending a message, which contains additional data when sending a message call. If the Frozen method of the contract is to be executed, the data area will contain the identifier of the Frozen method (freeze identifier), thereby judging that the type of the transaction data is a frozen type.

[0100] Step 106: If not, the block producer consensus node uses the transaction packaging data to conduct the transaction and generate the target transaction result.

[0101] Specifically, after the block producer consensus node determines that the data type of the transaction data is not a frozen type, the block producer consensus node first determines whether the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, and the transaction read-write set includes a transaction read set and a transaction write set corresponding to the transaction data (the same as the transaction read set and the transaction write set corresponding to the transaction data on the current storage tree of the archive node or the cache storage tree). If the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node do not have a transaction read-write set corresponding to the transaction data, it indicates that the transaction read-write set corresponding to the transaction data does not exist in the current storage tree and the cache storage tree of the archive node. At this time, the packaged data received by the block producer consensus node is the first transaction packaged data, and the block producer consensus node uses the Merkel proof in the first transaction packaged data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to trade and generate a target transaction result.

[0102] Furthermore, if the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, it indicates that the transaction read set and transaction write set corresponding to the transaction data also exist in the current storage tree and cache storage tree of the archive node. The block producer consensus node uses the status data of the transaction read-write set corresponding to the local transaction data and the transaction data in the transaction packaging data to conduct transactions and generate the target transaction result; the status data of the transaction read-write set includes the status data of the transaction read set and the status data of the transaction write set corresponding to the transaction data.

[0103] For example, see Figure 3 , the consensus node is responsible for participating in the consensus protocol in the blockchain network, but only maintains a part of the active state in the blockchain system, and does not save the complete blockchain state. It can normally verify the transactions in the block and is the most important consensus participant on the chain; the archive node is a node with good storage performance and rich computing resources. They will store the complete blockchain state and historical transaction data, not only participate in the consensus and replay execution transactions on the chain, but also provide proof services when the consensus node needs to verify a state that has not been saved. Specifically, transaction execution is divided into the following steps:

[0104] Step 1: A transaction request containing a digital signature is submitted by an account to the archive node. The transaction request contains transaction data. The digital signature of the transaction with the account .

[0105] Step 2: After receiving the transaction, the archive node will pre-execute the transaction locally and generate a Merkle proof of the transaction data , and get the read-write set of the transaction.

[0106] Step 3: The archive node will execute the results (including transaction data, transaction read-write sets, and the state root of each transaction), Merkle proof Packed into transaction package data Broadcast to the elected block producer consensus nodes.

[0107] Step 4: Receive data The block producer consensus node starts to execute the transaction. During the execution process, the corresponding transaction will be executed based on the data type of the transaction data, and the contract status will be confirmed to be saved locally or in the archive node according to the records in the local status tree. Get the corresponding status to start verification. After verifying that the block transaction is executed correctly, update the local database according to the execution result.

[0108] Step 5: The archive node regularly observes the blocks and transactions in the blockchain network. Once it observes that the transaction has been included in the blockchain, it will also synchronously update its local status in its local database.

[0109] It should be pointed out that the above examples only briefly illustrate the general process of blockchain transaction processing. The specific implementation process of each step can be understood by referring to the relevant content in the aforementioned steps. It will not be elaborated here. It can be understood that the present invention is not limited to this.

[0110] In an embodiment of the present invention, the present invention provides a blockchain transaction processing method. When an archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request to generate transaction packaging data; multiple consensus nodes in the blockchain determine a block producer consensus node based on a preset consensus algorithm; the block producer consensus node uses a preset digital signature algorithm to verify the transaction packaging data; if the verification is passed, the block producer consensus node determines whether the data type of the transaction packaging data is a frozen type based on a preset freezing protocol condition; if so, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction; if not, the block producer consensus node uses the transaction packaging data to trade and generate a target transaction result; based on the above scheme, the data type of the transaction packaging data is determined according to the preset freezing protocol condition, and the corresponding transaction processing is performed according to the corresponding data type, which can reduce the data stored by the consensus node, improve the efficiency of executing transactions, and further reduce storage overhead.

[0111] See also Figure 4 , Figure 4 A flowchart of the steps of a blockchain transaction processing method provided in Embodiment 2 of the present invention.

[0112] The present invention provides a blockchain transaction processing method, comprising:

[0113] Step 401: When the archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction packaging data.

[0114] The transaction request includes transaction data and a digital signature; the transaction packaged data includes first transaction packaged data, second transaction packaged data and third transaction packaged data.

[0115] Please note that Figure 5 The present invention modifies and expands the StorageRoot in the existing contract account model into GlobalRoot, CacheRoot, and CurrentRoot, which correspond to the global storage tree respectively. The root node and cache storage tree The root node of the current storage tree The root node of the global storage tree It is a storage tree that saves all contract variables (i.e., the transaction read set and transaction write set corresponding to the transaction data), such as Figure 3 As shown in the figure, for a contract account, the consensus node only needs to maintain the storage tree corresponding to the CacheRoot and CurrentRoot fields in the contract account, and only retains the value of the root node of the global storage tree; the archive node will save all three storage trees, the purpose is to provide B tx It can be compared with the data of the consensus node immediately when B tx Add the necessary data.

[0116] Furthermore, the archive node performs a pre-execution transaction according to the transaction request and generates the transaction packaging data, which can be achieved by executing the following steps S11 to S18:

[0117] Step S11, the archive node verifies the digital signature based on a preset digital signature algorithm;

[0118] Step S12: If the verification is successful, the archive node determines whether the data type of the transaction data is a frozen type based on the preset freezing protocol conditions;

[0119] It should be noted that the archive node verifies the digital signature based on the preset digital signature algorithm, that is, the archive node verifies whether the signature is valid based on the preset digital signature algorithm. If it is invalid, the request is discarded and the transaction is abandoned. If it is valid, the pre-transaction is continued, that is, based on the preset freezing protocol conditions, it is determined whether the data type of the transaction data is a frozen type.

[0120] Step S13: If the data type of the transaction data is not a frozen type, the archive node determines whether there is a transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node;

[0121] Step S14: If the transaction read set corresponding to the transaction data does not exist in the current storage tree and the cache storage tree of the archive node, the archive node generates a Merkle proof based on the status data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node;

[0122] Step S15: The archive node uses the transaction data and Merkle proof to perform pre-transactions and generate a transaction write set;

[0123] Step S16: The archive node packages the transaction write set, the transaction read set corresponding to the transaction data in the global storage tree of the archive node, the transaction data, the digital signature, and the Merkle proof to generate first transaction package data;

[0124] Step S17: If the current storage tree or cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the state data of the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node to perform a pre-transaction and generate a transaction write set;

[0125] Step S18: The archive node packages the transaction write set, the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature to generate second transaction package data.

[0126] It should be noted that if the data type of the transaction data is not a frozen type, the read and write status data tx.state (i.e. the status data of the transaction read set and the status data of the transaction write set) involved in the transaction is traversed. First, the archive node determines whether the status data of the read set (transaction read set) corresponding to the transaction data is in the current storage tree of the archive node. and cache storage tree If so, there is no need to generate a proof of the state data (i.e., Merkle proof). The archive node uses the transaction data and the state data of the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node to pre-trade, generate a transaction write set, and package the transaction write set, the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature to generate the second transaction package data; if there is only the global storage tree of the archive node In this case, it is necessary to generate a Merkle proof based on the status data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node.

[0127] It is worth mentioning that the archive node simulates the Ethereum virtual machine pre-execution transaction locally, generates the transaction write set (i.e., transaction write set), packages the transaction read-write set (transaction read set, transaction write set), Merkle proof and other data into a broadcast to the block maker consensus node, and waits for the consensus node to propose a new block to put the transaction on the chain. After the transaction is included in the newly generated block (target block), the archive node submits the local state and updates the current storage tree according to the transaction result. and cache storage tree , ensure the current storage tree of the archive node and cache storage tree and the current storage tree of the consensus node and cache storage tree consistency.

[0128] Optionally, if the data type of the transaction data is a frozen type, the archive node packages the transaction data and the digital signature to generate third transaction package data.

[0129] It should be noted that if the transaction type is Frozen tx , the archive node does not need to be pre-executed (it does not involve data modification of the global storage tree), because the purpose of the freeze transaction is to modify the status of the current storage tree and the cache storage tree. It only needs to wait for the transaction to be synchronized with the results of the consensus node after it is uploaded to the chain. The archive node packages the transaction data and digital signature to generate the third transaction package data.

[0130] Step 402: Multiple consensus nodes in the blockchain determine the block producer consensus node based on a preset consensus algorithm.

[0131] It should be noted that every preset step of the blockchain, all consensus nodes in the blockchain elect a consensus node as the block producer consensus node according to the consensus algorithm.

[0132] Step 403: The block producer consensus node uses a preset digital signature algorithm to verify the transaction package data.

[0133] It should be noted that the block producer consensus node verifies the digital signature according to the preset digital signature algorithm. If the verification passes, that is, the digital signature is valid, the transaction is executed. If the verification fails, that is, the digital signature is invalid, the transaction is abandoned.

[0134] Step 404: If the verification is successful, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions.

[0135] Furthermore, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol condition, which can be achieved by executing the following steps S41 to S43:

[0136] Step S41, the block producer consensus node determines whether the transaction data in the transaction package data has a frozen identifier;

[0137] Step S42: If it exists, the block producer consensus node determines that the data type of the transaction data is a frozen type;

[0138] Step S43: If not present, the block producer consensus node determines that the data type of the transaction data is not a frozen type.

[0139] It should be noted that, compared with the strategy of regular cleaning of historical data in traditional blockchain optimization, the dynamic freezing protocol (preset freezing protocol conditions) involved in the present invention is initiated by user customization, so different freezing strategies can be deployed for different contracts, such as the most common use of LFU strategy: the system cleans up data according to access frequency, and preferentially freezes the contract data with the lowest access frequency. This strategy is suitable for scenarios with relatively stable access frequency. Or, according to the storage space of the contract, use the automatic threshold freezing strategy: automatically trigger the cleaning operation according to the usage of the storage space occupied by the contract data, and trigger the freezing operation when the storage space usage exceeds a certain threshold.

[0140] Step 405: If yes, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at the future time, and stops the transaction.

[0141] The future time data storage tree includes the future time cache storage tree and the future time current storage tree.

[0142] Furthermore, the block producer consensus node updates the data storage tree of the block producer consensus node and determines the step of the data storage tree at a future time, which can be achieved by executing the following steps S51 to S52:

[0143] Step S51, the block producer consensus node uses the current storage tree of the block producer consensus node as the cache storage tree at the future moment;

[0144] Step S52: The block producer consensus node clears data on the current storage tree of the block producer consensus node to determine the current storage tree at a future time.

[0145] It should be noted that the block producer consensus node verifies whether the signature is valid based on the preset digital signature algorithm. If it is invalid, the request is discarded and the transaction is abandoned. If it is valid, the transaction is continued. If the block producer determines that the transaction type is frozen, tx, the cache tree is overwritten with the current storage tree and cleared, that is, the current storage tree of the block producer consensus node is used as the cache storage tree at the future moment, and the data of the current storage tree of the block producer consensus node is cleared to determine the current storage tree at the future moment.

[0146] For example, see Figure 6 , Figure 6 The state of a contract account at time t is defined in . At time t, a request to freeze transaction tx1 is received. Therefore, the current storage tree of the block producer consensus node at time t is transferred as the cache storage tree at time t+1 (that is, the cache storage tree at the future time), and the current storage tree at time t+1 is newly built as an empty tree (that is, the data of the current storage tree of the block producer consensus node is cleared, and the cleared current storage tree is used as the current storage tree at the future time). This process completes the freezing process of the contract account. Subsequently, transaction tx2 is received at time t+1, and the current storage tree and the global storage tree are updated according to the relevant states involved in tx2.

[0147] Step 406: If not, the block producer consensus node uses the transaction packaging data to conduct the transaction and generate the target transaction result.

[0148] The data storage tree of the block producer consensus node includes the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node.

[0149] Furthermore, the block producer consensus node uses the transaction packaging data to conduct transactions and generate the target transaction result, which can be achieved by executing the following steps S61 to S64:

[0150] Step S61: The block producer consensus node determines whether the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data;

[0151] Step S62: If the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node do not have the transaction read-write set corresponding to the transaction data, the block producer consensus node uses the Merkle proof in the transaction package data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to perform the transaction and generate the target transaction result;

[0152] Step S63: If the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, the block producer consensus node uses the status data of the transaction read-write set corresponding to the transaction data and the transaction data in the transaction packaging data to perform the transaction and generate the target transaction result.

[0153] It should be noted that if the transaction type is not Frozen tx, get the transaction status state (that is, get the transaction read-write set), because the block producer consensus node does not save the global storage tree , when the retrieved state data (the state data of the transaction read-write set) is not in the current storage tree of the local consensus node of the block producer and cache storage tree When the archive node provides B tx Get data Merkle proof, execute transaction, and update , that is, the block producer consensus node uses the Merkle proof in the transaction package data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to trade, generate the target transaction result, and update the block producer consensus node .

[0154] If the state data of the transaction read-write set exists in the local current storage tree of the block producer consensus node or cache storage tree When the block producer consensus node is connected, it uses the status data of the transaction read-write set corresponding to the local transaction data and the transaction data in the transaction packaging data to conduct transactions and generate the target transaction result.

[0155] Step 407: The block producer consensus node constructs an initial block and merges the target transaction result with the initial block to determine the target block.

[0156] It should be noted that after the block producer consensus node executes the transaction and obtains the target transaction result, it will build an initial block and package the target transaction result generated by the successfully executed transaction into the initial block.

[0157] Step 408: The block producer consensus node broadcasts the target block to multiple nodes of the blockchain.

[0158] Step 409: Multiple nodes of the blockchain verify the target block.

[0159] It should be noted that the consensus node broadcasts this target to the entire network. After receiving the block, other nodes will verify it and add it to the local blockchain after successful verification.

[0160] Step 410: If the verification is successful, multiple nodes in the blockchain add the target block to the local blockchain of each node to determine the new blockchain.

[0161] It should be noted that the block producer consensus node broadcasts the target block to other nodes in the blockchain for verification. If more than 51% of the nodes in the blockchain pass the verification, it means that the target block has passed the verification, and the main chain height is increased by one, that is, other nodes add the target block to their local blockchain after verification, and the block producer consensus node will also add the target block to the local blockchain, thereby obtaining a new blockchain. In addition, since the entire blockchain network is a distributed system, the present invention sets a blockchain that requires more than 51% of the nodes to be recognized to be legal and valid; wherein, the verification process is specifically as follows: after other nodes in the blockchain receive the target block, first verify the block header of the target block (parent block hash verification and timestamp verification), check whether the hash value of the parent block referenced by the block matches the hash value of the last block on the local blockchain, and check whether the timestamp of the block is reasonable. For example, the timestamp should be later than the timestamp of the previous block, and should not exceed the time of the current node by too much.

[0162] Then, based on the consensus mechanism used, for Proof of Work (PoW), the node recalculates the hash of the block and verifies whether it meets the current difficulty target. The calculation process checks the Nonce (random number) and other data in the block to ensure that the hash value meets the difficulty conditions set by the entire network (for example, the first few digits of the hash value are zero). Proof of Stake (PoS): The node verifies whether the stake of the block producer meets the requirements and checks whether the stake is consistent with the rules of the network.

[0163] Each block contains a set of transactions, and the node needs to verify the validity of these transactions one by one, including transaction structure verification, digital signature verification, double payment check, and balance verification. If the block passes all verifications, the node will add the block to the local blockchain and update the relevant status information (such as account balance, contract status, etc.).

[0164] Furthermore, if the verification fails, the target block will not be added to the local blockchain.

[0165] It is worth mentioning that after the block producer consensus node creates a new block (target block), it needs to synchronize with the rest of the network. Two types of nodes need to be considered: archive nodes and newly joined nodes; the synchronization of archive nodes is similar to the behavior of consensus nodes of other non-proposed blocks. They all need to re-execute the transactions in the block. However, since the archive node has pre-executed the transactions in advance, it only needs to verify whether the Merkle tree root of the transactions in the block is consistent with its own results, and then update its local state; fast synchronization of newly joined nodes: When a new node joins the network, it needs to synchronize and check all the blocks that have been created and the transactions contained in them. This process is similar to node synchronization in traditional blockchain systems, but there are some significant differences. First, the new node does not need to load transaction data from the archive node, but from other consensus nodes. Traditional new nodes must verify all blocks loaded from the blockchain network and execute all historical transactions to rebuild the entire state tree, which is a time-consuming process. We adopt fast synchronization to obtain the state tree from the consensus node, and further, only update the latest state tree and block header, so the new node has less data than the consensus node, so as to achieve the purpose of fast synchronization.

[0166] As a comparison of technical effects, we can refer to the existing technology. In Ethereum, each time a node executes a transaction, it will change the state of the blockchain, and thus the state tree needs to be modified. For example, if a new account needs to be created in the transaction, the state tree will add a new state in the leaf node, thereby increasing the storage capacity of the blockchain state tree; if the account data needs to be modified in the transaction, the corresponding leaf node in the state tree will be modified. As blockchain transactions are continuously executed, the number of blockchain states in the state tree continues to increase, and it will be difficult for Ethereum nodes to store the state tree that occupies a large amount of storage space. At present, the amount of data that Ethereum nodes need to store has reached 18TB.

[0167] In order to solve the storage problem of Ethereum nodes, there are currently two existing solutions:

[0168] 1. Sharding technology. Sharding is an effective way to reduce the storage requirements of Ethereum nodes. Modern sharded blockchain systems begin to split state data between different shards. This means that each shard is only responsible for a part of the state data and processes specific transactions related to that shard.

[0169] 2. Stateless blockchain technology. Stateless blockchain is designed to allow nodes to process transactions without the burden of storing large amounts of data. It hands over the state of the blockchain to off-chain nodes, which read and write it.

[0170] Based on the above foundation, the existing solutions to reduce the storage pressure of Ethereum nodes mainly have the following problems: As the number of Ethereum states continues to grow, and Ethereum nodes must store this data, the storage pressure often makes it difficult for nodes to store a huge number of blockchain states; As the number of blockchain states continues to increase, the height of the state tree also continues to increase, and the efficiency of reading and writing states during transaction execution will also decrease, thereby reducing the efficiency of transaction execution. As a result, the threshold for becoming an Ethereum node becomes higher, the blockchain transaction throughput decreases, and the blockchain will tend to be centralized; Sharded blockchains will bring additional communication and consensus overhead, especially when managing cross-shard transactions, involving the consensus of multiple shards, and the security and communication overhead between shards need to be considered, which will make the blockchain system complex and prone to security vulnerabilities; Stateless blockchains essentially transfer storage requirements to other nodes, which will greatly increase network bandwidth. Since stateless blockchains do not save transaction history, it is difficult to roll back transactions if errors or attacks occur, which makes stateless blockchains more vulnerable to attacks and fraud.

[0171] In view of the above problems, the present invention is committed to hierarchical storage and dynamic freezing of the blockchain state stored by the Ethereum node, and only hotspot states are saved in the blockchain node, reducing the storage pressure and network overhead of the node, improving the efficiency of transaction execution, and ultimately improving the transaction throughput; under the premise of not bringing the consensus overhead of additional multiple shards, the problem of storage demand upgrade is effectively solved, and the storage scalability of the blockchain system is improved. Specifically, according to the architecture of hierarchical storage of hotspot accounts, the storage layer and the consensus layer are separated and each performs its own duties; under the preset freezing protocol conditions, the process of the archive node and the consensus node executing the transaction, and the storage tree in the contract account is updated and executed according to the different transaction types; thereby saving the total storage space of the consensus node: since the unpopular data is frozen to the archive node, the amount of data that the consensus node needs to store is reduced. In addition, the existing contract account model is modified, and the node retains the hot state data of the contract for the time locality of the smart contract state data. When executing the transaction, the local database can be read first and the local state data can be updated; at the same time, since the data stored in the consensus node is reduced, its efficiency in executing transactions is improved, and the transaction throughput is finally improved.

[0172] In an embodiment of the present invention, the present invention provides a blockchain transaction processing method. When an archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request to generate transaction packaging data; multiple consensus nodes in the blockchain determine a block producer consensus node based on a preset consensus algorithm; the block producer consensus node uses a preset digital signature algorithm to verify the transaction packaging data; if the verification is passed, the block producer consensus node determines whether the data type of the transaction packaging data is a frozen type based on a preset freezing protocol condition; if so, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction; if not, the block producer consensus node uses the transaction packaging data to trade and generate a target transaction result; based on the above scheme, the data type of the transaction packaging data is determined according to the preset freezing protocol condition, and the corresponding transaction processing is performed according to the corresponding data type, which can reduce the data stored by the consensus node, improve the efficiency of executing transactions, and further reduce storage overhead.

[0173] See also Figure 7 , Figure 7 This is a structural block diagram of a blockchain transaction processing system provided in Example 3 of the present invention.

[0174] The present invention provides a blockchain transaction processing system, comprising:

[0175] The pre-transaction module 701 is used for, when the archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction packaging data;

[0176] Determination module 702, used for multiple consensus nodes in the blockchain to determine the block producer consensus node based on a preset consensus algorithm;

[0177] Verification module 703, used for the block producer consensus node to verify the transaction package data using a preset digital signature algorithm;

[0178] The judgment module 704 is used for judging whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions if the verification is passed;

[0179] Update module 705, for if yes, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction;

[0180] The transaction module 706 is used to, if not, the block producer consensus node uses the transaction packaging data to conduct transactions and generate the target transaction result.

[0181] Furthermore, the transaction request includes transaction data and a digital signature; the transaction packaged data includes first transaction packaged data and second transaction packaged data; the pre-transaction module 701 is specifically used to:

[0182] The archive node verifies the digital signature based on the preset digital signature algorithm;

[0183] If the verification is successful, the archive node determines whether the data type of the transaction data is a frozen type based on the preset freezing protocol conditions;

[0184] If the data type of the transaction data is not a frozen type, the archive node determines whether the current storage tree or cache storage tree of the archive node has a transaction read set corresponding to the transaction data;

[0185] If the transaction read set corresponding to the transaction data does not exist in the current storage tree and cache storage tree of the archive node, the archive node generates a Merkle proof based on the status data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node;

[0186] The archive node uses transaction data and Merkle proofs to perform pre-transactions and generate transaction write sets;

[0187] The archive node packages the transaction write set, the transaction read set corresponding to the transaction data in the global storage tree of the archive node, the transaction data, the digital signature, and the Merkle proof to generate first transaction package data;

[0188] If the current storage tree or cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the state data of the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node to perform pre-transactions and generate a transaction write set;

[0189] The archive node packages the transaction write set, the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature to generate second transaction package data.

[0190] In an optional embodiment, the transaction packaging data further includes third transaction packaging data; and the system further includes:

[0191] The third transaction module is used for, if the data type of the transaction data is a frozen type, the archive node packages the transaction data and the digital signature to generate third transaction packaged data.

[0192] Furthermore, the determination module 704 is specifically configured to:

[0193] The block producer consensus node determines whether the transaction data in the transaction package data has a frozen identifier;

[0194] If it exists, the block producer consensus node determines that the data type of the transaction data is a frozen type;

[0195] If it does not exist, the block producer consensus node determines that the data type of the transaction data is not a frozen type.

[0196] Further, the data storage tree of the block producer consensus node includes the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node; the data storage tree at a future time includes the cache storage tree at a future time and the current storage tree at a future time; the update module 705 is specifically used to:

[0197] The block producer consensus node uses the current storage tree of the block producer consensus node as the cache storage tree for future moments;

[0198] The block producer consensus node clears the data of the current storage tree of the block producer consensus node and determines the current storage tree at the future moment.

[0199] Furthermore, the transaction module 706 is specifically configured to:

[0200] The block producer consensus node determines whether the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data;

[0201] If the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node do not have the transaction read-write set corresponding to the transaction data, the block producer consensus node uses the Merkle proof in the transaction package data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to trade and generate the target transaction result;

[0202] If the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, the block producer consensus node uses the status data of the transaction read-write set corresponding to the transaction data and the transaction data in the transaction packaging data to perform the transaction and generate the target transaction result.

[0203] In an optional embodiment, the system further includes:

[0204] The first module is used by the block producer consensus node to build the initial block and merge the target transaction result with the initial block to determine the target block;

[0205] The second module is used by the block producer consensus node to broadcast the target block to multiple nodes of the blockchain;

[0206] The third module is used for multiple nodes of the blockchain to verify the target block;

[0207] The fourth module is used to add the target block to the local blockchain of each node if the verification is passed, and determine the new blockchain.

[0208] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0209] See also Figure 8 , Figure 8 A flowchart of the steps of a blockchain transaction processing method for an archive node in a blockchain provided in Embodiment 4 of the present invention.

[0210] A blockchain transaction processing method provided by the present invention is applied to an archive node in a blockchain, comprising:

[0211] Step 801: When a transaction request is received, a pre-execution transaction is performed according to the transaction request to generate transaction packaging data.

[0212] Step 802: In response to the received target request, the transaction package data is sent to the block producer consensus node in the blockchain.

[0213] It should be noted that the target request is that when the block producer consensus node needs transaction package data, it will generate and send a request to the archive node, and the archive node will respond to the request and send the transaction package data to the block producer consensus node.

[0214] In an embodiment of the present invention, when an archive node receives a transaction request, it pre-executes the transaction according to the transaction request and generates transaction package data; in response to the received target request, the transaction package data is sent to the block producer consensus node in the blockchain, and the block producer consensus node determines the data type of the transaction package data based on the preset freezing protocol conditions, and executes the corresponding transaction processing process according to the corresponding data type, which can reduce the data stored in the consensus node, improve the efficiency of executing transactions, and further improve the transaction throughput.

[0215] See also Fig. 9 , Fig. 9 A flowchart of the steps of a blockchain transaction processing method applied to a block producer consensus node in a blockchain provided in Embodiment 5 of the present invention.

[0216] A blockchain transaction processing method provided by the present invention is applied to a block producer consensus node in a blockchain, comprising:

[0217] Step 901: Send a target request to the archive node in the blockchain, and obtain the transaction package data sent by the archive node in the blockchain.

[0218] Step 902: Use a preset digital signature algorithm to verify the transaction package data.

[0219] Step 903: If the verification is successful, based on the preset freezing protocol conditions, determine whether the data type of the transaction packaged data is a frozen type.

[0220] Step 904: If yes, update the data storage tree of the block producer consensus node, determine the data storage tree at the future time, and stop the transaction.

[0221] Step 905: If not, use the transaction packaging data to conduct the transaction and generate the target transaction result.

[0222] In an embodiment of the present invention, the data type of the acquired transaction package data is determined based on the preset freezing protocol conditions, and the corresponding transaction processing is performed according to the corresponding data type, and the archive node is combined to perform a pre-transaction process on the transaction request; it is possible to reduce the data stored in the consensus node, improve the efficiency of executing transactions, and further improve the transaction throughput.

[0223] In the several embodiments provided in the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0224] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0225] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain transaction processing method, characterized in that: include: When an archive node in the blockchain receives a transaction request, the archive node performs a pre-execution transaction according to the transaction request and generates transaction packaging data; The multiple consensus nodes in the blockchain determine the block producer consensus node based on a preset consensus algorithm; The block producer consensus node verifies the transaction package data using a preset digital signature algorithm; If the verification is successful, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol conditions; If so, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at the future time, and stops the transaction; If not, the block producer consensus node uses the transaction packaging data to conduct transactions and generate the target transaction result.

2. The blockchain transaction processing method according to claim 1, characterized in that: The transaction request includes transaction data and a digital signature; the transaction package data includes first transaction package data and second transaction package data; the archive node performs a pre-execution transaction according to the transaction request to generate the transaction package data, including: The archive node verifies the digital signature based on the preset digital signature algorithm; If the verification is successful, the archive node determines whether the data type of the transaction data is a frozen type based on the preset freezing protocol conditions; If the data type of the transaction data is not a frozen type, the archive node determines whether a transaction read set corresponding to the transaction data exists in the current storage tree or cache storage tree of the archive node; If neither the current storage tree nor the cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node generates a Merkle proof according to the state data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node; The archive node uses the transaction data and the Merkle proof to perform a pre-transaction and generate a transaction write set; The archive node packages the transaction write set, the transaction read set corresponding to the transaction data in the global storage tree of the archive node, the transaction data, the digital signature and the Merkle proof to generate first transaction package data; If the current storage tree or cache storage tree of the archive node has a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the state data of the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node to perform a pre-transaction and generate a transaction write set; The archive node packages the transaction write set, the transaction read set corresponding to the transaction data of the current storage tree or cache storage tree of the archive node, the transaction data and the digital signature to generate second transaction package data.

3. The blockchain transaction processing method according to claim 2, characterized in that: The transaction packaging data further includes third transaction packaging data; and the method further includes: If the data type of the transaction data is a frozen type, the archive node packages the transaction data and the digital signature to generate third transaction packaged data.

4. The blockchain transaction processing method according to claim 1, characterized in that: The block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the preset freezing protocol condition, including: The block producer consensus node determines whether the transaction data in the transaction packaging data has a frozen identifier; If so, the block producer consensus node determines that the data type of the transaction data is a frozen type; If not, the block producer consensus node determines that the data type of the transaction data is not a frozen type.

5. The blockchain transaction processing method according to claim 1, characterized in that: The data storage tree of the block producer consensus node includes the current storage tree of the block producer consensus node and the cache storage tree of the block producer consensus node; the future time data storage tree includes the cache storage tree at the future time and the current storage tree at the future time; The block producer consensus node updates the data storage tree of the block producer consensus node to determine the data storage tree at a future time, including: The block producer consensus node uses the current storage tree of the block producer consensus node as the cache storage tree at the future moment; The block producer consensus node clears data on the current storage tree of the block producer consensus node to determine the current storage tree at a future time.

6. The blockchain transaction processing method according to claim 2, characterized in that: The block producer consensus node uses the transaction packaging data to conduct transactions and generate target transaction results, including: The block producer consensus node determines whether the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data; If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node has the transaction read-write set corresponding to the transaction data, the block producer consensus node uses the Merkel proof in the transaction package data, the status data of the transaction read set, the status data of the transaction write set, and the transaction data to perform the transaction and generate the target transaction result; If the current storage tree of the block producer consensus node or the cache storage tree of the block producer consensus node has a transaction read-write set corresponding to the transaction data, the block producer consensus node uses the status data of the transaction read-write set corresponding to the transaction data and the transaction data in the transaction packaging data to perform the transaction and generate the target transaction result.

7. The blockchain transaction processing method according to claim 1, characterized in that: After the block producer consensus node uses the transaction packaging data to conduct a transaction and generates a target transaction result, it includes: The block producer consensus node constructs an initial block, and merges the target transaction result with the initial block to determine the target block; The block producer consensus node broadcasts the target block to multiple nodes of the blockchain; Multiple nodes of the blockchain verify the target block; If the verification is successful, multiple nodes in the blockchain add the target block to the local blockchain of each node to determine a new blockchain.

8. A blockchain transaction processing system, characterized in that: include: A pre-transaction module, which is used for, when an archive node in the blockchain receives a transaction request, the archive node performs a pre-transaction according to the transaction request and generates transaction packaging data; A determination module, used for multiple consensus nodes in the blockchain to determine a block producer consensus node based on a preset consensus algorithm; A verification module, used for the block producer consensus node to verify the transaction packaging data using a preset digital signature algorithm; A judgment module, used for judging whether the data type of the transaction package data is a frozen type based on a preset freezing protocol condition if the verification is passed; An update module, used for, if yes, the block producer consensus node updates the data storage tree of the block producer consensus node, determines the data storage tree at a future time, and stops the transaction; The transaction module is used for, if not, the block producer consensus node uses the transaction packaging data to conduct transactions and generate a target transaction result.

9. A blockchain transaction processing method, characterized in that: Archive nodes used in blockchain include: When receiving a transaction request, performing a pre-execution transaction according to the transaction request and generating transaction packaging data; In response to the received target request, the transaction packaging data is sent to the block producer consensus node in the blockchain.

10. A blockchain transaction processing method, characterized in that: The block producer consensus nodes used in the blockchain include: Sending a target request to an archive node in the blockchain, and obtaining transaction package data sent by the archive node in the blockchain; Using a preset digital signature algorithm to verify the transaction package data; If the verification is successful, based on the preset freezing protocol conditions, determine whether the data type of the transaction packaged data is a frozen type; If so, update the data storage tree of the consensus node of the block producer, determine the data storage tree at the future time, and stop the transaction; If not, the transaction is performed using the transaction packaging data to generate a target transaction result.

Images