A blockchain transaction processing method and system

Abstract

This invention discloses a blockchain transaction processing method and system, comprising: when an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction according to the transaction request, generating transaction package data; multiple consensus nodes in the blockchain determine the block producer consensus node based on a pre-set consensus algorithm; the block producer consensus node verifies the transaction package data using a pre-set 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 pre-set freeze protocol conditions; if so, the block producer consensus node updates its data storage tree to determine the data storage tree at a future time and stops the transaction; if not, the block producer consensus node performs the transaction using the transaction package data to generate the target transaction result; this invention solves the technical problem that existing schemes for executing transactions in the blockchain lead to increasingly lower transaction execution efficiency and increasingly higher storage overhead.

Description

Technical Field

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

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

[0003] Blockchain typically combines data blocks sequentially in chronological order to form a chain-like data structure, while using cryptography to ensure the immutability and forgery resistance of the distributed ledger. Due to its decentralized, immutable, and autonomous characteristics, blockchain is receiving increasing attention and application.

[0004] In existing blockchain transaction execution schemes, each transaction executed by a node changes the blockchain state, requiring modifications to the state tree. For example, if a new account needs to be created in a transaction, a new state will be added to the leaf node of the state tree, 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 increases, reducing the efficiency of reading and writing states during transaction execution, resulting in increasingly lower transaction execution efficiency and higher storage overhead. Summary of the Invention

[0005] This invention provides a blockchain transaction processing method and system to solve the technical problems of increasingly lower transaction execution efficiency and increasing storage overhead caused by existing schemes for executing transactions in the blockchain.

[0006] The first aspect of this invention provides a blockchain transaction processing method, comprising:

[0007] When an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction based on the transaction request and generates transaction package data;

[0008] The blockchain has multiple consensus nodes that determine the block producer consensus node based on a pre-set consensus algorithm.

[0009] The block producer consensus node uses a pre-set digital signature algorithm to verify the transaction package data;

[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 freeze protocol conditions.

[0011] If so, the block producer consensus node updates its data storage tree to determine the data storage tree at future times and stops transactions;

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

[0013] Optionally, 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 step of the archive node performing pre-execution transactions and generating transaction package data according to the transaction request includes:

[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 freeze protocol conditions;

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

[0017] If neither the current storage tree nor the cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node generates a Merkel proof based on 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 Merkel proof to perform pre-transactions 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 Merkel proof to generate the first transaction package data;

[0020] If the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the status data of the transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node to perform 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 in 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.

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

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

[0024] Optionally, the step of the block producer consensus node determining whether the data type of the transaction package data is of the frozen type based on preset freeze protocol conditions includes:

[0025] The block producer consensus node determines whether there is a freeze identifier in the transaction data of the transaction package data;

[0026] If present, the block producer consensus node determines that the data type of the transaction data is frozen.

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

[0028] Optionally, 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 for future moments includes the cache storage tree for future moments and the current storage tree for future moments; the step of the block producer consensus node updating its data storage tree to determine the data storage tree for future moments includes:

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

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

[0031] Optionally, the step of the block producer consensus node using the transaction package data to generate the target transaction result includes:

[0032] The block producer consensus node determines whether the transaction read / write set corresponding to the transaction data exists in the current storage tree or the cache storage tree of the block producer consensus node.

[0033] If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the Merkel proof, the state data of the transaction read set, the state data of the transaction write set, and the transaction data in the transaction package data to perform the transaction and generate the target transaction result.

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

[0035] Optionally, after the step of the block producer consensus node using the transaction package data to generate the target transaction result, the following is 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 will add the target block to their local blockchains to determine a new blockchain.

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

[0041] The pre-transaction module is used to pre-execute transactions and generate transaction package data when an archive node in the blockchain receives a transaction request.

[0042] The determination module is used to determine the block producer consensus node based on a preset consensus algorithm among multiple consensus nodes in the blockchain.

[0043] The verification module is used by the block producer consensus node to verify the transaction package data using a pre-set digital signature algorithm;

[0044] The judgment module is used to determine, if the verification passes, whether the data type of the transaction package data is a frozen type based on the preset freeze protocol conditions;

[0045] The update module is used to update the data storage tree of the block producer consensus node if the condition is met, determine the data storage tree at a future time, and stop transactions.

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

[0047] A third aspect of this invention provides a blockchain transaction processing method, applied to archive nodes in a blockchain, comprising:

[0048] When a transaction request is received, a pre-execution transaction is performed according to the transaction request, and transaction package data is generated;

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

[0050] The fourth aspect of this invention provides a blockchain transaction processing method, applied to block producer consensus nodes in a blockchain, comprising:

[0051] 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;

[0052] The transaction package data is verified using a pre-set digital signature algorithm;

[0053] If the verification is successful, based on the preset freeze protocol conditions, it is determined whether the data type of the transaction package data is a freeze type;

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

[0055] If not, the transaction package data is used to perform the transaction and generate the target transaction result.

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

[0057] The above-described technical solution of the present invention provides a blockchain transaction processing method. When an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction according to the transaction request, generating transaction package data. Multiple consensus nodes in the blockchain determine the block producer consensus node based on a pre-set consensus algorithm. The block producer consensus node verifies the transaction package data using a pre-set 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 pre-set freeze protocol conditions. If so, the block producer consensus node updates its data storage tree to determine the data storage tree at future times and stops the transaction. If not, the block producer consensus node performs the transaction using the transaction package data, generating the target transaction result. Based on the above solution, by determining the data type of the transaction package data through pre-set freeze protocol conditions and performing corresponding transaction processing according to the corresponding data type, the amount of data stored by the consensus nodes can be reduced, the efficiency of transaction execution can be improved, and storage overhead can be further reduced. Attached Figure Description

[0058] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

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

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

[0061] Figure 3 This is a schematic diagram of the protocol architecture and steps provided in Embodiment 1 of the present invention;

[0062] Figure 4 This is a flowchart illustrating the steps of a blockchain transaction processing method according to Embodiment 2 of the present invention.

[0063] Figure 5 This is a schematic diagram of the structure of the novel contract account model provided in Embodiment 2 of the present invention;

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

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

[0066] Figure 8 This is a flowchart of the steps of a blockchain transaction processing method applied to archive nodes in a blockchain, as provided in Embodiment 4 of the present invention.

[0067] Figure 9 This is a flowchart illustrating the steps of a blockchain transaction processing method applied to a block producer consensus node in a blockchain, as provided in Embodiment 5 of the present invention. Detailed Implementation

[0068] This invention provides a blockchain transaction processing method and system to address the technical problems of increasingly lower transaction execution efficiency and higher storage overhead caused by existing blockchain transaction execution schemes.

[0069] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0070] Terminology Explanation:

[0071] Blockchain: A shared database containing data or information that is "unforgeable", "fully traceable", "transparent", and "collectively maintained".

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

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

[0074] A smart contract (SC) is a program deployed on a blockchain that automates the processing of traditional contracts through computer instructions. It is a piece of code that is triggered and executed when two parties transact on the blockchain. It consists of a code portion and a state portion, with the state portion containing the variables that need to be stored within the code.

[0075] Ethereum: A mainstream blockchain application.

[0076] State Tree: Ethereum typically 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: Stores variables (i.e., state parts) in smart contracts that need to be stored long-term. Each smart contract account will maintain a storage tree.

[0078] Please see Figure 1 , Figure 1 This is a flowchart illustrating the steps of a blockchain transaction processing method provided in Embodiment 1 of the present invention.

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

[0080] Step 101: When an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction based on the transaction request and generates transaction package data.

[0081] It should be noted that a transaction request containing a digital signature is submitted to the archive node by an Ethereum account, and this transaction request contains transaction data. With the account's digital signature on the transaction Upon receiving the request, the archive node performs a pre-execution transaction using the transaction request, generating transaction package data. The transaction write set in the transaction package data is stored in the archive node's current storage tree and cache storage tree. When the archive node receives a target request from the block producer consensus node, it sends the transaction package data to the block producer consensus node. The pre-execution transaction simulates transaction execution, generating a series of state changes. Transaction data is maintained by the transaction tree, and state data is maintained by the state tree. The transaction tree root and state tree root are separate fields in the block header, both being Merkle trees. However, since these are pre-execution results, the archive node is not responsible for consensus functionality. These results only provide data to the consensus node when needed; the block production function is still performed by the consensus node.

[0082] Further, please refer to 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 executed (Nonce) and the balance (Balance) of the account. The contract account contains the total number of transactions executed (Nonce), the balance (Balance), the storage root (StorageRoot), and the code hash (CodeHash). The storage root is the root node of the storage tree, which is used to store variables in the smart contract that need to be stored long-term (the storage tree is part of the state tree). This 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 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 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 current storage tree and cache storage tree of the archive node contain the status data of the transaction read set and the transaction write set corresponding to the transaction data, then the current storage tree and cache storage tree of the consensus node will also contain the status data of the transaction read set and the transaction write set corresponding to the transaction data.

[0084] Furthermore, regarding the state data of the read-write set (i.e., the state data of the transaction read set and the state of the transaction write set), the transaction read set refers to the account state 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 stored data (such as balance, variable values, etc.) of other accounts to make corresponding logical judgments.

[0085] Each Ethereum transaction involves reading the initiator's account balance and a random number to ensure the initiator has sufficient funds to cover transaction fees and that the transaction is not duplicated. For contract calls, the read set may also include information such as the contract's storage slots.

[0086] A transaction write set represents the changes made to the world state after a transaction is executed. These changes are reflected in the transaction write set and are ultimately committed on the blockchain. For example, a transfer transaction changes the balances of the initiator's and recipient's accounts, and a smart contract call modifies the contract's storage. In Ethereum, the primary function of the write set is to update on-chain data. Write operations include updating account balances (e.g., transfer transactions) and updating smart contract storage variables (e.g., contract calls).

[0087] Ethereum transaction execution limits the computational cost and storage modification of each transaction by consuming Gas. Each modification to storage consumes a certain amount of Gas, making write operations relatively expensive in the blockchain. In the concept of a read-write set, read operations typically consume less Gas, while write operations consume more Gas because they change the state of the blockchain.

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

[0089] It should be noted that every preset step, 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 elect the block producer consensus node according to the consensus algorithm. At the same time as the election, the archive node performs pre-execution transactions. There may be a situation where the block producer consensus node needs the data, but the archive node has not yet finished executing. In this case, 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, when the block producer consensus node needs data, it will generate a target request and send it to the archive node. 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, such as Ethereum's Proof-of-Work (PoW) consensus before the 2.0 upgrade, miners need to calculate a random number to determine who the current block producer of the blockchain is. This block producer pre-executes the transactions within this period (the process is basically the same as the pre-execution steps of the archive node mentioned above), and then packages the transactions into a block and broadcasts it to the entire network. For the Proof-of-Stake (PoS) consensus algorithm, there are no miners in the blockchain network. Instead, validators stake assets in Ethereum through smart contracts and are responsible for checking whether new blocks propagating on the network are valid. Occasionally, they also create and propagate new blocks themselves. When the network attempts to be cheated (for example, proposing multiple blocks when a block should be sent, or sending conflicting authentications), some or all of the Ether staked by the cheater may be destroyed.

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

[0093] The transaction package data includes first transaction package data, second transaction package data, and third transaction package data; wherein, the first transaction package data consists of 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 Merkel proof; the second transaction package data consists of the transaction write set, the transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature; the third transaction package data consists of the transaction data and the digital signature.

[0094] It should be noted that the block producer consensus node verifies the digital signature according to the pre-set digital signature algorithm. If the verification passes, the digital signature is valid, and the transaction is executed. If the verification fails, the digital signature is invalid, and the transaction is abandoned. Verifying the validity of the digital signature of a transaction only requires the signer's public key. The signature is the result of the signer encrypting the signed information using their private key, and can be verified using the public key. The pre-set digital signature algorithm used in this invention is the Elliptic Curve Digital Signature Algorithm (ECDSA-secp256k1).

[0095] Step 104: If the verification passes, the block producer consensus node determines whether the data type of the transaction package data is frozen based on the pre-set freeze protocol conditions.

[0096] It should be noted that if the digital signature is verified to be valid, the block producer consensus node determines whether the data type of the transaction package data is a frozen type based on the pre-set freeze protocol conditions. The pre-set freeze protocol conditions are to determine whether the transaction data has a freeze identifier. If it exists, the block producer consensus node determines that the data type of the transaction data is a frozen type; if it does not exist, 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 future times, and stops transactions.

[0098] It should be noted that after the block producer consensus node determines that the data type of the transaction data is frozen, it needs to execute the freeze transaction. In Ethereum, a freeze transaction is essentially a transaction that calls a contract type. 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. Consensus nodes do 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 for the future moment. The data of the current storage tree of the block producer consensus node is cleared to determine the current storage tree for the future moment.

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

[0100] Step 106: If not, the block producer consensus node uses the transaction package data to process 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 frozen, the block producer consensus node first checks whether there is a transaction read / write set corresponding to the transaction data in its current storage tree or cache storage tree. This transaction read / write set includes the transaction read set and transaction write set corresponding to the transaction data (which are the same as the transaction read set and transaction write set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node). If there is no transaction read / write set corresponding to the transaction data in either the current storage tree or the cache storage tree of the block producer consensus node, it indicates that there is also no transaction read / write set corresponding to the transaction data in the current storage tree or 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. The block producer consensus node uses the Merkle proof, the state data of the transaction read set, the state data of the transaction write set, and the transaction data in the first transaction packaged data to perform the transaction and generate the target transaction result.

[0102] Furthermore, if the current storage tree or cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, it indicates that the current storage tree and cache storage tree of the archive node also contain transaction read and transaction write sets corresponding to the transaction data. The block producer consensus node uses the state data of the transaction read / write set corresponding to the local transaction data and the transaction data in the transaction package data to perform the transaction and generate the target transaction result. The state data of the transaction read / write set includes the state data of the transaction read set and the state data of the transaction write set corresponding to the transaction data.

[0103] For example, please refer to Figure 3 Consensus nodes are responsible for participating in the consensus protocol within the blockchain network, but they only maintain a portion of the active state of the blockchain system, not the complete blockchain state. They can verify transactions in blocks and are the primary consensus participants on the chain. Archive nodes, on the other hand, are nodes with good storage performance and abundant computing resources. They store the complete blockchain state and historical transaction data, participating not only in on-chain consensus and replaying transaction execution, but also providing proof services when consensus nodes need to verify a state that has not been saved. Specifically, transaction execution involves the following steps:

[0104] Step 1: A transaction request containing a digital signature is submitted to the archive node by an account. The transaction request includes transaction data. With the account's digital signature on the transaction .

[0105] Step 2: Upon receiving the transaction, the archive node will pre-execute the transaction locally and generate a Merkel proof of the transaction data. And to obtain 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) and Merkel proof. Packaged into transaction data The broadcast is sent to the consensus nodes of the elected block producers.

[0107] Step 4: Receive data The block-producing consensus node begins executing transactions. During execution, it executes corresponding transactions based on the data type of the transaction data and confirms whether the contract state is stored locally or in the archive node based on the records on the local state tree. The system retrieves the corresponding status and begins verification. After verifying that the block transaction was executed correctly, it updates the local database based on the execution result.

[0108] Step 5: Archive nodes periodically observe blocks and transactions in the blockchain network. Once a transaction is observed to be included in the blockchain, it will also synchronously update its local state in its local database.

[0109] It should be noted that the above example is only a brief description of 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 above steps. It will not be elaborated here. It is understood that the present invention does not limit this.

[0110] In this embodiment of the invention, a blockchain transaction processing method is provided. When an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction according to the transaction request, generating 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 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 preset freeze protocol conditions. If so, the block producer consensus node updates its data storage tree to determine the data storage tree at future times and stops the transaction. If not, the block producer consensus node performs the transaction using the transaction package data, generating the target transaction result. Based on the above scheme, determining the data type of the transaction package data according to the preset freeze protocol conditions and performing corresponding transaction processing according to the corresponding data type can reduce the data stored by the consensus nodes, improve the efficiency of transaction execution, and further reduce storage overhead.

[0111] Please see Figure 4 , Figure 4 This is a flowchart illustrating the steps of a blockchain transaction processing method provided in Embodiment 2 of the present invention.

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

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

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

[0115] It should be noted that you should refer to [link / reference]. Figure 5 This 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. Root node, cache storage tree The root node and the current storage tree The root node. Global storage tree. To store the storage tree of all contract variables (i.e., the transaction read set and transaction write set corresponding to the transaction data), such as Figure 3 As shown, 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, on the other hand, will save all three types of storage trees, the purpose of which is to provide B tx It can immediately compare with the data of the consensus nodes, only in B. tx Add the necessary data.

[0116] Furthermore, the step of the archive node pre-executing the transaction based on the transaction request and generating the transaction package data can be achieved by executing the following steps S11 to S18:

[0117] Step S11: The archive node verifies the digital signature based on a pre-set digital signature algorithm;

[0118] Step S12: If the verification passes, the archive node determines whether the data type of the transaction data is frozen based on the preset freeze protocol conditions.

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

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

[0121] Step S14: If neither the current storage tree nor the cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node generates a Merkel proof based on the state 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 performs pre-transactions using transaction data and Merkel proofs to 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 Merkel proof to generate the 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 status 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-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 in 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.

[0126] It should be noted that if the data type of the transaction data is not frozen, when traversing the read and write state data tx.state involved in the transaction (i.e., the state data of the transaction read set and the state data of the transaction write set), the archive node first determines whether the state 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 the above is true, then no proof of the state data (i.e., Merkel proof) is needed. 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-transaction, 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 only the global storage tree of the archive node exists... Then, Merkel proofs need to be generated based on the state data of the transaction read set corresponding to the transaction data in the global storage tree of the archive node.

[0127] It's worth noting that the archive node locally simulates the Ethereum Virtual Machine to pre-execute transactions, generating a write set of the transactions (i.e., the transaction write set). It then packages the read and write sets (transaction read set, transaction write set), Merkel proofs, and other data into a package and broadcasts it to the block-maker consensus node, waiting for the consensus node to propose a new block to include the transaction on the chain. Once the transaction is included in the newly generated block (the target block), the archive node commits its local state and updates the current storage tree based on the transaction results. and cache storage tree Ensure the current storage tree of the archive node and cache storage tree and the current storage tree of consensus nodes and cache storage tree Consistency.

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

[0129] It should be noted that if the transaction type is frozen... tx The archive node does not need to pre-execute (and will not involve data modification of the global storage tree), because the purpose of freezing transactions is to modify the state of the current storage tree and the cache storage tree. It only needs to wait for the transaction to be uploaded to the chain and synchronize with the result of the consensus node. 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 pre-set consensus algorithm.

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

[0132] Step 403: The block producer consensus node uses a pre-set 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 pre-set digital signature algorithm. If the verification passes, the digital signature is valid and the transaction is executed. If the verification fails, the digital signature is invalid and the transaction is abandoned.

[0134] Step 404: If the verification passes, the block producer consensus node determines whether the data type of the transaction package data is frozen based on the pre-set freeze protocol conditions.

[0135] Furthermore, the step of determining whether the data type of the transaction package data is frozen based on the pre-set freeze protocol conditions can be achieved by executing the following steps S41 to S43:

[0136] Step S41: The block producer consensus node determines whether there is a freeze identifier in the transaction data in the transaction package data;

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

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

[0139] It should be noted that, compared to the strategy of periodically cleaning up historical data in traditional blockchain optimization, the dynamic freeze protocol (pre-defined freeze protocol conditions) involved in this invention is user-defined. Therefore, different freeze strategies can be deployed for different contracts. For example, the most common strategy is the LFU strategy: the system cleans up data based on access frequency, prioritizing the freezing of contract data with the lowest access frequency. This strategy is suitable for scenarios with relatively stable access frequencies. Alternatively, an automatic threshold freeze strategy can be used based on the contract's storage space usage: the cleanup operation is automatically triggered based on the storage space usage of the contract data, and a freeze operation is triggered 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 future times, and stops transactions.

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

[0142] Furthermore, the step of updating the data storage tree of the block producer consensus node to determine the data storage tree at future moments 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 for future moments;

[0144] Step S52: The block producer consensus node clears the data in the current storage tree of the block producer consensus node and determines the current storage tree at a future time.

[0145] It should be noted that the block producer consensus node verifies the validity of the signature based on a pre-built digital signature algorithm. If the signature is invalid, the request is discarded and the transaction is abandoned. If the signature is valid, the transaction continues to be executed. If the block producer determines that the transaction type is frozen, the block producer will proceed with the transaction. txIf the current storage tree is used to overwrite the cache tree and clear it, then the current storage tree of the block producer consensus node will be used as the cache storage tree for the future time. The data of the current storage tree of the block producer consensus node will be cleared to determine the current storage tree for the future time.

[0146] For example, please refer to Figure 6 , Figure 6 The code defines the state of a contract account at time t. 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 to the cache storage tree at time t+1 (i.e., the cache storage tree for future times). At time t+1, a new empty tree is created (i.e., 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 for future times). This process completes the freezing process of the contract account. Subsequently, at time t+1, transaction tx2 is received. 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 package data to process 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 step of the block-producing consensus node using transaction package data to generate the target transaction result 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 or the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data.

[0151] Step S62: If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the Merkle proof in the transaction package data, the state data of the transaction read set, the state 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 or the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the state data of the transaction read / write set corresponding to the transaction data and the transaction data in the transaction package data to perform the transaction and generate the target transaction result.

[0153] It should be noted that if the transaction type is not a frozen type (Frozen), txTo obtain the transaction state (i.e., the transaction read / write set), since the block producer consensus node does not save the global storage tree... When the retrieved state data (state data of the transaction read / write set) is not in the local current storage tree of the block producer consensus node... and cache storage tree When up, from the B provided by the archive node tx Obtain data Merkel proof, execute transactions, and update. In other words, the block-producing consensus node uses the Merkel proof from the transaction package data, the state data of the transaction read set, the state data of the transaction write set, and the transaction data to perform transactions, generate the target transaction result, and update the block-producing 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 in operation, it uses the state data of the transaction read / write set corresponding to the local transaction data and the transaction data in the transaction package data to perform the transaction and generate the target transaction result.

[0155] Step 407: The block producer consensus node constructs the 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 completes the execution of the transaction and obtains the target transaction result, it will construct an initial block and package the target transaction result generated corresponding to the successfully executed transaction into the initial block.

[0157] Step 408: The block producer consensus node broadcasts the target block to multiple nodes in 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. Other nodes will verify the block after receiving it, and add it to their local blockchain if the verification is successful.

[0160] Step 410: If the verification is successful, multiple nodes in the blockchain will add the target block to their local blockchains 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, the target block is considered valid, and the main chain height is incremented by one. This means that after other nodes verify the target block, they add it to their local blockchain, and the block producer consensus node also adds the target block to its local blockchain, resulting in a new blockchain. Furthermore, since the entire blockchain network is a distributed system, this invention requires that a blockchain recognized by more than 51% of the nodes be considered legitimate and valid. Specifically, the verification process involves other nodes in the blockchain receiving the target block and first verifying the block header (parent block hash verification and timestamp verification). They check whether the hash value of the parent block referenced by the block matches the hash value of the last block on their local blockchain and whether the block's timestamp is reasonable. For example, the timestamp should be later than the timestamp of the previous block and should not exceed the current node's timestamp by too much.

[0162] Then, based on the consensus mechanism used, for Proof-of-Work (PoW), nodes recalculate the block's hash value and verify whether it meets the current difficulty target. The calculation process checks the nonce and other data in the block to ensure that the hash value meets the network-wide difficulty requirements (e.g., the first few bits of the hash value are zero). For Proof-of-Stake (PoS), nodes verify whether the block producer's stake meets the requirements and check whether that stake is consistent with the network's rules.

[0163] Each block contains a set of transactions, which nodes must verify one by one: their validity, transaction structure, digital signature, double-spending checks, and balance verification. If a block passes all verifications, the node adds it to its local blockchain and updates relevant state information (such as account balance and contract status).

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

[0165] It's worth noting that after the block-producing consensus node creates a new block (the 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. Archive node synchronization behaves similarly to other consensus nodes that don't propose blocks; they need to re-execute the transactions in the block. However, because archive nodes pre-execute transactions, they only need to verify that the Merkle tree root of the transactions in the block matches their own result, and then update their local state. Newly joined nodes synchronize quickly: when a new node joins the network, it needs to synchronize and check all created blocks and the transactions they contain. This process is similar to node synchronization in traditional blockchain systems, but with some significant differences. First, new nodes don't need to load transaction data from archive nodes; instead, they obtain it from other consensus nodes. Traditionally, new nodes must verify all blocks loaded from the blockchain network and execute all historical transactions to reconstruct the entire state tree, a time-consuming process. We adopt a fast synchronization approach, obtaining the state tree from consensus nodes and further, only updating the latest state tree and block headers. Therefore, new nodes store less data than consensus nodes, achieving fast synchronization.

[0166] For comparison of technical effects, we can refer to existing technologies. In Ethereum, each transaction executed by a node changes the blockchain state, requiring modifications to the state tree. For example, if a transaction creates a new account, a new state is added to the leaf node of the state tree, increasing the storage capacity of the blockchain state tree; if a transaction modifies account data, the corresponding leaf node in the state tree will be modified. As blockchain transactions continue to be executed, the number of blockchain states in the state tree also increases, making it difficult for Ethereum nodes to store the state tree, which occupies a large amount of storage space. Currently, the amount of data that Ethereum nodes need to store has reached 18TB.

[0167] To address the storage issue 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 by dividing state data among different shards. This means that each shard is only responsible for a portion of the state data and processes specific transactions associated with that shard.

[0169] 2. Stateless Blockchain Technology. Stateless blockchains aim to allow nodes to process transactions without the burden of storing large amounts of data. It delegates the blockchain's state to off-chain nodes, which then read and write the data.

[0170] Based on the above, existing solutions for reducing Ethereum node storage pressure mainly suffer from the following problems: The increasing number of Ethereum states, which nodes must store, often leads to storage pressure that makes it difficult for nodes to handle the massive amount of blockchain states. Furthermore, the increasing number of blockchain states and the rising height of the state tree reduce the efficiency of reading and writing states during transaction execution, thus lowering transaction execution efficiency. This raises the barrier to entry for becoming an Ethereum node, decreases blockchain transaction throughput, and tends towards centralization. Sharded blockchains introduce additional communication and consensus overhead, especially when managing cross-shard transactions, which involves consensus across multiple shards. Considering the security and communication overhead between shards makes the blockchain system complex and prone to security vulnerabilities. Stateless blockchains essentially shift storage requirements to other nodes, significantly increasing network bandwidth. Since stateless blockchains do not retain transaction history, it is difficult to roll back transactions in case of errors or attacks, making them more vulnerable to attacks and fraud.

[0171] To address the aforementioned issues, this invention aims to implement layered storage and dynamic freezing of blockchain states stored in Ethereum nodes. Only frequently accessed states are preserved in the blockchain nodes, reducing storage pressure and network overhead, improving transaction execution efficiency, and ultimately increasing transaction throughput. Without incurring the consensus overhead of multiple additional shards, this effectively solves the problem of upgraded storage requirements and improves the storage scalability of the blockchain system. Specifically, the architecture uses layered storage based on frequently accessed accounts, separating the storage layer and the consensus layer, each with its own function. Under a pre-defined freezing protocol, the process of executing transactions by archive nodes and consensus nodes, as well as the storage tree in contract accounts, is updated and executed according to different transaction types. This saves the total storage space of consensus nodes: because less frequently accessed data is frozen in archive nodes, the amount of data that consensus nodes need to store is reduced. Furthermore, the existing contract account model is modified to address the temporal locality of smart contract state data, allowing nodes to retain frequently accessed contract state data. When executing transactions, nodes can first read the local database and update the local state data. Simultaneously, because less data is stored in the consensus nodes, their transaction execution efficiency is improved, ultimately increasing transaction throughput.

[0172] In this embodiment of the invention, a blockchain transaction processing method is provided. When an archive node in the blockchain receives a transaction request, the archive node performs pre-execution of the transaction according to the transaction request, generating 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 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 preset freeze protocol conditions. If so, the block producer consensus node updates its data storage tree to determine the data storage tree at future times and stops the transaction. If not, the block producer consensus node performs the transaction using the transaction package data, generating the target transaction result. Based on the above scheme, determining the data type of the transaction package data according to the preset freeze protocol conditions and performing corresponding transaction processing according to the corresponding data type can reduce the data stored by the consensus nodes, improve the efficiency of transaction execution, and further reduce storage overhead.

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

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

[0175] The pre-transaction module 701 is used to pre-execute transactions and generate transaction package data when an archive node in the blockchain receives a transaction request.

[0176] Module 702 is used to determine the block producer consensus node based on a pre-set consensus algorithm among multiple consensus nodes in the blockchain.

[0177] The verification module 703 is used by the block producer consensus node to verify the transaction package data using a pre-set digital signature algorithm;

[0178] The judgment module 704 is used to determine whether the data type of the transaction package data is frozen type based on the preset freezing protocol conditions, if the verification passes.

[0179] The update module 705 is used to update the data storage tree of the block producer consensus node if the block producer consensus node is active, determine the data storage tree at future moments, and stop transactions.

[0180] Transaction module 706 is used to generate the target transaction result by using the transaction package data of the block producer consensus node, if not.

[0181] Furthermore, 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 pre-transaction module 701 is specifically used for:

[0182] The archive node verifies the digital signature based on a pre-set digital signature algorithm;

[0183] If the verification passes, the archive node determines whether the data type of the transaction data is frozen based on the pre-set freeze protocol conditions;

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

[0185] If neither the current storage tree nor the cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node generates a Merkel proof based on the state 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 Merkel proofs to perform pre-transactions and generate a transaction write set;

[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 Merkel proof to generate the first transaction package data;

[0188] If the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the status 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-transaction and generate a transaction write set.

[0189] The archive node packages the transaction write set, the transaction read set corresponding to the transaction data in 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.

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

[0191] The third transaction module is used to package the transaction data and digital signature into third transaction package data if the data type of the transaction data is frozen.

[0192] Furthermore, the judgment module 704 is specifically used for:

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

[0194] If present, the block producer consensus node determines that the data type of the transaction data is frozen.

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

[0196] Furthermore, the data storage tree of the block producer consensus node includes the current storage tree and the cache storage tree of the block producer consensus node; the data storage tree for future moments includes the cache storage tree for future moments and the current storage tree for future moments; the update module 705 is specifically used for:

[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 in the current storage tree of the block producer consensus node to determine the current storage tree at a future time.

[0199] Furthermore, the transaction module 706 is specifically used for:

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

[0201] If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the Merkle proof in the transaction package data, the state data of the transaction read set, the state data of the transaction write set, and the transaction data to perform the transaction and generate the target transaction result.

[0202] If the current storage tree or the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the state data of the transaction read / write set corresponding to the transaction data and the transaction data in the transaction package 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 construct 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 in the blockchain;

[0206] The third module is used by multiple nodes in 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 successful, thus determining the new blockchain.

[0208] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0209] Please see Figure 8 , Figure 8 This is a flowchart illustrating the steps of a blockchain transaction processing method applied to archive nodes in a blockchain, as provided in Embodiment 4 of the present invention.

[0210] This invention provides a blockchain transaction processing method, applied to archive nodes in a blockchain, comprising:

[0211] Step 801: When a transaction request is received, perform a pre-execution transaction based on the transaction request and generate transaction package data.

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

[0213] It should be noted that the target request is generated and sent to the archive node when the block producer consensus node needs transaction packaging data. The archive node responds to the request by sending the transaction packaging data to the block producer consensus node.

[0214] In this embodiment of the invention, when an archive node receives a transaction request, it performs a pre-execution transaction based on the transaction request to generate transaction package data; in response to the received target request, it sends the transaction package data to the block producer consensus node in the blockchain. The block producer consensus node determines the data type of the transaction package data based on the preset freeze protocol conditions, and performs the corresponding transaction processing according to the corresponding data type. This process can reduce the data stored by the consensus node, improve the efficiency of transaction execution, and further increase transaction throughput.

[0215] Please see Figure 9 , Figure 9 This is a flowchart illustrating the steps of a blockchain transaction processing method applied to a block producer consensus node in a blockchain, as provided in Embodiment 5 of the present invention.

[0216] This invention provides a blockchain transaction processing method, applied to the block producer consensus node in a blockchain, comprising:

[0217] Step 901: Send the 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: Verify the transaction package data using a pre-set digital signature algorithm.

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

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

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

[0222] In this embodiment of the invention, the data type of the acquired transaction package data is determined based on the pre-set freeze protocol conditions, and the corresponding transaction processing is performed according to the corresponding data type. In addition, the pre-transaction process is performed on the transaction request in conjunction with the archive node. This can reduce the data stored by the consensus node, improve the efficiency of transaction execution, and further increase the transaction throughput.

[0223] In the several embodiments provided in this 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 merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0225] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate 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 pre-execution of the transaction based on the transaction request and generates transaction package data; The blockchain has multiple consensus nodes that determine the block producer consensus node based on a pre-set consensus algorithm. The block producer consensus node uses a pre-set digital signature algorithm to verify the transaction package data; 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 freeze protocol conditions. If so, the block producer consensus node updates its data storage tree to determine the data storage tree at future times and stops transactions; If not, the block producer consensus node uses the transaction package data to perform the transaction and generate the target transaction result; 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 steps of the archive node performing pre-execution transactions and generating transaction package data according to the transaction request include: 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 freeze protocol conditions; If the data type of the transaction data is not frozen, the archive node determines whether the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data; If neither the current storage tree nor the cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node generates a Merkel proof based on 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 Merkel proof to perform pre-transactions 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 Merkel proof to generate the first transaction package data; If the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the status data of the transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node to perform 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 current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature to generate second transaction package data; The steps by which the block-producing consensus node uses the transaction package data to generate the target transaction result include: The block producer consensus node determines whether the transaction read / write set corresponding to the transaction data exists in the current storage tree or the cache storage tree of the block producer consensus node. If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the Merkel proof, the state data of the transaction read set, the state data of the transaction write set, and the transaction data in the transaction package data to perform the transaction and generate the target transaction result. If the current storage tree or the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the state data of the transaction read / write set corresponding to the transaction data and the transaction data in the transaction package data to perform the transaction and generate the target transaction result.

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

3. The blockchain transaction processing method according to claim 1, characterized in that, The step of the block producer consensus node determining whether the data type of the transaction package data is of the frozen type based on the pre-set freeze protocol conditions includes: The block producer consensus node determines whether there is a freeze identifier in the transaction data of the transaction package data; If present, the block producer consensus node determines that the data type of the transaction data is frozen. If not, the block producer consensus node determines that the data type of the transaction data is not frozen.

4. 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 data storage tree for future moments includes the cache storage tree for future moments and the current storage tree for future moments. The steps for the block-producing consensus node to update its data storage tree and determine the data storage tree at future moments include: The block producer consensus node uses the current storage tree of the block producer consensus node as the cache storage tree for future moments; The block producer consensus node clears the data in its current storage tree to determine the current storage tree at a future time.

5. The blockchain transaction processing method according to claim 1, characterized in that, After the block producer consensus node uses the transaction package data to perform a transaction and generate the target transaction result, the following steps are included: 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 will add the target block to their local blockchains to determine a new blockchain.

6. A blockchain transaction processing system, characterized in that, include: The pre-transaction module is used to pre-execute transactions and generate transaction package data when an archive node in the blockchain receives a transaction request. A determination module is used to determine the block producer consensus node based on a preset consensus algorithm among multiple consensus nodes in the blockchain. The verification module is used by the block producer consensus node to verify the transaction package data using a pre-set digital signature algorithm; The judgment module is used to determine whether the data type of the transaction package data is frozen, based on the preset freeze protocol conditions, if the verification is successful. The update module is used to update the data storage tree of the block producer consensus node if the condition is met, determine the data storage tree at a future time, and stop transactions. The transaction module is used to, if not, the block producer consensus node to use the transaction package data to perform a transaction and generate the target transaction result; 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 pre-transaction module is specifically used for: 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 freeze protocol conditions; If the data type of the transaction data is not frozen, the archive node determines whether the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data; If neither the current storage tree nor the cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node generates a Merkel proof based on 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 Merkel proof to perform pre-transactions 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 Merkel proof to generate the first transaction package data; If the current storage tree or cache storage tree of the archive node contains a transaction read set corresponding to the transaction data, the archive node uses the transaction data and the status data of the transaction read set corresponding to the transaction data in the current storage tree or cache storage tree of the archive node to perform 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 current storage tree or cache storage tree of the archive node, the transaction data, and the digital signature to generate second transaction package data; The transaction module is specifically used for: The block producer consensus node determines whether the transaction read / write set corresponding to the transaction data exists in the current storage tree or the cache storage tree of the block producer consensus node. If neither the current storage tree of the block producer consensus node nor the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the Merkel proof, the state data of the transaction read set, the state data of the transaction write set, and the transaction data in the transaction package data to perform the transaction and generate the target transaction result. If the current storage tree or the cache storage tree of the block producer consensus node contains a transaction read / write set corresponding to the transaction data, the block producer consensus node uses the state data of the transaction read / write set corresponding to the transaction data and the transaction data in the transaction package data to perform the transaction and generate the target transaction result.

7. A blockchain transaction processing method applied to the blockchain transaction processing system of claim 6, characterized in that, Archive nodes used in blockchain include: When a transaction request is received, a pre-execution transaction is performed according to the transaction request, and transaction package data is generated; In response to the received target request, the transaction package data is sent to the block producer consensus node in the blockchain.

8. A blockchain transaction processing method applied to the blockchain transaction processing system of claim 6, characterized in that, Block-producing consensus nodes used in blockchains include: 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; The transaction package data is verified using a pre-set digital signature algorithm; If the verification is successful, based on the preset freeze protocol conditions, it is determined whether the data type of the transaction package data is a freeze type; If so, update the data storage tree of the block producer consensus node, determine the data storage tree at future times, and stop transactions; If not, the transaction package data is used to perform the transaction and generate the target transaction result.

Images