Blockchain node and transaction information processing method applied to blockchain node

Abstract

A transaction information processing method applied to a blockchain node. The blockchain node includes a scheduling module, a transaction pool module and a virtual machine engine. The method comprises: receiving a transaction information sending request sent by a scheduling module, wherein the transaction information sending request is used for requesting a transaction pool module to start sending transaction information (401); in response to the transaction information sending request, determining a plurality of pieces of transaction information stored in the transaction pool module (402); and when a transaction queue for transmitting the plurality of pieces of transaction information comprises a first-type read queue and a first-type write queue, writing the plurality of pieces of transaction information into the first-type write queue, wherein the first-type write queue is constrained by a write lock, the first-type write queue constrained by the write lock only allows a single thread to perform a write operation on transaction information among the plurality of pieces of transaction information at the same moment, the first-type read queue allows a plurality of threads to concurrently perform a read operation on transaction information among the plurality of pieces of transaction information at the same moment, the first-type read queue is used for a virtual machine engine to read the transaction information and perform transaction processing on the plurality of pieces of transaction information to obtain processing results, and the plurality of pieces of transaction information and the processing results are used for instructing the scheduling module to package the plurality of pieces of transaction information into a new block on the basis of the processing results (403).

Description

Blockchain node and transaction information processing method applied to blockchain node

[0001] Related applications

[0002] This application claims priority to Chinese patent application number 2024102610871, filed on March 6, 2024, entitled “Blockchain Node and Transaction Processing Method Applied to Blockchain Node,” the entire text of which is hereby incorporated by reference. Technical Field

[0003] The present application relates to the field of blockchain technology, and in particular to a blockchain node and a transaction information processing method applied to the blockchain node. Background Art

[0004] In the blockchain system, after obtaining new transaction information, the blockchain node will first temporarily store the new transaction information in the cache pool module of the blockchain node. When the blockchain node is ready to generate a new block, it will select a certain amount of transaction information from the transaction pool module for processing and packaging.

[0005] In related technologies, the transaction pool module transmits multiple transaction information that needs to be packaged into a new block to the virtual machine engine of the blockchain node in the form of a single queue. For example, the transaction pool module writes the transaction information into the queue, and the virtual machine engine reads and processes the transaction information from the queue. At the same time, in order to protect the synchronization consistency of the transaction information in the queue, a read-write lock is usually added to the transaction information when the transaction information is transmitted. However, this will cause the problem of read-write lock conflicts, that is, when writing transaction information to the queue, a write lock needs to be held, and when reading transaction information from the queue, a read lock needs to be held. When the write thread occupies the write lock to write transaction information to the queue, other write threads and read threads can only wait. When the read thread occupies the read lock to read transaction information from the queue, the write thread can only wait. This can easily lead to blockage in the reading and writing of transaction information, and the transmission efficiency of transaction information in the blockchain node is low. Summary of the Invention

[0006] The present application provides a blockchain node and a transaction information processing method applied to the blockchain node.

[0007] According to one aspect of an embodiment of the present application, a transaction information processing method applied to a blockchain node is provided, wherein the blockchain node includes a scheduling module, a transaction pool module, and a virtual machine engine, and the method includes:

[0008] receiving a transaction information sending request sent by the scheduling module, wherein the transaction information sending request is used to request the transaction pool module to start sending transaction information;

[0009] In response to the transaction information sending request, determining a plurality of transaction information stored in the transaction pool module; and

[0010] In a case where a transaction queue for transmitting the multiple transaction information includes a first-type read queue and a first-type write queue, the multiple transaction information is written into the first-type write queue, the first-type write queue is constrained by a write lock, and the first-type write queue under the write lock constraint allows only a single thread to perform a write operation on transaction information from the multiple transaction information at the same time, while the first-type read queue allows multiple threads to perform a read operation on transaction information from the multiple transaction information in parallel at the same time. The first-type read queue is used for the virtual machine engine to read the transaction information, perform the transaction processing on the multiple transaction information to obtain a processing result, and the multiple transaction information and the processing result are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing result.

[0011] According to one aspect of an embodiment of the present application, a transaction information processing method applied to a blockchain node is provided, wherein the blockchain node includes a scheduling module, a transaction pool module, and a virtual machine engine, and the method includes:

[0012] In a case where the transaction queue for transmitting transaction information includes a first-type read queue and a first-type write queue, multiple transaction information is read from the first-type read queue, the first-type read queue allows multiple threads to concurrently perform read operations on transaction information from the multiple transaction information at the same time, the multiple transaction information in the first-type write queue is written by the transaction pool module, the first-type write queue is constrained by a write lock, and under the write lock constraint, the first-type write queue only allows a single thread to perform write operations on transaction information from the multiple transaction information at the same time;

[0013] Performing transaction processing on the plurality of transaction information to obtain processing results corresponding to the plurality of transaction information; and

[0014] The multiple transaction information and the processing results are sent to the scheduling module, where the multiple transaction information and the processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results.

[0015] According to one aspect of an embodiment of the present application, a blockchain node is provided, wherein the blockchain node includes a transaction pool module, a virtual machine engine, and a scheduling module;

[0016] The transaction pool module is configured to receive a transaction information sending request sent by the scheduling module, the transaction information sending request being used to request the transaction pool module to start sending transaction information; determine, in response to the transaction information sending request, multiple transaction information stored by the transaction pool module; and write the multiple transaction information into the first-class write queue, if the transaction queue used to transmit the multiple transaction information includes a first-class read queue and a first-class write queue, wherein the first-class write queue is constrained by a write lock, and under the write lock constraint, the first-class write queue only allows a single thread to perform a write operation on transaction information from the multiple transaction information at the same time, while the first-class read queue allows multiple threads to perform a read operation on transaction information from the multiple transaction information in parallel at the same time;

[0017] The virtual machine engine is configured to read the plurality of transaction information from the first type read queue; perform transaction processing on the plurality of transaction information to obtain processing results corresponding to the plurality of transaction information; and send the plurality of transaction information and the processing results to the scheduling module;

[0018] The scheduling module is configured to package the plurality of transaction information into a new block based on the processing result.

[0019] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is loaded and executed by a processor to implement the above-mentioned transaction information processing method applied to a blockchain node.

[0020] According to one aspect of an embodiment of the present application, a computer program product is provided, which includes a computer program stored in a computer-readable storage medium, and a processor reads and executes the computer program from the computer-readable storage medium to implement the above-mentioned transaction information processing method applied to a blockchain node.

[0021] The details of one or more embodiments of the present application are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the present application will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0023] FIG1 is a schematic diagram of an implementation environment of a solution provided by an embodiment of the present application;

[0024] FIG2 is a schematic diagram of a blockchain node provided by one embodiment of the present application;

[0025] FIG3 is a schematic diagram of the interaction relationship between various modules in a blockchain node provided by one embodiment of the present application;

[0026] FIG4 is a flowchart of a transaction information processing method applied to a blockchain node provided by one embodiment of the present application;

[0027] FIG5 is a schematic diagram of a transaction queue provided by an embodiment of the present application;

[0028] FIG6 is a flowchart of a method for determining a write location of transaction information provided by one embodiment of the present application;

[0029] FIG7 is a schematic diagram of a first type of write queue provided by one embodiment of the present application;

[0030] FIG8 is a schematic diagram of a first type of write queue provided by another embodiment of the present application;

[0031] 9 and 10 are schematic diagrams of a method for switching between a first type of read queue and a subqueue provided by one embodiment of the present application;

[0032] FIG11 is a flowchart of a transaction information processing method applied to a blockchain node provided in another embodiment of the present application;

[0033] FIG12 is a flowchart of a method for transmitting processing results according to an embodiment of the present application;

[0034] FIG13 is a schematic diagram of a result queue provided by one embodiment of the present application;

[0035] FIG14 is a schematic diagram of a second type of write queue provided by one embodiment of the present application;

[0036] FIG15 is a flowchart of a transaction information processing method applied to a blockchain node provided by another embodiment of the present application;

[0037] FIG16 is a flowchart of a method for switching between a read queue and a write queue provided by one embodiment of the present application;

[0038] FIG17 is a structural block diagram of a computer device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0041] First, the terms involved in this application are introduced and explained.

[0042] Blockchain technology is a distributed ledger technology in the field of information technology. It is generally composed of consensus, transaction blocks and status data storage, cryptographic identity security, etc. Since the ledger is stored in a distributed manner and the blocks are agreed upon, it has the characteristics of being tamper-proof, traceable, and jointly maintained (it packages transaction information into blocks and links them together through cryptography to form an unalterable chain (i.e., blockchain). Each block contains transaction records and the hash value of the previous block).

[0043] A blockchain system can refer to a distributed system implemented using blockchain technology. A blockchain system can include the underlying blockchain platform, the platform's product and service layer, and the application service layer. A blockchain system can also be referred to as a blockchain network.

[0044] The underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation management. Among them, the user management module is responsible for the identity information management of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between the user's real identity and the blockchain address (authority management), etc., and under authorization, it supervises and audits the transactions of certain real identities and provides risk control rule configuration (audit); the basic service module is deployed on all blockchain node devices to verify the validity of business requests (i.e. transaction information), and records the valid requests to the storage after consensus is reached. For a new business request, the basic service first performs interface adaptation analysis and authentication processing (interface adaptation), and then encrypts the business information through the consensus algorithm (consensus Management), and after encryption, it is transmitted completely and consistently to the shared ledger (network communication) and recorded and stored; the smart contract module is responsible for the registration, issuance, triggering and execution of contracts. Developers can define the contract logic in a programming language and publish it to the blockchain system (contract registration). According to the logic of the contract terms, the key or other events are called to trigger the execution to complete the contract logic. At the same time, it also provides the function of contract upgrade and cancellation; the operation management module is mainly responsible for the deployment, configuration modification, contract setting, cloud adaptation and real-time status visualization output of the product operation during the product release process, such as alarm, management network status, management node device health status, etc.

[0045] The platform's product service layer provides the basic capabilities and implementation framework for typical applications. Developers can build on these basic capabilities, overlay business features, and complete the blockchain system implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0046] Blockchain is the core data structure in blockchain systems. It represents a novel application model for computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks (i.e., blocks) generated using cryptographic methods. Each block contains information about a batch of network transactions (i.e., transaction information), which is used to verify the validity of this information (to prevent counterfeiting) and generate the next block. For example, a blockchain can be used to store and manage all confirmed blocks. A blockchain is organized in a chain-like structure, with each block containing a set of transactions, a block header (including metadata such as the hash value of the previous block and a timestamp), and other information. Blockchain provides a public, immutable record of transaction history for the blockchain system, ensuring its transparency and consistency. A blockchain can also be referred to as a blockchain ledger.

[0047] A blockchain consists of a series of blocks that are sequentially generated. Once added to the blockchain, they cannot be removed. A block consists of a header and a body. The header includes the block's version number, root hash, a timestamp indicating the block's creation, a difficulty value (Target_bits), and a random number (Nonce). The body of the block records the transaction information within the block, which can be arranged in a Merkle tree structure. The root hash typically refers to the hash value of the root node of a Merkle tree. A Merkle tree is a binary tree structure used to efficiently verify the integrity of large amounts of data. The root hash is calculated recursively by calculating the hash values ​​of the nodes in the tree. Starting with the leaf nodes, each leaf node stores the hash value of a data block (such as transaction information). The hash values ​​of two adjacent leaf nodes are combined and hashed to obtain the hash value of their parent node. This process is repeated until the hash value of the root node, known as the root hash, is finally obtained. In blockchains, the root hash is included in the block header. By verifying the root hash, nodes can quickly check the integrity of transaction information across the entire block. If any transaction is tampered with, the Merkle tree structure changes, and the root hash changes accordingly, making it easy to detect data inconsistencies.

[0048] A Merkle tree is a binary tree constructed from the hash values ​​of a set of data blocks. The leaf nodes of the tree contain the hash value of each data block, while non-leaf nodes contain the hash value of the combined hash values ​​of their two child nodes. Ultimately, the hash value of the root node is the root hash. When constructing a Merkle tree, all data blocks to be processed are hashed individually to obtain the hash values ​​of the leaf nodes. The hash values ​​of adjacent leaf nodes are then combined and hashed to obtain the hash value of the node in the previous level. This process is repeated until the root node is generated. Due to its structural characteristics, even the slightest change to any data block will cause all hash values ​​from the corresponding leaf node to the root node to change. Therefore, simply verifying the correctness of the root hash can determine whether the entire data set has been tampered with. In a blockchain, transaction information within the main block can be arranged according to the Merkle tree structure to ensure the integrity and security of transaction information.

[0049] A nonce is an arbitrary number included in the block header, typically a 32-bit or 64-bit integer. While the patent doesn't elaborate on its specific mechanism within this system, in general blockchain concepts, it plays a key role in the Proof-of-Work (PoW) consensus mechanism. Miners continually try different nonce numbers, hashing them together with other information in the block header (such as the hash value of the previous block, the root hash of transaction information, etc.) until they find a result that meets certain conditions (such as a hash value less than a target value). The miner who finds the right nonce receives a block reward and adds the new block to the blockchain.

[0050] After transaction information is generated, it is stored in the blockchain node's transaction pool (also known as the memory pool or mempool). The transaction pool module is the internal memory space within the blockchain node program used to cache transaction information. Transaction information in the transaction pool module has not yet been written to the blockchain ledger (also known as the blockchain). For any transaction information in the transaction pool module, it simply indicates that the blockchain node has received the transaction information. When a block needs to be generated later, the blockchain node extracts a batch of transaction information from the transaction pool module and removes it from the transaction pool module, using this batch of transaction information to form a block. For example, the transaction pool module is a data structure in the blockchain system that stores transaction information that has not yet been packaged into a block. When a user submits new transaction information to the blockchain network, it first enters the transaction pool module. When preparing to generate a new block, the blockchain node selects a certain number of transaction information from the transaction pool module for packaging. The transaction pool module helps improve the processing capacity of the blockchain network and can also serve as a strategy to allow blockchain nodes to prioritize transaction information with higher handling fees for packaging, thereby increasing blockchain node revenue.

[0051] A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, and these transactions are traceable and irreversible. For example, a smart contract can be implemented as a program stored on a blockchain that automatically executes when pre-set conditions are met, such as automatically executing all operations in an agreement or contract. Smart contracts are primarily used to execute transactions and access status data. For example, they can query the logistics status of a buyer's purchased goods and transfer the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions; they can also execute contracts that process received information.

[0052] State data is a data structure used within a blockchain system to represent the current state of the system. This data includes the balances of all accounts, the status of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security. For example, state data can be stored in a state database, which can be used to store the entire blockchain system's state data.

[0053] A read-write set refers to the set of data items involved in executing a blockchain transaction. It consists of two parts: the readset (the data set required to read the transaction) and the writeset (the data set required to write the transaction results). In a blockchain system, read-write sets are used to record transactions' accesses and modifications to state data, ensuring correct transaction execution and data consistency. Read-write sets are generated by executing smart contracts based on transaction information. A read-write set identifier, which can be referred to as a read-write set key, is used to identify the read-write set.

[0054] A transaction is a user's request for an operation on a smart contract deployed on a blockchain. Transaction information is information describing a transaction, and is used to refer to the transaction. A transaction is initiated by a user, such as from a user's client to a blockchain node (called a master node) in the blockchain system. Upon receiving the transaction (e.g., transaction information), the master node invokes the corresponding smart contract based on the contract address and interface specified in the transaction. It then notifies other blockchain nodes (called slave nodes) of the transaction. Upon receiving the transaction, the slave nodes then invoke the corresponding smart contract based on the contract address and interface specified in the transaction to process the transaction.

[0055] Please refer to Figure 1, which is a schematic diagram of an implementation environment of a solution provided by an embodiment of the present application. The implementation environment of the solution can be implemented as a blockchain system, and the blockchain system 100 may include: multiple blockchain nodes 101.

[0056] The blockchain node 101 is the basic component unit of the blockchain system 100. The blockchain system 100 may include multiple blockchain nodes 101. There is a communication connection between the blockchain nodes 101 so that data can be transmitted between any two blockchain nodes 101, such as receiving data (such as blocks, transaction information, processing results, etc.) from other nodes, or sending data to other nodes.

[0057] Blockchain nodes 101 can be any computer device connected to a network, such as a server or user terminal. Blockchain nodes 101 form a peer-to-peer (P2P) network. The P2P protocol is an application layer protocol that runs on top of the TCP (Transmission Control Protocol). In a distributed system, any machine, such as a server or terminal device, can become a blockchain node. Blockchain nodes consist of a hardware layer, a middle layer, an operating system layer, and an application layer.

[0058] The blockchain node 101 has at least the functions of transaction information processing, blockchain maintenance, consensus, sending and receiving, calculation, and storage. For example, the blockchain node 101 can send transaction information to other nodes in the blockchain system 100, and perform transaction processing, consensus, storage, and other operations on the acquired transaction information. Transaction information processing can be transaction processing of transaction information.

[0059] The functions of each blockchain node 101 in the blockchain system 100 include but are not limited to one of the following:

[0060] Routing is a basic function of the blockchain node 101, used to achieve communication between blockchain nodes 101.

[0061] Applications are deployed in blockchain systems to implement specific businesses based on actual business needs. They record data related to the implementation of functions to form record data. The record data carries a digital signature to indicate the source of the task data. The record data is sent to other nodes in the blockchain system for other nodes to add to the temporary block when they successfully verify the source and integrity of the record data.

[0062] For example, the services implemented by the application include: a shared ledger, which is used to provide functions such as storage, query and modification of account data, and sends record data of operations on account data to other nodes in the blockchain system. After verification by other nodes, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the blockchain node 101 that initiated the operation.

[0063] In one example, refer to Figure 2, which is a schematic diagram of a blockchain node provided by one embodiment of the present application. The blockchain node 101 can be any blockchain node in the blockchain system, or a blockchain node dedicated to processing transaction information in the blockchain system, which is not limited in this embodiment of the present application. The blockchain node 101 may include a network module 1011, a verification module 1012, a transaction pool module 1013, a scheduling module 1014, a virtual machine engine 1015, a consensus module 1016, and a storage module 1017.

[0064] The network module 1011 is responsible for communication between blockchain nodes and has a routing function. It can realize data transmission between blockchain nodes, such as transaction information broadcasting and block synchronization.

[0065] Verification module 1012 is responsible for performing certificate and authority verification on transaction information. Certificate verification refers to the process of verifying the identity certificate of the transaction initiator corresponding to the transaction information to ensure the legitimacy of the transaction initiator's identity. Authority verification refers to the process of verifying whether the transaction initiator has the authority to execute the transaction.

[0066] The transaction pool module 1013 is used to store transaction information. The transaction pool module 1013 may include a transaction queue sender, which is used to send transaction information to the virtual machine engine 1015. Optionally, the transaction queue sender can also be implemented independently of the transaction pool module 1013, which is not limited in this embodiment of the application.

[0067] The scheduling module 1014 is responsible for packaging transaction information and generating blocks. This scheduling module 1014 may include a transaction packager, a block generator, and a result queue reader. The transaction packager is used to package processed transaction information into blocks, and the block generator is used to generate new blocks, including a block header and block body. The result queue reader is used to obtain the transaction information processing results from the virtual machine engine 1015.

[0068] Virtual machine engine 1015 is responsible for executing and verifying transaction processing of transaction information. This virtual machine engine 1015 may include a transaction execution and verification module, a transaction queue reader, and a result queue sender. The transaction execution and verification module is responsible for executing transaction processing, obtaining processing results, and verifying the correctness of the processing results. The transaction queue reader is used to obtain transaction information from the transaction pool module 1013, and the result queue sender is used to send the processing results of the transaction information to the scheduling module 1014. Optionally, the result queue sender can also be implemented independently of virtual machine engine 1015, which is not limited in this embodiment of the application.

[0069] Consensus module 1016 is responsible for reaching consensus on block and transaction information within the blockchain system to ensure the correctness and security of the blockchain. Consensus is the process of maintaining consistency across the distributed ledger (i.e., blockchain) across all blockchain nodes in the blockchain system.

[0070] Storage module 1017 is responsible for storing blockchain data, including the block ledger and state data. The block ledger is responsible for storing processed block data, and the state data is responsible for storing state information in the blockchain system, such as account balances and smart contract data.

[0071] In one example, referring to FIG3 , the interaction relationship between the modules in the blockchain node 101 may be as follows:

[0072] The network module 1011 and the verification module 1012 are communicated with each other, the verification module 1012 and the transaction pool module 1013 are communicated with each other, the transaction pool module 1013 and the virtual machine engine 1015 and the scheduling module 1014 are communicated with each other, the virtual machine engine 1015 and the scheduling module 1014 are communicated with each other, the scheduling module 1014 and the consensus module 1016 are communicated with each other, and the consensus module 1016 and the storage module 1017 are communicated with each other.

[0073] After acquiring new transaction information, network module 1011 sends it to verification module 1012 for certificate and permission verification. Verification module 1012 then sends the verified transaction information to transaction pool module 1013 for storage. After receiving a transaction information transmission request from scheduling module 1014, transaction pool module 1013 adds multiple transaction information to be packaged into a new block to a transaction queue, which is then used to transmit the multiple transaction information to virtual machine engine 1015. Virtual machine engine 1015 then processes the multiple transaction information, obtains processing results for the multiple transaction information, and adds the multiple processing results to a result queue, which is then transmitted to scheduling module 1014 via the result queue. Optionally, virtual machine engine 1015 also transmits the processed multiple transaction information to scheduling module 1014. The scheduling module 1014 packages the processed transaction information into a new block, and sends the new block and the processing result to the consensus module 1016. The consensus module 1016 distributes the new block to other blockchain nodes for consensus, and after the consensus is completed, sends the new block and the processing result to the storage module 1017. The storage module 1017 updates the blockchain (such as adding the new block to the original blockchain) and status data (such as updating the status data according to the processing result) according to the new block and the processing result.

[0074] The following will use a method embodiment to illustrate the technical solution provided by the embodiment of the present application. For matters not described in the method embodiment, please refer to the above embodiment.

[0075] Please refer to Figure 4, which is a flowchart of a transaction information processing method applied to a blockchain node provided by one embodiment of the present application. For example, the execution subject of this method can be the node blockchain node 101 in the solution implementation environment shown in Figure 1, such as the transaction pool module 1013 in the node blockchain node 101. The node blockchain node 101 includes a scheduling module 1014, a transaction pool module 1013, and a virtual machine engine 1015. As shown in Figure 4, the method can include at least one of the following steps (401-403):

[0076] Step 401: Receive a transaction information sending request sent by a scheduling module. The transaction information sending request is used to request the transaction pool module to start sending transaction information.

[0077] The scheduling module is a module within a blockchain node responsible for packaging transaction information and generating blocks. This module includes a transaction packager, a block generator, and a result queue reader. The transaction packager packages processed transaction information into blocks, the block generator generates new blocks, including a block header and block body, and the result queue reader retrieves transaction processing results from the virtual machine engine. Furthermore, if the scheduling module determines that a new block needs to be generated, it generates a transaction information send request, instructing the transaction pool module to begin sending transaction information.

[0078] The transaction pool module is the internal memory space within the blockchain node program used to cache and store transaction information. This module includes a transaction queue sender, responsible for sending transaction information to the virtual machine engine. The transaction pool module receives transaction information send requests from the scheduling module, responds to these requests, identifies multiple pending transactions, and then writes these transactions into the first write queue within the transaction queue.

[0079] Transaction information describes transactions within a blockchain system and represents a user's request for an operation on a smart contract deployed on the blockchain. Transaction information can include the transaction's identity (TxID) and transaction attributes (such as the version number of the block to which it belongs, the specific transaction content, and a timestamp). Its purpose depends on the smart contract being invoked. For example, transaction information from a proof-of-storage contract can be used to store data, while transaction information from a transfer contract can be used for transfers or barter.

[0080] The scheduling module generates a transaction information transmission request when it determines that a new block needs to be generated. For example, the scheduling module may generate a new block at a first time interval, such as every 10 seconds, 15 seconds, or the like. The scheduling module may also generate a new block based on a first number of transactions, such as every 2000 or 1500 transactions, etc. This embodiment of the present application is not limited to this.

[0081] Blocks are generated by the scheduling module by packaging multiple processed transaction information. Transaction information is used to describe transactions in the blockchain system. A transaction is a user's request for an operation on a smart contract deployed on the blockchain. For example, transaction information can refer to a representation of an operation performed on the blockchain. The purpose of transaction information can be determined by the smart contract invoked by the transaction information. For example, transaction information invoking a proof contract can be used to store data; in another example, transaction information invoking a transfer contract can be used for transfers or barter; in another example, transaction information invoking a game contract can be used to invoke the game program, although this is not limited in the present embodiment.

[0082] In some embodiments, transaction information includes a transaction identifier (TxID) and transaction attribute information. The transaction identifier, also known as the transaction hash, uniquely identifies the transaction. Transaction attribute information includes the version number of the block to which the transaction information belongs and the specific transaction content (e.g., transaction input sequence, transaction output sequence). Furthermore, the attribute information may include a timestamp, which indicates when the transaction information was created. A transaction hash is a fixed-length string generated by processing transaction information using a specific hash algorithm (e.g., SHA-256). This string serves as a unique digital fingerprint of the transaction information. Regardless of the length of the transaction information, the hash value remains fixed. In blockchain, the transaction hash uniquely identifies each transaction. When a user initiates a transaction, all transaction details (e.g., sender address, recipient address, transaction amount, etc.) are combined and hashed to produce a transaction hash. Other nodes can use this hash value to quickly verify the integrity and uniqueness of the transaction, ensuring that the transaction has not been tampered with during transmission or storage. In a blockchain network, transaction hashes are used to identify and organize transactions when packaging them; when synchronizing transaction information between nodes, transaction hashes are also used to confirm whether the transaction has been processed.

[0083] Optionally, the transaction information sending request may include identification information of multiple transaction information to be packaged into the new block and to be processed, such as the identity of the transaction information, the creation time of the transaction information, the root hash of the new block, the version number, etc. For example, the scheduling module may determine the current packaging time period based on the first time interval, and determine the transaction information whose creation time is within the current packaging time period as the transaction information to be packaged into the new block, and then generate a transaction information sending request based on the identity or creation time of the transaction information to inform the transaction pool module which transaction information to send. Optionally. The transaction information sending request may also include the current packaging time period, and the transaction pool module may determine the transaction information that needs to be sent based on the current packaging time period, which is not limited in this embodiment of the present application.

[0084] The transaction pool module stores transaction information, which indicates pending transactions. This transaction information can be received by the blockchain node from other blockchain nodes. It can also be collected by the blockchain node, which can be generated by the blockchain node. It can also be sent by the transaction initiator to the blockchain node via a terminal device, though this is not a limitation in the present embodiment.

[0085] Step 402: In response to the transaction information sending request, determine a plurality of transaction information stored in the transaction pool module.

[0086] Optionally, the transaction pool module determines the multiple transaction information based on the identity identifier in the transaction information sending request, or determines the multiple transaction information based on the creation time in the transaction information sending request, or determines the multiple transaction information based on the current packaging time period in the transaction information sending request. The embodiments of the present application are not limited to this.

[0087] In a feasible example, the transaction information sending request is only used to request the transaction pool module to start sending transaction information. The specific transaction information to be sent can be determined by the transaction pool module itself, such as giving priority to sending transaction information with an earlier creation time to improve the timeliness of transaction information processing.

[0088] In step 403, when the transaction queue for transmitting multiple transaction information includes a first-class read queue and a first-class write queue, the multiple transaction information is written into the first-class write queue. The first-class write queue is constrained by a write lock. Under the write lock constraint, the first-class write queue only allows a single thread to perform a write operation on transaction information in the multiple transaction information at the same time. The first-class read queue allows multiple threads to perform a read operation on transaction information in the multiple transaction information in parallel at the same time. The first-class read queue is used for the virtual machine engine to read the transaction information, and transaction processing is performed on the multiple transaction information to obtain processing results. The multiple transaction information and the processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results.

[0089] In the embodiments of the present application, a transaction queue refers to a queue used to transmit transaction information, such as a queue used to transmit transaction information between a transaction pool module and a virtual machine engine. A queue is a data structure. The transaction queue in the embodiments of the present application is different from an ordinary queue and may include a first-class read queue and a first-class write queue. A first-class read queue refers to a queue used to read transaction information, but not to write transaction information. A first-class write queue refers to a queue used to write transaction information, but not to read transaction information. The first-class read queue and the first-class write queue are not connected.

[0090] Transaction processing refers to the process of processing transaction information (i.e., executing the transaction) and obtaining a processing result through the corresponding smart contract. In a blockchain system, user-initiated transaction information is received by the blockchain node. The virtual machine engine calls the corresponding smart contract based on the transaction information, executes the logic defined in the contract, completes the transaction operation, and generates a processing result. This processing result can be used to update the status data in the blockchain system.

[0091] The virtual machine engine is responsible for executing and verifying transaction processing of transaction information. This module can include a transaction execution and verification module, a transaction queue reader, and a result queue sender. The transaction execution and verification module is used to execute transaction processing, obtain processing results, and verify the correctness of the processing results; the transaction queue reader is used to obtain transaction information from the transaction pool module; and the result queue sender is used to send the processing results of the transaction information to the scheduling module.

[0092] Lock constraints are a mechanism used to protect the synchronization and consistency of shared resources. In blockchain transaction processing, these primarily involve read-write locks. Under a write lock, only a single thread is allowed to write to a constrained resource (such as a first- or second-class write queue) at a time to prevent data inconsistencies. Read locks typically allow multiple threads to read a resource simultaneously. By properly setting lock constraints, the efficient transmission of transaction information and processing results between different modules of a blockchain node can be improved.

[0093] Packaging refers to the process by which the scheduling module, based on the results of transaction processing by the virtual machine engine, integrates multiple processed transaction information into a new block. A new block consists of a block header and a block body. Transaction information is added to the block body of the new block. Once consensus is reached, the new block is added to the blockchain system. After determining that a new block needs to be generated, the scheduling module constructs the block header and block body of the new block. After the multiple transaction information is processed, the scheduling module can package it into the block body of the new block.

[0094] Optionally, the first type of write queue is subject to a write lock, while the first type of read queue is not. The write lock is the write lock within a read-write lock (a type of spin lock), of which there is only one. The write lock refers to the read-write lock when locked in write mode. A read-write lock is a synchronization primitive used to protect shared resources. It allows multiple threads to read a shared resource simultaneously (read lock), but only allows a single thread to perform a write operation (write lock) when writing to the resource. The read-write lock ensures that other threads cannot read or write to the shared resource during a write operation, thereby avoiding data inconsistencies. In blockchain transaction processing, read operations generally do not modify data, so the first type of read queue is designed to be free of lock constraints to avoid waiting caused by read-write lock conflicts. This design improves the concurrency of read operations, enabling the virtual machine engine to read in parallel, reducing transaction processing time, improving the blockchain node's ability to handle large numbers of concurrent transactions, and enhancing overall system performance.

[0095] Because the first-class write queue is subject to a write lock, while the first-class read queue is not, the virtual machine engine can use threads in parallel to read transaction information from the first-class read queue without occupying the read lock or waiting for the corresponding write lock of the first-class write queue to be released, thereby improving the efficiency of transaction information reading. The transaction pool module only needs to occupy the write lock to write transaction information to the first-class write queue in sequence without waiting for the release of the read lock (the first-class read queue is not subject to a lock), thereby improving the efficiency of transaction information writing and effectively improving the efficiency of transaction information transmission between the transaction pool module and the virtual machine engine.

[0096] In a feasible example, the process of the virtual machine engine performing transaction processing on multiple transaction information to obtain processing results is as follows: the virtual machine engine performs transaction processing on the read transaction information through the smart contract corresponding to the transaction information to obtain the processing result of the transaction information. For each transaction information in the same transaction group (i.e., the write area), the same smart contract is used for transaction processing; for transaction information in different transaction groups, it is necessary to switch to the corresponding smart contract for transaction processing. Since the transaction information is sorted by contract name and arrival time, this can reduce the switching cost of the smart contract and reduce the response time when the smart contract is switched. The virtual machine engine performs transaction processing on the read transaction information in sequence according to the order in which the transaction information is read, thereby obtaining the processing results corresponding to multiple transaction information.

[0097] In one feasible example, the virtual machine engine sends multiple transaction information and processing results to the scheduling module. These transaction information and processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results. The new block is a block of the blockchain that is added to the blockchain system after consensus is completed. Multiple transaction information can be added to the block body of the new block. The processing results can be used to update the status data in the blockchain system after consensus is completed. The specific sending method is as follows:

[0098] Transaction Information Transmission: A second transaction queue is set up between the virtual machine engine and the scheduling module. The virtual machine engine writes processed transaction information to the first-class write queue within this second queue. The scheduling module then reads the processed transaction information from the first-class read queue within this second transaction queue. The operating principle of this second transaction queue is the same as that of the transaction queue between the transaction pool module and the virtual machine engine.

[0099] Sending of processing results: When the result queue used to transmit the processing results includes a second-class read queue and a second-class write queue, the virtual machine engine writes the processing results into the second-class write queue. The second-class write queue is subject to a write lock constraint. The second-class write queue under the write lock constraint only allows a single thread to perform write operations on the processing results at the same time. The second-class read queue is used for the scheduling module to read the processing results, and the second-class read queue allows multiple threads to perform read operations in parallel at the same time. The specific steps are as follows: Obtaining the read-write set identifier: The virtual machine engine determines the read-write set required to process the transaction information and the processing result corresponding to the transaction information based on the transaction information corresponding to the processing result, and obtains the read-write set identifier of the read-write set, such as the read-write set key. Determine the write location: Determine the candidate subqueue: For each subqueue included in the second-class write queue, a subqueue that does not have a read-write set identifier that is the same as the read-write set identifier of the processing result is determined as a candidate subqueue. Determine the target subqueue: The first candidate subqueue in the candidate subqueue is determined as the target subqueue. Determine the write position in the target subqueue: Determine the write position of the processing result in the target subqueue based on the read-write set identifier of the processing result. The processing results in the subqueue are arranged in ascending order according to the read-write set identifier. Determine the write position in the second-class write queue: Determine the write position of the processing result in the target subqueue as the corresponding write position of the processing result in the second-class write queue. Write the processing result: Write the processing result to the write position to write the processing result to the second-class write queue. If there is no candidate subqueue in the second-class write queue, add a new subqueue to the tail of the second-class write queue and write the processing result to the head of the new subqueue.

[0100] When the processing results in the second-class read queue are cleared, a switch operation is performed between the subqueue and the second-class read queue. Specifically, the second-class read queue is moved to the end of the second-class write queue and the second-class read queue is changed to a new subqueue, resulting in a new second-class write queue. Simultaneously, the first subqueue in the second-class read queue is changed to the new second-class read queue. During the switch, all write and read operations on the processing results are prohibited to avoid errors in the transmission of processing results. After a batch of processing results (i.e., the processing results of all transaction information corresponding to a new block) is transmitted, the result queue can retain a subqueue (i.e., return to its initial state) to transmit the next batch of processing results, thereby reducing the result queue's utilization of transmission resources. The second-class read queue can also include a small number of subqueues, such as two or three. This helps reduce the frequency of switching between subqueues and the second-class read queue, thereby reducing the management workload of the result queue, while ensuring stable reading of processing results, reducing read wait times, and improving the efficiency of reading processing results.

[0101] In the above embodiment, by dividing the transaction queue into a first-class write queue subject to a write lock and a first-class read queue not subject to the lock, synchronous consistency during transaction information writing is ensured, and the mutual influence of read and write operations is avoided. The virtual machine engine can read transaction information in the first-class read queue in parallel without waiting for the write lock to be released, thereby improving reading efficiency. The transaction pool module only needs to occupy the write lock to write transaction information in sequence without waiting for the read lock to be released, thereby improving writing efficiency, thereby effectively improving the transmission efficiency of transaction information between the transaction pool module and the virtual machine engine, and ultimately improving the efficiency of transaction information processing in blockchain nodes. At the same time, the scheduling module packages transaction information into new blocks based on the processing results, ensuring the normal operation of the blockchain and the orderly storage of transaction records.

[0102] In one example, the first type of write queue is subject to a write lock constraint and can be implemented as follows: a write lock is added to the first type of write queue, and all threads need to occupy the write lock before they can perform write operations on the first type of write queue. The write operation refers to the process of writing transaction information to the first type of write queue. For example, a write lock is added to the storage address corresponding to the first type of write queue, and the thread needs to occupy the write lock before it can access and write to the storage address after the write lock is added. The write lock can be implemented as a section of code. When adding the write lock, the first type of write queue can be introduced into the section of code. When releasing the write lock, the first type of write queue can be deleted from the section of code. This embodiment of the present application is not limited to this.

[0103] In another example, a write lock can be added to the critical section (the code or program fragment used to perform write operations on the first type of write queue). When the current thread occupies the critical section with a write lock, other threads will be blocked regardless of whether they are performing write operations or read operations. A read operation refers to the process of reading transaction information from the first type of read queue. The critical section is the code or program fragment used to perform write operations on the first type of write queue. In a multi-threaded environment, in order to ensure the synchronization consistency of shared resources (such as the first type of write queue), a write lock can be added to the critical section. When the current thread occupies the critical section with a write lock, other threads will be blocked regardless of whether they are performing write operations or read operations, thereby ensuring that only a single thread is allowed to write transaction information to the first type of write queue at the same time, avoiding data conflicts and inconsistencies.

[0104] Optionally, the first-class write queue may further include at least one subqueue, each of which is connected end to end. Each subqueue can be used to write transaction information, such as the first subqueue and the second subqueue in at least one subqueue. After the first subqueue is filled, transaction information is written to the second subqueue. Exemplarily, the number of subqueues can be preset based on empirical values, such as a fixed number of 10 subqueues. The number of subqueues can also be adjusted in real time based on the transaction information written. For example, if each subqueue can write 10 transaction information, then for every 10 transaction information written, a new subqueue is added to the tail of the first-class write queue. The length of the first-class write queue can also be automatically adjusted based on the amount of transaction information written.

[0105] For example, refer to Figure 5, which is a schematic diagram of a transaction queue provided by one embodiment of the present application. Transaction queue 500 includes a first-class write queue 501 and a first-class read queue 502. First-class write queue 501 and first-class read queue 502 are not connected. Multiple subqueues within first-class write queue 501 are connected end-to-end, and each subqueue can have the same length. The length of first-class read queue 502 can be the same as the length of the subqueues.

[0106] The first-class write queue 501 is subject to a write lock, while the first-class read queue 502 is not. When a writer thread wishes to write transaction information to the first-class write queue 501, if it detects that another writer thread has already occupied the write lock, the writer thread waits for the other writer thread to release the write lock. After the other writer thread releases the write lock, the writer thread can seize the write lock and write the transaction information to the first-class write queue 501. If the writer thread detects that the write lock is not occupied, it can directly seize the write lock and write the transaction information to the first-class write queue 501.

[0107] When a reader thread wishes to read transaction information from the first-type read queue 502, it can directly read the transaction information from the first-type read queue 502, regardless of whether it detects that another reader thread is already performing a read operation. The transaction information in the first-type read queue 502 is read sequentially by the virtual machine engine, for example, from the head to the tail of the first-type read queue 502, or from the tail to the head of the first-type read queue 502. Blank cells in FIG. 5 indicate that there is no transaction information at that location.

[0108] In one example, the transaction queue in the initial state includes a first-class read-write queue, which is subject to a read-write lock constraint. The first-class read-write queue under the read-write lock constraint only allows a single thread to perform write operations at the same time, and allows multiple threads to perform read operations in parallel at the same time. The transaction queue in the initial state includes a first-class read-write queue subject to a read-write lock constraint. The read-write lock constraint allows the first-class read-write queue to only allow a single thread to perform write operations at the same time to ensure the consistency of written data, while allowing multiple threads to perform read operations in parallel at the same time to improve reading efficiency. On this basis, the claim further divides the transaction queue into a first-class write queue subject to a write lock constraint and a first-class read queue not subject to a lock constraint, further optimizing the concurrent processing of read and write operations. This design ensures the synchronous consistency when writing transaction information and avoids the mutual influence of read and write operations. The virtual machine engine can read transaction information from the first-class read queue in parallel, without waiting for the write lock to be released, thus improving reading efficiency. The transaction pool module only needs to occupy the write lock to write transaction information in sequence, without waiting for the read lock to be released, which improves writing efficiency. This effectively improves the transmission efficiency of transaction information between the transaction pool module and the virtual machine engine, and ultimately improves the efficiency of transaction information processing in blockchain nodes. At the same time, the scheduling module packages transaction information into new blocks based on processing results, ensuring the normal operation of the blockchain and the orderly storage of transaction records.

[0109] The first type of read / write queue is used by the transaction pool module to write transaction information and by the virtual machine engine to read transaction information. Optionally, the length of the first type of read / write queue can be the same as the length of the subqueue, that is, the transaction queue in the initial state only includes one subqueue.

[0110] Optionally, when a writer thread (i.e., the transaction pool module) wants to write transaction information into the first-class read-write queue, if it detects that another writer thread / reader thread has occupied the read-write lock, the writer thread waits for the other writer thread / reader thread to release the read-write lock. After the other writer thread / reader thread releases the read-write lock, the writer thread can occupy the read-write lock (i.e., the write lock) and write the transaction information into the first-class read-write queue. If it detects that neither another writer thread nor a reader thread has occupied the read-write lock, the writer thread can directly occupy the read-write lock (i.e., the write lock) and write the transaction information into the first-class read-write queue.

[0111] When a reader thread (i.e., the virtual machine engine) wants to read transaction information from the first type of read-write queue, if it detects that another writer thread has already occupied the read-write lock, the reader thread will wait for the other writer thread to release the read-write lock. After the other writer thread releases the read-write lock, the reader thread can occupy the read-write lock (i.e., the read lock) and read the transaction information from the first type of read-write queue. If it detects that no other writer thread has occupied the read-write lock or that a reader thread has already occupied the read-write lock, the writer thread can directly occupy the read-write lock (i.e., the read lock) and read the transaction information from the first type of read-write queue.

[0112] Optionally, when the first-class read / write queue is full, the transaction queue in the initial state can be changed to the transaction queue in the above state (denoted as a bidirectional multi-group sortable transaction queue, bidirectional: read and write; multi-group: including the first-class read queue and the first-class sub-queue; sortable: the transaction information in the first-class read queue is sortable). For example, the embodiment of the present application may also include the following content:

[0113] 1. Write transaction information into the first type of read-write queue.

[0114] Optionally, the transaction pool module may call a write thread to occupy a read-write lock, and write the transaction information into the first type of read-write queue in sequence, starting from the first transaction information among the multiple transaction information.

[0115] 2. When the first read-write queue is full, the first read-write queue is changed to the first read queue, and a first write queue is added after the first read queue. The first write queue is not connected to the first read queue.

[0116] The first-class read / write queue is full when all corresponding locations in the first-class read / write queue are written with transaction information. When the first-class read / write queue is changed to the first-class read queue, the read / write lock corresponding to the first-class read / write queue is released, and no lock is added to the first-class read queue. When the first-class write queue is added after the first-class read queue, a write lock is added to the first-class write queue.

[0117] Optionally, the first type write queue in an initial state includes only one sub-queue. As the amount of transaction information to be written increases, the first type write queue expands to include multiple sub-queues.

[0118] In the embodiments of the present application, the transaction queue in the initial state is configured to include only one first-class read-write queue constrained by a read-write lock. This configuration can effectively reduce the workload of managing the transaction queue when the number of transactions is small. However, when a large number of transactions are written and the first-class read-write queue is full, it is changed to a first-class read queue and an additional first-class write queue is added, switching to a bidirectional, multi-group, sortable transaction queue. This improves the efficiency of transaction information transmission, dynamically adjusts the queue structure based on transaction load, and optimizes the performance of blockchain nodes.

[0119] In one example, when at least one subqueue included in the first type write queue is full, a new subqueue is added to the tail of the first type write queue, and the head of the new subqueue is connected to the tail of the first type write queue.

[0120] For example, if a subqueue included in the first-type write queue is full, a new subqueue is added after the subqueue; or if multiple subqueues included in the first-type write queue are full, a new subqueue is added after the last subqueue. The length of this new subqueue is the same as the length of the subqueues included in the first-type write queue. Subsequent transaction information to be written can be written into this new subqueue.

[0121] In this embodiment of the present application, when at least one subqueue of the first-class write queue is full, meaning that as the amount of transaction information being written increases, a new subqueue is added to the end of the queue. This adaptive addition of new subqueues ensures that all transaction information corresponding to a new block can be fully written into the transaction queue and transmitted to the virtual machine engine for processing. At the same time, multiple subqueues provide a foundation for conversion between the first-class read queue and the subqueues, facilitating subsequent queue management and efficient transmission of transaction information, thereby improving the overall performance of blockchain nodes in processing transaction information.

[0122] In the above embodiment, by configuring the transaction queue in the initial state to include only one first-class read / write queue, the transaction queue management workload can be effectively reduced. When the number of transactions to be written is large, switching to a bidirectional multi-group sortable transaction queue can effectively improve the transmission efficiency of transaction information.

[0123] Optionally, the transaction information in the above-mentioned transaction queue can be sorted, such as the transaction information in the first-class write queue can be sorted. Exemplarily, the sorting can be implemented by the transaction pool module, or it can be implemented by the transaction queue itself, and the embodiments of the present application are not limited to this. For example, after determining the write position of the transaction information, the transaction pool module can directly add it to the corresponding write position in the first-class write queue. The transaction pool module can also only add the transaction information to the first-class write queue, and the transaction queue can sort the transaction information by itself, that is, automatically determine the write position of the transaction information in the first-class write queue. Among them, the write position refers to the position where the transaction information is written in the first-class write queue.

[0124] For the transaction pool module and the transaction queue, the method for determining the write position is the same, and the following takes the transaction pool module as an example for explanation. In one example, as shown in FIG6 , step 403 may also include the following sub-steps:

[0125] Step 403a, obtain the contract name and arrival time of the transaction information. The contract name refers to the name of the smart contract used to process the transaction information, and the arrival time refers to the time when the transaction information arrives at the transaction pool module.

[0126] Optionally, the transaction pool module determines the smart contract to be called based on the contract address specified in the transaction information, and further determines the contract name of the transaction information. For example, if the name of the smart contract used to process transaction information A is B, B can be determined as the contract name of the transaction information.

[0127] The transaction pool module determines the arrival time of the transaction information based on the time when the transaction information arrives at the transaction pool module. For example, if the transaction information arrives at the transaction pool module at 20:17, 20:17 can be determined as the arrival time of the transaction information.

[0128] Optionally, for the data used for sorting transaction information, the embodiment of the present application is not limited to the above-mentioned contract name. Any identification information that can uniquely identify a smart contract can be used for sorting transaction information.

[0129] Step 403b: Determine the write area corresponding to the transaction information in the first type write queue according to the contract name of the transaction information. The contract name of the transaction information in the write area is the same as the contract name of the transaction information.

[0130] The aforementioned write area refers to the area in the first-class write queue occupied by transaction information with the same contract name. Different contract names correspond to different write areas, and the write area can be identified by its corresponding storage address. Optionally, each transaction information within the same write area has the same contract name, that is, each transaction information within the same write area is processed by the same smart contract. After each transaction information within a write area is processed by the corresponding smart contract, the smart contract is switched to process each transaction information within the next write area. This avoids frequent switching of smart contracts, thereby reducing the switching cost of smart contracts and the response time when smart contracts are switched, thereby effectively improving the processing efficiency of transaction information.

[0131] 7 , the first type of write queue 501 includes four write areas: the write area corresponding to contract 1, the write area corresponding to contract 2, the write area corresponding to contract 3, and the write area corresponding to contract 4. The transaction information in each write area has the same contract name.

[0132] Optionally, when there is target transaction information with the same contract name as the contract name of the transaction information in the first type of write queue, the write area where the target transaction information is located can be determined as the write area corresponding to the transaction information. When there is no transaction information with the same contract name as the contract name of the transaction information in the first type of write queue, the transaction information is written after the last transaction information in the first type of write queue, that is, a new write area is added for the transaction information, and the write area is identified by the contract name corresponding to the transaction information. In this way, when there is no transaction information with the same contract name as the current transaction information in the first type of write queue, that is, there is no corresponding write area, the transaction information is directly written after the last transaction information in the queue, that is, at the end of the first type of write queue. Such operation can effectively reduce the workload generated by adjusting the first type of write queue due to transaction information, improve the efficiency of writing transaction information, avoid unnecessary queue adjustment operations, and enable transaction information to enter the queue for processing more quickly.

[0133] For example, referring to Figures 5 and 8 , when the transaction pool module writes transaction information 504 into the first-type write queue 501, the transaction pool module can determine the corresponding write area 503 in the first-type write queue 501 based on the contract name of transaction information 504, and then write transaction information 504 into this write area 503. The virtual machine engine can read transaction information directly from the first-type read queue 502 without being affected by the write lock. In Figures 5 and 8 , cells with the same fill pattern form a write area, meaning that the transaction information corresponding to cells with the same fill pattern has the same contract name.

[0134] Step 403c: Determine the write location of the transaction information in the write area according to the arrival time of the transaction information, and arrange the transaction information in the write area in descending order according to the arrival time.

[0135] Optionally, the arrival time of the transaction information is sequentially compared with each transaction information in the write area to determine the write location of the transaction information. For example, if the arrival time of the transaction information is earlier than the arrival time of the first transaction information in the write area, the first location in the write area is determined as the write location of the transaction information; if the arrival time of the transaction information is earlier than the arrival time of the nth transaction information in the write area and later than the arrival time of the n-1th transaction information, the location corresponding to the nth transaction information is determined as the write location of the transaction information, where n is an integer greater than 1; if the arrival time of the transaction information is later than the arrival time of the last transaction information in the write area, the location corresponding to the transaction information after the last transaction information is determined as the write location of the transaction information.

[0136] For example, referring to Figures 7 and 8 (Figure 7 corresponds to Figure 8, and Figure 7 records the contract name and arrival time corresponding to each transaction information in the first type of write queue 501), the arrival time of transaction information 504 (20:10) is earlier than the arrival time of the first transaction information in the write area 503 (20:11), then the first position in the write area 503 can be determined as the write position of the transaction information 504.

[0137] In a feasible example, if the arrival time of the transaction information is earlier than the arrival time of the first transaction information in the write area, a position (such as a storage address) may be inserted before the first position in the write area to serve as the write position of the transaction information; if the arrival time of the transaction information is earlier than the arrival time of the nth transaction information in the write area and later than the arrival time of the n-1th transaction information, a position may be inserted between the position corresponding to the nth transaction information and the position corresponding to the n-1th transaction information to serve as the write position of the transaction information; if the arrival time of the transaction information is later than the arrival time of the last transaction information in the write area, a position may be inserted after the position corresponding to the last transaction information to serve as the write position of the transaction information.

[0138] Optionally, each transaction information after the write position and the original transaction information at the write position can be moved back one position in turn (i.e., the storage address is adaptively changed) to reserve a write position for the above transaction information. This embodiment of the present application is not limited to this.

[0139] For example, referring to FIG7 and FIG8 , each piece of transaction information written into area 503 and each piece of transaction information after area 503 are sequentially shifted back by one position to reserve a writing position for transaction information 504 .

[0140] Step 403d: Write the transaction information to the first type of write queue according to the write position.

[0141] Optionally, the transaction information is written into the write location to implement writing the transaction information into the first type of write queue. For example, referring to Figures 7 and 8 , the transaction information 504 can be directly written into the first location in the write area 503 .

[0142] In an embodiment of the present application, by sorting the transaction information written into the first type of write queue according to the contract name and arrival time, the switching cost of the smart contract can be reduced (reducing response time) while completing the processing of the transaction information in a timely manner (i.e., for the same write area, transaction information with an earlier arrival time is given priority). The write area is determined according to the contract name, so that the transaction information in the same write area is processed by the same smart contract. This method can effectively reduce the switching cost of the smart contract and reduce the response time during switching. At the same time, the transaction information in the write area is sorted according to the arrival time, and the transaction information with an earlier arrival time is given priority for the same write area. The processing of the transaction information can be completed in a timely manner, ensuring the timeliness of the transaction information processing and further improving the processing efficiency of the transaction information.

[0143] In one example, the embodiment of the present application can also realize automatic sorting of write areas. The various transaction information in the write area can be collectively referred to as a transaction group. The automatic sorting of the write area can be realized as automatic sorting of the transaction group.

[0144] For example, the transaction groups may be sorted based on the number of transactions in the transaction information included in the transaction groups (written to the area). This process may include the following:

[0145] 1. Get the number of transactions in each transaction group in the first type of write queue.

[0146] Get the number of transactions in a transaction group, that is, get the number of transactions in the write area corresponding to the transaction group. Transaction groups are clustered by contract name, and the number of transactions indicates the amount of transaction information used for transaction processing in the transaction group.

[0147] Optionally, each time a new transaction information is written to the transaction queue, the transaction pool module sorts the transaction group once; or, when the transaction information in the first type of read queue is cleared, the transaction pool module sorts the transaction group once, which helps reduce the workload of sorting the transaction group. This embodiment of the present application is not limited to this.

[0148] 2. Sort each transaction group in descending order of transaction quantity to obtain the adjusted first-class write queue.

[0149] Optionally, transaction groups are sorted by transaction count, from largest to smallest, to obtain a transaction group sequence. Transaction groups are then arranged in sequence according to the transaction group sequence to obtain an adjusted first-class write queue. For example, the transaction group with the largest transaction count is placed at the head of the first-class write queue, and the transaction group with the smallest transaction count is placed at the tail of the first-class write queue. This sorting of transaction groups by transaction count prioritizes smart contracts with a large number of transactions, minimizing the need for frequent switching of smart contracts within a short period of time. This reduces overall response time, improves transaction contract processing efficiency, and enables blockchain nodes to more efficiently process large volumes of transaction information.

[0150] Exemplarily, the transaction groups may be sorted based on the arrival time of the transaction information included in the transaction groups (written to the area). This process may include the following:

[0151] 1. Get the earliest arrival time of each transaction group in the first type of write queue.

[0152] The transaction group is obtained by clustering the contract names, and the earliest arrival time refers to the earliest arrival time corresponding to each transaction information used for transaction processing in the transaction group.

[0153] Optionally, for each transaction group, the arrival time corresponding to each transaction information in the transaction group is sorted in order from first to last to obtain an arrival time sequence, and the first arrival time in the arrival time sequence is determined as the earliest arrival time corresponding to the transaction group.

[0154] 2. Sort each transaction group in descending order of earliest arrival time to obtain the adjusted first-class write queue.

[0155] Optionally, the transaction groups are sorted in descending order of earliest arrival time to obtain a transaction group sequence. The transaction groups are then arranged in this order to obtain an adjusted first-class write queue. For example, the transaction group with the earliest arrival time is placed at the head of the first-class write queue, and the transaction group with the latest arrival time is placed at the tail of the first-class write queue. This sorting of transaction groups by arrival time prioritizes transactions with earlier arrival times, which helps improve the timeliness of transaction processing, ensures that earlier arriving transactions are processed first, reduces transaction waiting time, and improves the overall performance of the blockchain system.

[0156] In an example, when the transaction information in the first type of read queue is cleared, the embodiment of the present application may further include the following content:

[0157] 1. Move the first-class read queue to the end of the first-class write queue, and change the first-class read queue to a new subqueue to obtain a new first-class write queue.

[0158] Moving the first-class read queue to the end of the first-class write queue means adding the first-class read queue after the last subqueue in the first-class write queue and connecting it to the last subqueue. The new first-class write queue is used by the transaction pool module to write transaction information. If the last subqueue is full, new transaction information can be directly added to the moved first-class read queue (i.e., the new subqueue).

[0159] Optionally, after the first type read queue is moved to the end of the first type write queue, a write lock may be added to the first type read queue to convert the first type read queue into a new subqueue, thereby obtaining a new first type write queue.

[0160] The transaction information in the first type of read queue is cleared, which means that all transaction information in the first type of read queue is read by the virtual machine engine. After the transaction information in the first type of read queue is read by the virtual machine engine, the transaction pool module automatically deletes the transaction information to make room.

[0161] For example, referring to Figures 9 and 10 , for each transaction information in the first-class read queue 502, after the transaction information is read by the virtual machine engine, the transaction pool module automatically deletes the transaction information. When the transaction information in the first-class read queue 502 is cleared, the first-class read queue 502 is moved to the end of the first-class write queue 501, and the head of the moved first-class read queue 502 is connected to the first-class write queue 501. A write lock is added to the moved first-class read queue 502 to convert it into a new subqueue in the first-class write queue 501.

[0162] 2. Change the first subqueue in the first-class read queue to the new first-class read queue.

[0163] Optionally, the first subqueue is disconnected from the second subqueue in the first-class write queue and the write lock of the first subqueue is released, thereby changing the first subqueue to a new first-class read queue. The new first-class read queue is used by the virtual machine engine to obtain transaction information. In other words, the virtual machine engine will switch to reading transaction information from the new first-class read queue.

[0164] In the above embodiment, when transaction information in the first-class read queue is cleared, a switching operation is performed between the subqueue and the first-class read queue. Specifically, the first-class read queue is moved to the end of the first-class write queue and becomes a new subqueue. Simultaneously, the first subqueue in the first-class read queue is changed to a new first-class read queue. This switching method further helps prevent the interaction between write and read operations, allowing write operations to be performed in the new first-class write queue and read operations to be performed in the new first-class read queue, thus ensuring that the transmission of transaction information is not interfered with. Furthermore, this mechanism improves the efficiency of transaction information transmission, enabling blockchain nodes to continuously and efficiently process transaction information, and ensuring the smoothness and stability of transaction processing within the blockchain system.

[0165] Optionally, during the switching process between the sub-queue and the first-type read queue, all write operations and read operations on the transaction information are prohibited to avoid transaction information transmission errors.

[0166] For example, referring to Figures 9 and 10, for the first subqueue 505 in the first-class read queue, the first subqueue 505 is disconnected from the second subqueue in the first-class write queue 501, and the write lock of the first subqueue 505 is released to change the first subqueue to a new first-class read queue. The virtual machine engine can continue to read transaction information from the first subqueue 505 without holding the lock.

[0167] In one example, transaction information in a transaction queue can also be pre-written, such as pre-writing transaction information for a sub-queue, or pre-writing transaction information less than a specified data volume. The pre-written transaction information or specified data volume can be determined based on the new block, which is not limited in this embodiment of the application. Pre-writing can effectively further improve the transmission efficiency of transaction information.

[0168] In one example, after a batch of transaction information (i.e., all transaction information corresponding to a new block) is transmitted, the transaction queue can retain a sub-queue (i.e., restore to its initial state) to transmit the next batch of transaction information, which helps reduce the transaction queue's occupancy of transmission resources.

[0169] In one example, the first-class read queue can also include a small number of sub-queues, such as two or three. This helps reduce the switching frequency between the sub-queues and the first-class read queue, thereby reducing the workload of managing the transaction queue. At the same time, it can ensure stable reading of transaction information and reduce read latency, thereby improving transaction information reading efficiency.

[0170] The virtual machine engine is used to obtain the processing result of the transaction information. The processing result refers to the result obtained by performing transaction processing (i.e., executing the transaction) on the transaction information. Optionally, the virtual machine engine can perform transaction processing on the transaction information through the smart contract corresponding to the transaction information to obtain the processing result of the transaction information.

[0171] In summary, by adopting the technical solution provided in the embodiments of the present application, in the process of transmitting transaction information in the blockchain node, by setting the transaction queue into two types of queues: a write queue is used to write transaction information, and a read queue is used to read transaction information, and the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information, and the read queue is not constrained by the lock, thereby avoiding the read operation on the transaction information being affected by the write operation on the transaction information, and also avoiding the write operation on the transaction information being affected by the read operation on the transaction information, effectively improving the efficiency of the write operation on the transaction information and the efficiency of the read operation on the transaction information, thereby improving the transmission efficiency of the transaction information in the blockchain node, and then improving the processing efficiency of the transaction information in the blockchain node.

[0172] Please refer to Figure 11, which is a flowchart of a transaction information processing method applied to a blockchain node according to another embodiment of the present application. For example, the execution subject of this method may be the node blockchain node 101 in the solution implementation environment shown in Figure 1, such as the virtual machine engine 1015 in the node blockchain node 101. As shown in Figure 11, this method may include at least one of the following steps (1101-1103):

[0173] In step 1101, when a transaction queue for transmitting multiple transaction information includes a first-class read queue and a first-class write queue, multiple transaction information is read from the first-class read queue. The first-class read queue allows multiple threads to perform read operations on transaction information in the multiple transaction information in parallel at the same time. The multiple transaction information in the first-class write queue is written by the transaction pool module. The first-class write queue is constrained by a write lock. Under the write lock constraint, the first-class write queue only allows a single thread to perform write operations on transaction information in the multiple transaction information at the same time.

[0174] Among them, the transaction queue, the first type read queue, the first type write queue, transaction information, the write transaction pool module and the virtual machine engine are the same as those described in the above embodiment. The contents not described in the embodiment of this application can be referred to the above embodiment and will not be repeated here.

[0175] Optionally, because the first-class read queue is not subject to lock constraints, the virtual machine engine can simultaneously read transaction information from the first-class read queue using at least a single thread without holding a read lock or waiting for the write lock to be released. The transaction pool module, however, needs to hold a read lock to sequentially write transaction information to the first-class write queue. In one example, if the transaction queue only includes the first-class read and write queue, the virtual machine engine needs to hold a read lock to sequentially read transaction information from the first-class read and write queue.

[0176] Optionally, the virtual machine engine may read the transaction information in sequence from the head to the tail of the first type of read queue, and perform transaction processing on the read transaction information in sequence in this order.

[0177] Step 1102: perform transaction processing on the multiple transaction information to obtain processing results corresponding to the multiple transaction information.

[0178] Optionally, the virtual machine engine can process the transaction information through the smart contract corresponding to the transaction information to obtain the processing result of the transaction information. The processed multiple transaction information can be used to package into a new block.

[0179] Among them, for each transaction information in the same transaction group (i.e., the above-mentioned write area), the same smart contract can be used for transaction processing. For transaction information in different transaction groups, it is necessary to switch to the corresponding smart contract for transaction processing. The virtual machine engine can perform transaction processing on the read transaction information in the order in which the transaction information is read to obtain the processing results corresponding to the multiple transaction information. Since the transaction information is sorted by contract name and arrival time, this can reduce the switching cost of the smart contract and the response time when the smart contract is switched. The processing result refers to the result obtained by transaction processing (i.e., executing the transaction) on the transaction information.

[0180] Step 1103: Send the multiple transaction information and processing results to the scheduling module. The multiple transaction information and processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results.

[0181] A new block is a block added to the blockchain system after consensus is reached. The transaction information is added to the block body of the new block. The results of the processing can be used to update the state data in the blockchain system after consensus is reached.

[0182] In the above embodiment, from the perspective of the virtual machine engine, when the transaction queue is divided into a first-class read queue and a first-class write queue, the virtual machine engine can read transaction information from the first-class read queue without lock constraints, thereby improving reading efficiency. After processing the read transaction information, the transaction information and processing results are sent to the scheduling module for packaging into a new block, ensuring the normal processing of transaction information and the generation of new blocks in the blockchain system. At the same time, the read-write separation queue design avoids the mutual influence of read and write operations, improving the transmission and processing efficiency of transaction information in blockchain nodes.

[0183] In one example, the virtual machine engine can associate transaction information and the processing results corresponding to the transaction information together and send them to the scheduling module, such as sending them together to the scheduling module through the result queue described below; the virtual machine engine can also send the transaction information and the processing results to the scheduling module separately, such as sending the transaction information in the form of a transaction queue and sending the processing results in the form of a result queue. This embodiment of the present application is not limited to this.

[0184] In one feasible example, the virtual machine engine can also send transaction information to the scheduling module using a single queue, RPC (Remote Procedure Call Protocol), or other methods. Transaction information between the transaction pool module and the virtual machine engine can also be transmitted using a single queue, RPC (Remote Procedure Call Protocol), or other methods. It should be noted that applying the technical solutions provided by the embodiments of this application to either the virtual machine engine and the scheduling module, or the transaction pool module and the virtual machine engine, can improve the efficiency of transaction information transmission within blockchain nodes. The Remote Procedure Call Protocol (RPC) is a method for transmitting transaction information between the virtual machine engine and the scheduling module, or between the transaction pool module and the virtual machine engine. It allows a program on one computer to call a procedure or function in a program on another computer, just like calling a local program. In a blockchain system, RPC is used for communication between different modules. Its advantages are ease of use: developers can call remote functions as if they were local functions, improving development efficiency. It also decouples different modules, facilitating system expansion and maintenance. However, its disadvantages are that network latency can affect call performance, and measures must be taken to ensure communication security to prevent data leakage and malicious attacks.

[0185] Exemplarily, as shown in FIG12 , step 1102 may further include the following sub-steps.

[0186] Step 1102a: Send multiple transaction information to the scheduling module in the form of transaction queues.

[0187] Optionally, a second transaction queue is provided between the virtual machine engine and the scheduling module. The virtual machine engine can sequentially write processed transaction information into the first-type write queue within this second queue, and the scheduling module can sequentially read the processed transaction information from the first-type read queue within this second transaction queue. The operating principle of this second transaction queue is the same as that of the transaction queue between the transaction pool module and the virtual machine engine, and will not be further described here.

[0188] Step 1102b, when the result queue used to transmit the processing results includes a second-class read queue and a second-class write queue, the processing results are written to the second-class write queue, and the second-class write queue is subject to a write lock constraint. The second-class write queue under the write lock constraint only allows a single thread to perform a write operation on the processing result at the same time. The second-class read queue is used for the scheduling module to read the processing results, and the second-class read queue allows multiple threads to perform read operations in parallel at the same time.

[0189] In an embodiment of the present application, a result queue refers to a queue for transmitting the processing results corresponding to transaction information, such as a queue for transmitting processing results between a virtual machine engine and a scheduling module. The result queue in an embodiment of the present application is different from an ordinary queue, and may include a second-class read queue and a second-class write queue. The second-class read queue refers to a queue for reading processing results, which is not used for writing processing results. The second-class write queue refers to a queue for writing processing results, which is not used for reading processing results, and the second-class read queue and the second-class write queue are not connected. The data structure of the result queue is the same as that of the transaction queue, which can also be referred to as a bidirectional multi-group sortable result queue.

[0190] Optionally, the second type of write queue is subject to a write lock, while the second type of read queue is not. The write lock is the write lock within a read-write lock (a type of spin lock), of which there is only one. The write lock refers to the read-write lock when locked in write mode. A read-write lock is a synchronization primitive used to protect shared resources. It allows multiple threads to read a shared resource simultaneously (read lock), but only allows a single thread to write to the resource (write lock). The read-write lock ensures that other threads cannot read or write to the shared resource during a write operation, thereby avoiding data inconsistencies.

[0191] In the above embodiment, the transaction information and processing results are transmitted through the transaction queue and the result queue respectively. The result queue also adopts a read-write separation design, that is, a second-class write queue constrained by a write lock and a second-class read queue not constrained by the lock. Since the second-class write queue is constrained by the write lock and the second-class read queue is not constrained by the lock, the scheduling module can use threads in parallel to read the processing results in the second-class read queue without occupying the read lock or waiting for the release of the write lock corresponding to the second-class write queue, thereby improving the reading efficiency of the processing results. The virtual machine engine only needs to occupy the write lock to write the processing results to the second-class write queue in turn without waiting for the release of the read lock (because the second-class read queue is not constrained by the lock), thereby improving the writing efficiency of the processing results. This design ensures the synchronous consistency when the processing results are written, effectively improves the transmission efficiency of the processing results between the virtual machine engine and the scheduling module, and further improves the overall performance of the blockchain node.

[0192] In one example, the second type of write queue is subject to a write lock constraint and can be implemented as follows: a write lock is added to the second type of write queue, and all threads need to occupy the write lock before they can perform write operations on the second type of write queue to process the results. The write operation refers to the process of writing the processing results to the second type of write queue. For example, a write lock is added to the storage address corresponding to the second type of write queue, and the thread needs to occupy the write lock before it can access and write to the storage address after the write lock is added. The write lock can be implemented as a section of code. When adding the write lock, the second type of write queue can be introduced into the section of code. When releasing the write lock, the second type of write queue can be deleted from the section of code. This embodiment of the present application is not limited to this.

[0193] In another example, a write lock can be added to a critical section (the code or program fragment used to write to the second type of write queue). When the current thread uses the write lock to occupy the critical section, other threads will be blocked regardless of whether they are performing write or read operations. A read operation refers to the process of reading processing results from the second type of read queue.

[0194] Optionally, the above-mentioned second-class write queue may further include at least one subqueue, each of which is connected end to end. Each subqueue can be used to write processing results, such as the first subqueue and the second subqueue in at least one subqueue. After the first subqueue is filled, the processing results are written to the second subqueue. Exemplarily, the number of the subqueues can be preset based on empirical values, such as a fixed number of 10 subqueues. The number of the subqueues can also be adjusted in real time based on the written processing results. For example, if each subqueue can write 10 processing results, then for every 10 processing results written, a new subqueue is added to the tail of the second-class write queue. The length of the second-class write queue can also be automatically adjusted based on the number of written processing results.

[0195] For example, referring to FIG13 , which is a schematic diagram of a result queue provided by one embodiment of the present application, result queue 1300 includes a second-type write queue 1301 and a second-type read queue 1302. Second-type write queue 1301 and second-type read queue 1302 are not connected. Multiple subqueues within second-type write queue 1301 are connected end-to-end, and each subqueue can have the same length. Second-type read queue 1302 can have the same length as the subqueues.

[0196] The second-type write queue 1301 is subject to a write lock, while the second-type read queue 1302 is not. When a writer thread wishes to write a processing result to the second-type write queue 1301, if it detects that another writer thread has already taken the write lock, the writer thread waits for the other writer thread to release the write lock. After the other writer thread releases the write lock, the writer thread can take the write lock and write the processing result to the second-type write queue 1301. If the writer thread detects that the write lock is not already taken, it can directly take the write lock and write the processing result to the second-type write queue 1301.

[0197] When a read thread wishes to read a processing result from the second-type read queue 1302, it can directly read the processing result from the second-type read queue 1302, regardless of whether it detects that another read thread is already performing a read operation. The processing results from the second-type read queue 1302 are read sequentially by the scheduling module, such as from the head to the tail of the second-type read queue 1302, or from the tail to the head of the second-type read queue 1302. Blank cells in FIG. 13 indicate that there is no processing result at that location. Cells with the same fill pattern correspond to processing results with the same read-write set identifier.

[0198] In one example, the result queue in the initial state includes a second-type read-write queue, which is subject to a read-write lock constraint. The second-type read-write queue under the read-write lock constraint only allows a single thread to perform write operations at the same time, and allows multiple threads to perform read operations in parallel at the same time.

[0199] The second type of read / write queue is used for both the virtual machine engine to write transaction information and the scheduling module to read transaction information. Optionally, the length of the second type of read / write queue can be the same as the length of the above subqueue, that is, the result queue in the initial state only includes one subqueue.

[0200] Optionally, when a write thread (i.e., a virtual machine engine) wants to write a processing result into the second type of read-write queue, if it detects that another write thread / read thread has occupied the read-write lock, the write thread waits for the other write thread / read thread to release the read-write lock. After the other write thread / read thread releases the read-write lock, the write thread can occupy the read-write lock (i.e., the write lock) and write the processing result into the second type of read-write queue. If it detects that there are no other write threads or read threads occupying the read-write lock, the write thread can directly occupy the read-write lock (i.e., the write lock) and write the processing result into the second type of read-write queue.

[0201] When a read thread (i.e., the scheduling module) wants to read the processing result from the second type of read-write queue, if it detects that another write thread has occupied the read-write lock, the read thread will wait for the other write thread to release the read-write lock. After the other write thread releases the read-write lock, the read thread can occupy the read-write lock (i.e., the read lock) and read the processing result from the second type of read-write queue. If it detects that no other write thread has occupied the read-write lock or that a read thread has occupied the read-write lock, the write thread can directly occupy the read-write lock (i.e., the read lock) and read the processing result from the second type of read-write queue.

[0202] Optionally, when the second type of read and write queue is full, the result queue in the initial state can be changed to the result queue in the above state (denoted as a bidirectional multi-group sortable result queue, bidirectional: read and write; multi-group: including the second type of read queue and the second type of sub-queue; sortable: the processing results in the second type of read queue are sortable). For example, the embodiment of the present application may also include the following content:

[0203] 1. Write the processing results into the second type of read-write queue.

[0204] Optionally, the virtual machine engine may call a write thread to occupy a read-write lock, and write the processing results into the second type of read-write queue in sequence starting from the first processing result among the processing results corresponding to the multiple transaction information.

[0205] 2. When the second type read / write queue is full, the second type read / write queue is changed to a second type read queue, and a second type write queue is added after the second type read queue. The second type write queue is not connected to the second type read queue.

[0206] The second type of read / write queue is full when all corresponding locations in the second type of read / write queue have been written with processing results. When the second type of read / write queue is changed to the second type of read queue, the read / write lock corresponding to the second type of read / write queue is released, and no lock is added to the second type of read queue. When the second type of write queue is added after the second type of read queue, a write lock is added to the second type of write queue.

[0207] Optionally, the second type write queue in an initial state includes only one sub-queue, and as the number of written processing results increases, the second type write queue is expanded to include multiple sub-queues.

[0208] In one example, when at least one subqueue included in the second type write queue is full, a new subqueue is added to the tail of the second type write queue, and the head of the new subqueue is connected to the tail of the second type write queue.

[0209] Exemplarily, when a subqueue included in the second type of write queue is filled, a new subqueue is added after the subqueue; or, when multiple subqueues included in the second type of write queue are filled, a new subqueue is added after the last subqueue. The length of the new subqueue is the same as the length of the subqueue included in the second type of write queue. Subsequent processing results to be written can be written into the new subqueue. As the number of processing results to be written increases, new subqueues are adaptively added to ensure that the processing results of all transaction information corresponding to a new block can be written to the result queue for transmission to the scheduling module. At the same time, multiple subqueues provide the basis for conversion between the second type of read queue and the subqueue.

[0210] In the embodiment of the present application, the result queue is initially configured to contain only one second-class read-write queue constrained by a read-write lock. This effectively reduces the management workload of the result queue when the number of processing results is small. As the number of processing results increases, the second-class read-write queue is filled up, and it is changed to a second-class read queue, and a second-class write queue is added, switching to a bidirectional multi-group sortable result queue. This dynamic adjustment method takes into account both the convenience of management under low load and the improvement of the transmission efficiency of processing results under high load, thereby achieving flexible optimization of the queue structure according to the processing result load and improving the performance of blockchain nodes in processing processing results.

[0211] Optionally, the processing results in the above-mentioned result queue can be sorted, such as the processing results in the second type of write queue can be sorted. Exemplarily, the sorting can be implemented by the virtual machine engine, or it can be implemented by the result queue itself, and the embodiments of the present application are not limited to this. For example, after determining the write position of the processing result, the virtual machine engine can directly add it to the corresponding write position in the second type of write queue. The virtual machine engine can also only add the processing result to the second type of write queue, and the result queue can sort the processing result by itself, that is, automatically determine the write position of the processing result in the second type of write queue. Among them, the write position refers to the position where the processing result is written in the second type of write queue.

[0212] For the virtual machine engine and the result queue, the method for determining the write position is the same, and the following description will be made using the virtual machine engine as an example. In one example, step 1102b may also include the following content:

[0213] 1. Obtain the read-write set identifier of the processing result. The read-write set identifier is used to identify the read-write set of the transaction information corresponding to the processing result. The read-write set is used to record the transaction information corresponding to the processing result and the access and modification of the state data of the blockchain system where the blockchain node is located.

[0214] Optionally, the virtual machine engine determines a read-write set required to process the transaction information and the processing result corresponding to the transaction information based on the transaction information corresponding to the processing result, and obtains a read-write set identifier of the read-write set, such as a read-write set key.

[0215] 2. According to the read-write set identifier of the processing result, determine the corresponding write position of the processing result in the second type of write queue.

[0216] In an embodiment of the present application, for each sub-queue included in the second type of write queue, the read-write set identifiers corresponding to each processing result in the sub-queue can be made different as much as possible based on the read-write set identifiers of the processing results. In this way, processing results with different read-write set identifiers can be processed as much as possible in a short period of time, and different read-write sets can be accessed. This can avoid the read-write lock contention problem caused by the presence of a large number of processing results with the same read-write set identifier in the same sub-queue (such as the read-write lock contention that may exist when accessing the same read-write set), thereby improving the processing efficiency of the processing results and improving the transaction processing performance of the blockchain system.

[0217] Exemplarily, the process of determining the write position corresponding to the processing result in the second type write queue may include the following:

[0218] (1) For each sub-queue, a sub-queue that does not have a read-write set identifier that is the same as the read-write set identifier of the processing result is determined as a candidate sub-queue.

[0219] Optionally, taking subqueues as units, the read-write set identifier corresponding to each subqueue is compared with the read-write set identifier of the processing result to obtain a candidate subqueue.

[0220] For example, referring to Figure 14 , the second-type write queue 1301 includes four subqueues. The first subqueue corresponds to read-write sets key 1 through key 10, and the corresponding read-write set key at each position is different. The second and third subqueues also correspond to read-write sets key 1 through key 10, respectively. The fourth subqueue corresponds to read-write sets key 1 through key 6. If the read-write set identifier of the processing result to be written is any of read-write sets key 7 through key 10, the fourth subqueue can be determined as a candidate subqueue.

[0221] (2) The first candidate subqueue in the candidate subqueues is determined as the target subqueue.

[0222] Optionally, if the number of candidate subqueues is 1, that candidate subqueue can be directly determined as the target subqueue. If the number of candidate subqueues is 2 or greater, the first candidate subqueue in the candidate subqueues can be determined as the target subqueue. The target subqueue is the subqueue into which the processing results are to be written. For example, referring to FIG14 , the fourth subqueue can be directly determined as the target subqueue.

[0223] (3) Determine the write position of the processing result in the target subqueue according to the read-write set identifier of the processing result, wherein the processing results in the subqueue are arranged in ascending order according to the read-write set identifier.

[0224] Optionally, the read-write set identifier of the processing result is compared with the read-write set identifiers of each processing result in the target sub-queue. If the read-write set identifier of the processing result is smaller than the read-write set identifier of the first processing result in the target sub-queue, the first position in the target sub-queue is determined as the write position of the processing result; if the read-write set identifier of the processing result is smaller than the read-write set identifier of the nth processing result in the target sub-queue, and greater than the read-write set identifier of the n-1th processing result, the position corresponding to the nth processing result is determined as the write position of the processing result, where n is an integer greater than 1.

[0225] For example, referring to FIG14 , if the read-write set identifier of the processing result to be written is read-write set key7 , the position after the processing result with the read-write set identifier of read-write set key6 can be determined as the write position.

[0226] Optionally, each processing result after the write position in the target sub-queue, as well as the original processing result at the write position, can be moved back one position in turn (i.e., the storage address is adaptively changed) to reserve a write position for the above processing results. This embodiment of the present application is not limited to this.

[0227] For example, referring to Figure 14, if the read-write set corresponding to the fifth position in the fourth sub-queue is identified as read-write set key7, and the read-write set of the processing result to be written is identified as read-write set key6, then the original processing result at the fifth position is moved to the sixth position, and the fifth position is determined as the write position.

[0228] In one example, if each position in each subqueue corresponds one-to-one with a read-write set identifier, the position corresponding to the read-write set identifier can be directly determined as the write position. Referring to Figure 14, if the read-write set identifier of the processing result to be written is read-write set key8, the eighth position in the fourth subqueue can be determined as the write position, but this embodiment of the application is not limited to this.

[0229] The embodiment of the present application does not limit the sorting method of the various processing results in the sub-queue. The various processing results in the sub-queue can also be arranged in descending order according to the read-write set identifier; the various processing results in the sub-queue can also have no arrangement order, which is conducive to reducing the workload of writing the processing results, thereby improving the transmission efficiency of the processing results.

[0230] (4) The write position of the processing result in the target sub-queue is determined to be the corresponding write position of the processing result in the second type write queue.

[0231] For example, referring to FIG. 14 , the write position of the processing result in the fourth sub-queue is determined to be the corresponding write position of the processing result in the second-type write queue 1301 .

[0232] For the second-type write queue, which includes multiple subqueues, this approach further optimizes the storage and arrangement of processing results within the second-type write queue, by identifying candidate and target subqueues and then arranging them in ascending order of read-write set identifiers. This allows for a more orderly distribution of processing results across subqueues for different read-write sets, reducing read-write lock conflicts, improving result processing efficiency, and enhancing the stability and performance of the blockchain system.

[0233] 3. Write the processing results to the second type of write queue based on the write position.

[0234] Optionally, the processing result is written to the write location to write the processing result to the second type write queue. In the embodiment of the present application, the sub-queue arranged at the front is filled first so that when the second type read queue is emptied, the second type read queue is replaced to read the processing result.

[0235] In the above embodiment, the read-write set identifier of the processing result is obtained and the write position of the processing result in the second type of write queue is determined based on the identifier. This allows the processing results to be reasonably distributed in the second type of write queue according to the read-write set identifier, avoiding frequent competition between different processing results for the same read-write set, ensuring the efficiency and stability of the processing result writing, and thus improving the overall efficiency of the blockchain system in processing transaction information and generating new blocks.

[0236] In one example, when there is no candidate sub-queue in the second-type write queue, a new sub-queue is added to the tail of the second-type write queue; and the processing result is written to the head of the new sub-queue.

[0237] In this embodiment, if no candidate subqueues exist in the second-type write queue, a new subqueue is added to the end of the queue, and the processing results are written to the head of the new subqueue. This approach ensures that the read-write set identifiers of each subqueue are as unique as possible, avoiding read-write lock contention, improving the efficiency of processing results, and ensuring that the blockchain system can efficiently process large amounts of transaction information.

[0238] For example, referring to Figure 14, if the read-write set identifier of the processing result to be written is any one of read-write set key1 to read-write set key6, a new subqueue can be added after the fourth subqueue as a candidate subqueue, and the processing result can be directly written to the head of the new subqueue. By adding a new subqueue in this way, the read-write set identifiers in each subqueue can be made different as much as possible.

[0239] In one example, when the processing results in the second type of read queue are cleared, the embodiment of the present application may further include the following content:

[0240] 1. Move the second-class read queue to the end of the second-class write queue, and change the second-class read queue to a new subqueue to obtain a new second-class write queue.

[0241] Moving the second-class read queue to the end of the second-class write queue means adding the second-class read queue after the last subqueue in the second-class write queue and connecting it to the last subqueue. The new second-class write queue is used by the virtual machine engine to write processing results. If the first-class read queue after the move (i.e., the new subqueue) is the target subqueue, the processing results can be written to the moved first-class read queue.

[0242] Optionally, after moving the second-type read queue to the end of the second-type write queue, a write lock can be added to the second-type read queue to convert it into a new sub-queue, thereby obtaining a new second-type write queue. The new second-type write queue is used for the blockchain node's virtual machine engine to write processing results.

[0243] The processing results in the second type read queue are cleared, which means that all processing results in the second type read queue are read by the scheduling module. After the processing results in the second type read queue are read by the scheduling module, the virtual machine engine automatically deletes the processing results to make room.

[0244] 2. Change the first subqueue in the second type read queue to a new second type read queue.

[0245] Optionally, the first subqueue is disconnected from the second subqueue in the second-type write queue and the write lock of the first subqueue is released, thereby changing the first subqueue to a new second-type read queue. The new second-type read queue is used for the scheduling module to read the processing results. In other words, the scheduling module will switch to reading the processing results from the new second-type read queue.

[0246] In this embodiment, when the processing results in the second-class read queue are cleared, a switch operation is performed between the subqueue and the second-class read queue. Specifically, the second-class read queue is moved to the end of the second-class write queue and becomes a new subqueue. Simultaneously, the first subqueue in the second-class read queue is changed to the new second-class read queue. This switching method further helps avoid read-write lock contention, allowing write operations to be performed in the new second-class write queue and read operations to be performed in the new second-class read queue, ensuring that the transmission of processing results is not disrupted. Furthermore, this mechanism significantly improves the transmission efficiency of processing results, enabling blockchain nodes to continuously and efficiently process and transmit processing results, ensuring the smooth and stable flow of transaction processing results within the blockchain system, and further enhancing the performance and reliability of the entire blockchain system.

[0247] Optionally, during the switching process between the subqueue and the second-type read queue, all write and read operations on the processing results are prohibited to avoid errors in the transmission of the processing results. The switching process between the subqueue in the second-type write queue and the second-type read queue is the same as the switching process between the subqueue in the first-type write queue and the first-type read queue described above. For any content not described in the embodiments of this application, please refer to the above embodiments and will not be repeated here.

[0248] In one example, after a batch processing result (i.e., the processing result of all transaction information corresponding to a new block) is transmitted, the result queue can retain a sub-queue (i.e., restore to the initial state) to transmit the next batch processing result, which helps reduce the result queue's occupancy of transmission resources.

[0249] In one example, the second-type read queue can also include a small number of sub-queues, such as two or three. This helps reduce the frequency of switching between the sub-queues and the second-type read queue, thereby reducing the workload of managing the result queue. At the same time, it can ensure stable reading of processing results and reduce reading wait time, thereby improving the efficiency of reading processing results.

[0250] The scheduling module is used to package multiple processed transaction information into a new block, and send the new block and processing results to the consensus module to achieve consensus on the new block and processing results.

[0251] In summary, by adopting the technical solution provided in the embodiments of the present application, in the process of transmitting transaction information in the blockchain node, by setting the transaction queue into two types of queues: a write queue is used to write transaction information, and a read queue is used to read transaction information, and the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information, and the read queue is not constrained by the lock, thereby avoiding the read operation on the transaction information being affected by the write operation on the transaction information, and also avoiding the influence of the write operation on the read operation on the transaction information, effectively improving the efficiency of the write operation on the transaction information and the efficiency of the read operation on the transaction information, thereby improving the transmission efficiency of the transaction information in the blockchain node, and then improving the processing efficiency of the transaction information in the blockchain node.

[0252] In addition, in the process of transmitting the processing results in the blockchain node, the result queue is set as two types of queues: the write queue is used to write the processing results, and the read queue is used to read the processing results. The write queue is constrained by the write lock, thereby ensuring the synchronization consistency of the processing results. The read queue is not constrained by the lock, avoiding the read operation on the processing result being affected by the write operation on the processing result, and also avoiding the write operation on the processing result being affected by the read operation on the processing result. It effectively improves the efficiency of the write operation on the processing result and the efficiency of the read operation on the processing result, thereby improving the transmission efficiency of the processing result in the blockchain node, and then improving the processing efficiency of the processing result in the blockchain node.

[0253] The following will describe the interaction process between the transaction pool module, the virtual machine engine, and the scheduling module. For matters not described in the embodiments of this application, please refer to the above embodiments.

[0254] 1. The transaction pool module is used to receive the transaction information sending request sent by the scheduling module. The transaction information sending request is used to request the transaction pool module to start sending transaction information.

[0255] 2. The transaction pool module is configured to determine, in response to a transaction information sending request, multiple transaction information stored in the transaction pool module.

[0256] 3. A transaction pool module, configured to write transaction information into a first-class write queue when the transaction queue used to transmit transaction information includes a first-class read queue and a first-class write queue. The first-class write queue is subject to a write lock constraint. Under the write lock constraint, the first-class write queue only allows a single thread to perform write operations on transaction information in multiple transaction information at the same time. The first-class read queue is not subject to the lock constraint.

[0257] In one example, the transaction pool module is further used to obtain the contract name and arrival time of the transaction information, where the contract name refers to the name of the smart contract used to process transaction information, and the arrival time refers to the time when the transaction information arrives at the transaction pool module; based on the contract name of the transaction information, the write area corresponding to the transaction information in the first type of write queue is determined, and the contract name of the transaction information in the write area is the same as the contract name of the transaction information; based on the arrival time of the transaction information, the write position of the transaction information is determined from the write area, and the transaction information in the write area is arranged in order from earliest to latest according to the arrival time; based on the write position, the transaction information is written to the first type of write queue.

[0258] In one example, the transaction pool module is further used to obtain the number of transactions in each transaction group in the first-category write queue. The transaction group is clustered based on the contract name, and the transaction number is used to indicate the amount of transaction information used for transaction processing in the transaction group. The transaction groups are sorted in descending order of the transaction number to obtain an adjusted first-category write queue.

[0259] In one example, the transaction pool module is also used to obtain the earliest arrival time of each transaction group in the first-category write queue. The transaction group is clustered based on the contract name. The earliest arrival time refers to the earliest arrival time corresponding to each transaction information used for transaction processing in the transaction group. The transaction groups are sorted in descending order according to the earliest arrival time to obtain an adjusted first-category write queue.

[0260] In one example, the transaction pool module is further configured to write the transaction information after the last transaction information in the first type of write queue if there is no transaction information with the same contract name as the transaction information in the first type of write queue.

[0261] In one example, the first-class write queue includes at least one sub-queue, and each sub-queue is connected end to end in sequence; the transaction pool module is further used to add a new sub-queue to the tail of the first-class write queue when at least one sub-queue is filled, and the head of the new sub-queue is connected to the tail of the first-class write queue.

[0262] In one example, the transaction queue in the initial state includes a first-class read-write queue. The first-class read-write queue is subject to a read-write lock constraint. The first-class read-write queue under the read-write lock constraint allows only a single thread to perform write operations at the same time, and allows multiple threads to perform read operations in parallel at the same time; the transaction pool module is also used to write transaction information into the first-class read-write queue; when the first-class read-write queue is filled, the first-class read-write queue is changed to the first-class read queue, and the first-class write queue is added after the first-class read queue. The first-class write queue is not connected to the first-class read queue.

[0263] In one example, the transaction pool module is further used to move the first-class read queue to the tail of the first-class write queue and change the first-class read queue into a new sub-queue to obtain a new first-class write queue when the transaction information in the first-class read queue is cleared; change the first sub-queue in the first-class read queue into a new first-class read queue; wherein the new first-class read queue is used by the virtual machine engine to obtain transaction information, and the new first-class write queue is used by the transaction pool module to write transaction information.

[0264] 4. A virtual machine engine is configured to read multiple transaction information from the first type of read queue, perform transaction processing on the multiple transaction information, and obtain processing results corresponding to the multiple transaction information.

[0265] 5. The virtual machine engine is used to send multiple transaction information and corresponding processing results of the multiple transaction information to the scheduling module.

[0266] In one example, the virtual machine engine is also used to send multiple transaction information after transaction processing to the scheduling module in the form of a transaction queue; when the result queue used to transmit the processing result includes a second-type read queue and a second-type write queue, the processing result is written to the second-type write queue, and the second-type write queue is subject to a write lock constraint. The second-type write queue under the write lock constraint only allows a single thread to perform a write operation on the processing result at the same time. The second-type read queue is used for the scheduling module to read the processing result, and the second-type write queue allows multiple threads to perform read operations in parallel at the same time.

[0267] In one example, the virtual machine engine is further used to obtain a read-write set identifier of a processing result after transaction processing, where the read-write set identifier is used to identify a read-write set of transaction information corresponding to the processing result, and the read-write set is used to record the transaction information corresponding to the processing result, and the access and modification of the status data of the blockchain system where the blockchain node is located; based on the read-write set identifier of the processing result, determine the write position corresponding to the processing result in the second type of write queue; and write the processing result to the second type of write queue based on the write position.

[0268] In one example, the above-mentioned second-category write queue includes at least one sub-queue, and each sub-queue is connected end to end in sequence; the virtual machine engine is also used to, for each sub-queue, determine a sub-queue that does not have a read-write set identifier that is the same as the read-write set identifier of the processing result as a candidate sub-queue; determine the first candidate sub-queue in the candidate sub-queue as the target sub-queue; determine the write position of the processing result in the target sub-queue based on the read-write set identifier of the processing result, wherein the individual processing results in the sub-queue are arranged in ascending order of the read-write set identifier; and determine the write position of the processing result in the target sub-queue as the corresponding write position of the processing result in the second-category write queue.

[0269] In one example, the virtual machine engine is further configured to add a new subqueue to the tail of the second type write queue if there is no candidate subqueue in the second type write queue; and write the processing result to the head of the new subqueue.

[0270] In one example, the result queue in the initial state includes a second-class read-write queue, which is subject to a read-write lock constraint. The second-class read-write queue under the read-write lock constraint only allows a single thread to perform write operations at the same time, and allows multiple threads to perform read operations in parallel at the same time; the virtual machine engine is also used to write the processing results into the second-class read-write queue; when the second-class read-write queue is full, the second-class read-write queue is changed to a second-class read queue, and a second-class write queue is added after the second-class read queue, and the second-class write queue is not connected to the second-class read queue.

[0271] In one example, the virtual machine engine is further used to move the second-class read queue to the tail of the second-class write queue and change the second-class read queue into a new subqueue to obtain a new second-class write queue when the processing results in the second-class read queue are cleared; change the first subqueue in the second-class read queue into the new second-class read queue; wherein the new second-class read queue is used for the scheduling module to read the processing results, and the new second-class write queue is used for the virtual machine engine of the blockchain node to write the processing results.

[0272] 6. Scheduling module, used to package multiple transaction information into a new block.

[0273] In some embodiments, referring to FIG15 , the complete transaction processing process of a new block may include the following:

[0274] 1. The user initiates a transaction request through the client.

[0275] The transaction request is used to request the execution of a transaction, and the client generates transaction data according to the transaction request.

[0276] 2. The user signs the transaction information corresponding to the transaction request.

[0277] The user can complete the signature of the transaction information through the client, and the client can generate signature data based on the user's signature.

[0278] 3. The user sends the transaction data and signature data to the blockchain node.

[0279] Optionally, the user can send the transaction data and signature data together to the blockchain node connected to the client through the client.

[0280] 4. The blockchain node receives the transaction data and signature data.

[0281] Blockchain nodes can receive transaction data and signature data through the network module.

[0282] 5. Blockchain nodes perform certificate and signature verification.

[0283] The blockchain node can verify the certificate and signature of the transaction data through the verification module. If the certificate and signature verification pass, go to step 7. If the certificate and signature verification fail, go to step 6.

[0284] 6. Return the verification failure result to the client and end.

[0285] 7. Blockchain nodes perform permission verification.

[0286] The blockchain node can verify the permissions of the transaction data through the verification module. If the permission verification passes, go to step 9. If not, go to step 8.

[0287] 8. Return the result of failed permission verification to the client and end.

[0288] 9. Put the transaction data into the transaction pool module.

[0289] 10. The blockchain node prepares to generate a new block.

[0290] The blockchain node can prepare the new blocks to be generated based on the scheduling module, such as preparing the block header and block body for the new block. This blockchain node can be called a master node.

[0291] 11. The scheduling module sends a transaction information sending request to the transaction pool module.

[0292] The transaction information sending request is used to request the transaction pool module in the blockchain node to start sending multiple transaction information to be packaged into a new block.

[0293] 12. The transaction pool module adds transaction information to the transaction queue.

[0294] The transaction pool module may write the above-mentioned multiple transaction information into the transaction queue in sequence through the transaction queue sender.

[0295] 13. Check whether the queue number of the transaction queue is 1.

[0296] If the queue number of the transaction queue is 1, go to 14; if the queue number of the transaction queue is not 1, go to 17.

[0297] 14. Identify the transaction queue as the first-class read-write queue.

[0298] That is, the transaction pool module sends transaction information, and the virtual machine engine reads transaction information, all in this first-class read-write queue. Both read and write operations on transaction information require locking (such as a read-write lock).

[0299] 15. The transaction pool module obtains the write lock of the first-class read-write queue.

[0300] 16. The transaction pool module puts the transaction information into the transaction queue and goes to 20.

[0301] 17. Identify the transaction queues as the first-class read queue and the first-class write queue.

[0302] The first type of read queue is used by the virtual machine engine to read transaction information, and the first type of write queue is used by the transaction pool module to write transaction information. The first type of write queue is subject to write lock constraints, and the first type of read queue is not subject to lock constraints.

[0303] The sub-queues in the first write queue are connected end to end. The first sorting rule is based on the contract name of the transaction information, and the contract group with the largest number of transactions is prioritized to the front of the first write queue to avoid frequent switching of smart contracts by the virtual machine engine. The second sorting rule is based on the arrival time of the transaction information, and the transaction information with the earliest arrival time is prioritized to the front of the contract group to ensure timely processing of the transaction information.

[0304] 18. The transaction pool module acquires the write lock of the first type write queue.

[0305] 19. The transaction pool module writes the transaction information into the first type write queue.

[0306] The transaction pool module can write transaction information into the first type write queue through the transaction queue sender, and the first type write queue automatically sorts the written transaction information.

[0307] 20. The virtual machine engine acquires a read lock.

[0308] For the first type of read / write queue, the virtual machine engine obtains a read lock of the first type of read / write queue to read transaction information for transaction processing.

[0309] 21. The virtual machine engine reads the transaction information and performs transaction processing on the transaction information to obtain the processing result.

[0310] When the VM engine attempts to read transaction information from the first-class read / write queue, if it detects that another writer thread is already holding the read lock, it waits for the other writer thread to release the read lock. After the other writer thread releases the read lock, the VM engine can seize the read lock and read the transaction information from the first-class read / write queue. Because the first-class read queue is not subject to lock constraints, the VM engine can read transaction information directly from the first-class read queue through the transaction queue reader.

[0311] 22. The virtual machine engine writes the processing results to the result queue.

[0312] The virtual machine engine writes processing results to the second type of write queue in the result queue through the result queue sender. The result queue's data structure, read-write locks, and usage are identical to those of the transaction queue, but the sorting rules are different. The result queue is primarily sorted based on the read-write set key of the transaction information. Specifically, each subqueue in the second type of write queue is guaranteed to have a different read-write set key, thereby avoiding time-consuming lock contention.

[0313] 23. The scheduling module reads the processing results from the result queue.

[0314] The scheduling module can read the processing result of the transaction information from the second type of read queue in the result queue through the result queue reader.

[0315] 24. The scheduling module puts the processing results into the consensus block.

[0316] 25. When the above multiple transaction information processing is completed, the master node sends the new block to all slave nodes for consensus.

[0317] When the above-mentioned multiple transaction information is processed, the scheduling module can package the processed multiple transaction information into a new block.

[0318] 26. Check whether the slave nodes have reached consensus.

[0319] If the consensus is reached, go to step 27; if the consensus is not reached, end.

[0320] 27. All blockchain nodes store the new block in the blockchain.

[0321] 28. All blockchain nodes store state data in the state database.

[0322] The status data may be updated based on the processing results.

[0323] In some embodiments, the transaction queue and result queue described above can be collectively referred to as bidirectional, multi-group, reorderable queues. The first and second types of write queues can be collectively referred to as write queues, and the first and second types of read queues can be collectively referred to as read queues. Referring to FIG16 , using the example of a virtual machine engine acquiring transaction information, the dynamic switching process between the write and read queues can include the following.

[0324] 1. The virtual machine engine reads the read queue in the bidirectional multi-group sortable queue.

[0325] 2. Check whether the read queue is empty.

[0326] That is, check whether the read queue is empty. If the read queue is empty, go to 3; if the read queue is not empty, go to 1.

[0327] 3. Whether the write queue in the bidirectional multi-group sortable queue is empty.

[0328] If the write queue is empty, go to 4; if the write queue is not empty, go to 6.

[0329] 4. Check whether all transaction information has been completed.

[0330] If all the transaction information is executed, the process ends. If not all the transaction information is executed, go to step 5. The transaction information is packaged into a new block.

[0331] 5. Wait for new transaction information to appear in the bidirectional multi-group sortable queue.

[0332] 6. The queue starts to lock, prohibiting all write and read operations.

[0333] That is, when it is detected that the read queue is emptied, the conversion between the read queue and the write queue can be started. At this time, neither the virtual machine engine nor the transaction pool module can operate on the bidirectional multi-group sortable queue.

[0334] 7. The queues start rotating, switching the read queue to the last subqueue of the write queue, and switching the first subqueue of the write queue to the read queue.

[0335] 8. Check whether the total number of queues is 1.

[0336] The total number of queues refers to the total number of subqueues in a bidirectional, multi-group, sortable queue. If the total number of queues is 1, proceed to step 9. If the total number of queues is not 1, proceed to step 10.

[0337] 9. Determine the bidirectional multi-group sortable queue as a read-write queue and go to 11.

[0338] That is, the bidirectional multi-group sortable queue is subject to read-write lock constraints, which can be used to write transaction information and read transaction information.

[0339] 10. Continue to use the read-write separation mode to transmit transaction information.

[0340] That is, except for one read queue, the remaining queues are all write queues, and the remaining queues are connected end to end and are subject to write lock constraints, while the read queue is not subject to lock constraints.

[0341] 11. The queue is unlocked and the process goes to step 1.

[0342] This means that both the virtual machine engine and the transaction pool module can now operate on bidirectional, multi-group, sortable queues. End.

[0343] In some embodiments, the technical solutions provided by the embodiments of the present application can be applied in at least the following scenarios:

[0344] 1. High-performance financial transaction processing: Financial transaction processing places high demands on real-time performance, security, and throughput. The technical solutions provided by the embodiments of this application enable blockchain systems to process transaction information more efficiently, thereby improving transaction information processing performance, reducing switching costs during smart contract runtime, and mitigating read-write lock conflicts. Therefore, the technical solutions provided by the embodiments of this application are ideally suited for high-performance financial transaction processing scenarios, such as securities transactions, payment settlement, and cross-border remittances.

[0345] 2. Supply Chain Finance and Logistics Management: Supply Chain Finance and Logistics Management involve multiple parties and place high demands on data consistency and real-time performance. The technical solutions provided by the embodiments of this application can ensure efficient and real-time transaction processing, which is conducive to improving the operational efficiency of the entire supply chain finance and logistics management system. Application scenarios include supply chain financing, cargo tracking, warehouse management, etc.

[0346] 3. IoT Data Processing: IoT devices generate enormous amounts of data, placing high demands on data processing capabilities. The technical solutions provided in the embodiments of this application improve the performance of blockchain systems in IoT data processing scenarios by decoupling read / write locks for bidirectional, multiple-group sortable queues (such as transaction queues and result queues), implementing a dynamic rotation mechanism, and optimizing sorting strategies. Application scenarios include smart homes, smart transportation, and smart factories.

[0347] 4. Cross-industry data sharing and privacy protection: Cross-industry data sharing and privacy protection involve multi-party data exchange, placing high demands on data processing capabilities and data security. The technical solutions provided in the embodiments of this application can improve the performance of blockchain systems in handling cross-industry data sharing and privacy protection scenarios, while ensuring data consistency and security. Application scenarios include medical data sharing, credit data sharing, and intellectual property protection.

[0348] In summary, by adopting the technical solution provided in the embodiments of the present application, in the process of transmitting transaction information in the blockchain node, by setting the transaction queue into two types of queues: a write queue is used to write transaction information, and a read queue is used to read transaction information, and the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information, and the read queue is not constrained by the lock, thereby avoiding the read operation on the transaction information being affected by the write operation on the transaction information, and also avoiding the influence of the write operation on the read operation on the transaction information, effectively improving the efficiency of the write operation on the transaction information and the efficiency of the read operation on the transaction information, thereby improving the transmission efficiency of the transaction information in the blockchain node, and then improving the processing efficiency of the transaction information in the blockchain node.

[0349] In addition, in the process of transmitting the processing results in the blockchain node, the result queue is set as two types of queues: the write queue is used to write the processing results, and the read queue is used to read the processing results. The write queue is constrained by the write lock, thereby ensuring the synchronization consistency of the processing results. The read queue is not constrained by the lock, avoiding the read operation on the processing result being affected by the write operation on the processing result, and also avoiding the write operation on the processing result being affected by the read operation on the processing result. It effectively improves the efficiency of the write operation on the processing result and the efficiency of the read operation on the processing result, thereby improving the transmission efficiency of the processing result in the blockchain node, and then improving the processing efficiency of the processing result in the blockchain node.

[0350] The blockchain node transaction information processing method of this application involves three main modules: scheduling module, transaction pool module and virtual machine engine. Its workflow is as follows:

[0351] The scheduling module is triggered. The scheduling module determines the timing of generating a new block based on preset rules (such as time interval or number of transactions), generates a transaction information sending request, and tells the transaction pool module to start sending transaction information.

[0352] The transaction pool module processes transaction information. Determining pending transactions: After receiving a request, the transaction pool module determines the multiple transactions stored in the transaction pool based on the request identifier, creation time, or current packaging time period. Writing to the transaction queue: Initially, the transaction queue consists of a first-class read-write queue, which is constrained by a read-write lock. The transaction pool module calls the write thread to write transaction information sequentially. When the first-class read-write queue is full, it is changed to a first-class read queue, and a first-class write queue, which is constrained by a write lock, is added to it. Transaction information sorting: The transaction pool module obtains the contract name and arrival time of the transaction information and determines the write region based on the contract name, ensuring that transactions within the same region are processed by the same smart contract. The module then determines the write location within the write region based on the arrival time, prioritizing transactions that arrive earlier. Transaction groups can also be sorted based on the number of transactions in a group or the earliest arrival time. Dynamic queue adjustment: When a subqueue of the first-class write queue is full, a new subqueue is added to the end. When transaction information in the first-class read queue is cleared, it is moved to the end of the first-class write queue to become a new subqueue. Simultaneously, the first subqueue of the first-class write queue becomes the new first-class read queue.

[0353] The virtual machine engine processes transactions. Reading transaction information: Since the first type of read queue is not subject to lock constraints, the virtual machine engine can use threads in parallel to read transaction information from it. Executing smart contract processing: Performing transaction processing on the read transaction information to obtain the processing results. Transmitting transaction information and results: Sending the processed transaction information to the scheduling module in the form of a transaction queue; for the processing results, when the result queue includes the second type of read queue and the second type of write queue, write them to the second type of write queue subject to the write lock constraint. Result queue management: The virtual machine engine obtains the read-write set identifier of the processing result, determines its write position in the second type of write queue, and makes the read-write set identifiers of the processing results in the subqueue as different as possible to reduce contention for read-write locks. When there is no suitable candidate subqueue in the second type of write queue, a new subqueue is added to the tail; when the processing results in the second type of read queue are cleared, the queue is switched, and the operation is similar to the transaction queue.

[0354] The scheduling module packages new blocks. The scheduling module receives multiple transaction information and processing results sent by the virtual machine engine, packages the transaction information into a new block based on the processing results, and then sends the new block and processing results to the consensus module. After reaching consensus, the blockchain and status data are updated.

[0355] The effects of this application are as follows:

[0356] Improved transaction information transmission efficiency: A read-write separation queue design is employed. The transaction queue is divided into a first-class write queue, subject to a write lock, and a first-class read queue, free of locks. The result queue is divided into a second-class write queue, subject to a write lock, and a second-class read queue, free of locks. This design avoids the mutual impact of read and write operations. The virtual machine engine can read the lock-free read queue in parallel, while the transaction pool module and virtual machine engine only need to hold the write lock to write information sequentially. This improves the read and write efficiency of transaction information and processing results, thereby enhancing the transmission efficiency within blockchain nodes.

[0357] Reduce smart contract switching costs: Transaction information is sorted by contract name and arrival time. Transactions in the same write area are processed by the same smart contract, which reduces the frequent switching of smart contracts, reduces switching costs and response time, and improves the efficiency of transaction information processing.

[0358] Reduce read-write lock conflicts: By rationally designing the queue structure and sorting rules, such as sorting the result queue by read-write set identifier, the read-write set identifiers of the processing results in the sub-queues are made as different as possible. This avoids the read-write lock contention caused by accessing the same read-write set, improves the processing efficiency of the processing results and the transaction processing performance of the blockchain system.

[0359] Optimized queue management: The queue structure is simple in the initial state. As the number of transactions or processing results increases, it is dynamically adjusted to a bidirectional multi-group sortable queue. The sub-queue and read queue are switched according to the queue status. This can reduce the management workload under low load and improve transmission efficiency under high load, realizing flexible optimization of the queue structure according to the load.

[0360] Enhanced system stability and adaptability: Throughout the entire transaction processing process, various modules work together to ensure that the blockchain network can accurately and promptly process large amounts of transaction information and maintain normal network operation. This makes it suitable for a variety of scenarios, including high-performance financial transaction processing, supply chain finance and logistics management, IoT data processing, cross-industry data sharing, and privacy protection.

[0361] Please refer to Figure 17, which is a block diagram of a computer device provided in one embodiment of the present application. The computer device can be implemented as the above-mentioned blockchain node.

[0362] Typically, the computer device 1700 includes a processor 1701 and a memory 1702 .

[0363] The processor 1701 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1701 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), or PLA (Programmable Logic Array). The processor 1701 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1701 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1701 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0364] Memory 1702 may include one or more computer-readable storage media, which may be tangible and non-transitory. Memory 1702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in memory 1702 stores a computer program, which is loaded and executed by processor 1701 to implement the transaction information processing method applied to a blockchain node provided by the above-mentioned various method embodiments.

[0365] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. The computer program is loaded and executed by a processor to implement the transaction information processing method applied to a blockchain node provided by the above-mentioned method embodiments.

[0366] The computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include RAM (Random Access Memory), ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technology, CD-ROM, DVD (Digital Video Disc) or other optical storage, tape cassettes, magnetic tape, disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage media is not limited to the above-mentioned ones.

[0367] An embodiment of the present application also provides a computer program product, which includes a computer program. The computer program is stored in a computer-readable storage medium, and a processor reads and executes the computer program from the computer-readable storage medium to implement the transaction information processing method applied to a blockchain node provided in the above-mentioned method embodiments.

[0368] It should be noted that, in the embodiments of the present application, before collecting the relevant data of the user and during the process of collecting the relevant data of the user, a prompt interface, pop-up window or voice prompt information can be displayed. The prompt interface, pop-up window or voice prompt information is used to remind the user that its relevant data is currently being collected, so that the present application only starts to execute the relevant steps of obtaining the relevant data of the user after obtaining the confirmation operation issued by the user on the prompt interface or pop-up window. Otherwise (that is, when the confirmation operation issued by the user on the prompt interface or pop-up window is not obtained), the relevant steps of obtaining the relevant data of the user are terminated, that is, the relevant data of the user is not obtained. In other words, all user data collected by this application are processed strictly in accordance with the requirements of relevant national laws and regulations. The informed consent or separate consent of the personal information subject is obtained only when the user agrees and authorizes the collection, and the subsequent data use and processing behavior is carried out within the scope of the authorization of the laws and regulations and the personal information subject. The collection, use and processing of relevant user data need to comply with the relevant laws, regulations and standards of the relevant countries and regions. For example, the transaction information involved in this application is obtained with full authorization.

[0369] It should be understood that the term "plurality" used herein refers to two or more. "And / or" describes a relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, or B exists alone. The character " / " generally indicates an "or" relationship between the associated objects.

[0370] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent switches, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

[0371] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0372] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A transaction information processing method applied to a blockchain node, characterized in that: The blockchain node includes a scheduling module, a transaction pool module and a virtual machine engine, and the method includes: receiving a transaction information sending request sent by the scheduling module, wherein the transaction information sending request is used to request the transaction pool module to start sending transaction information; In response to the transaction information sending request, determining a plurality of transaction information stored in the transaction pool module; and In a case where a transaction queue for transmitting the multiple transaction information includes a first-type read queue and a first-type write queue, the multiple transaction information is written into the first-type write queue, the first-type write queue is constrained by a write lock, and the first-type write queue under the write lock constraint allows only a single thread to perform a write operation on transaction information from the multiple transaction information at the same time, while the first-type read queue allows multiple threads to perform a read operation on transaction information from the multiple transaction information in parallel at the same time. The first-type read queue is used for the virtual machine engine to read transaction information from the multiple transaction information, perform transaction processing on the multiple transaction information to obtain processing results, and the multiple transaction information and the processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results.

2. The method according to claim 1, characterized in that Writing the plurality of transaction information into the first type write queue comprises: Obtaining the contract name and arrival time of the transaction information, where the contract name refers to the name of the smart contract used to process the transaction information, and the arrival time refers to the time when the transaction information arrives at the transaction pool module; Determining, based on the contract name of the transaction information, a write area corresponding to the transaction information in the first type of write queue, wherein the contract name of the transaction information in the write area is the same as the contract name of the transaction information; determining a write position of the transaction information in the write area according to the arrival time of the transaction information, and arranging the transaction information in the write area in descending order of the arrival time; The transaction information is written into the first-type write queue according to the write position.

3. The method according to claim 2, characterized in that After writing the transaction information to the first type of write queue according to the write position, the method further includes: Obtaining the number of transactions in each transaction group in the first type of write queue, where the transaction groups are clustered based on the contract names, and the transaction number indicates the number of transaction information in the transaction group; The transaction groups are sorted in descending order of the transaction quantity to obtain the adjusted first-type write queue.

4. The method according to claim 2, characterized in that After writing the transaction information to the first type of write queue according to the write position, the method further includes: Obtaining the earliest arrival time of each transaction group in the first type of write queue, where the transaction group is clustered based on the contract name, and the earliest arrival time refers to the earliest arrival time corresponding to each transaction information in the transaction group; The transaction groups are sorted in descending order of the earliest arrival time to obtain an adjusted first-type write queue.

5. The method according to any one of claims 2 to 4, characterized in that: The method further comprises: If there is no transaction information with the same contract name as the transaction information in the first type write queue, the transaction information is written after the last transaction information in the first type write queue.

6. The method according to any one of claims 1 to 5, characterized in that The first type of write queue includes at least one subqueue, and each subqueue is connected end to end in sequence; the method further includes: When the at least one subqueue is full, a new subqueue is added to the tail of the first-type write queue, and the head of the new subqueue is connected to the tail of the first-type write queue.

7. The method according to any one of claims 1 to 6, characterized in that The transaction queue in the initial state includes a first-class read-write queue, which is subject to a read-write lock. The first-class read-write queue under the read-write lock constraint allows only a single thread to perform a write operation at the same time, and allows multiple threads to perform a read operation in parallel at the same time. Before writing the plurality of transaction information into the first type write queue, the method further includes: Writing the plurality of transaction information into the first type read-write queue; When the first type read and write queue is full, the first type read and write queue is changed to the first type read queue, and the first type write queue is added after the first type read queue. The first type write queue is not connected to the first type read queue.

8. The method according to any one of claims 1 to 7, characterized in that After writing the plurality of transaction information into the first type write queue, the method further includes: When transaction information in the first-type read queue is cleared, the first-type read queue is moved to the end of the first-type write queue, and the first-type read queue is changed into a new sub-queue to obtain a new first-type write queue; Changing the first subqueue in the first-class read queue to a new first-class read queue; The new first-type read queue is used by the virtual machine engine to obtain the transaction information, and the new first-type write queue is used by the transaction pool module to write the transaction information.

9. A transaction information processing method applied to a blockchain node, characterized in that: The blockchain node includes a scheduling module, a transaction pool module and a virtual machine engine, and the method includes: In a case where the transaction queue for transmitting transaction information includes a first-type read queue and a first-type write queue, multiple transaction information is read from the first-type read queue, the first-type read queue allows multiple threads to concurrently perform read operations on transaction information from the multiple transaction information at the same time, the multiple transaction information in the first-type write queue is written by the transaction pool module, the first-type write queue is constrained by a write lock, and under the write lock constraint, the first-type write queue only allows a single thread to perform write operations on transaction information from the multiple transaction information at the same time; Performing transaction processing on the plurality of transaction information to obtain processing results corresponding to the plurality of transaction information; and The multiple transaction information and the processing results are sent to the scheduling module, where the multiple transaction information and the processing results are used to instruct the scheduling module to package the multiple transaction information into a new block based on the processing results.

10. The method according to claim 9, characterized in that The sending the plurality of transaction information and the processing results to the scheduling module includes: Sending the plurality of transaction information to the scheduling module in the form of the transaction queue; In the case where the result queue used to transmit the processing result includes a second-type read queue and a second-type write queue, the processing result is written into the second-type write queue, the second-type write queue is subject to a write lock constraint, and the second-type write queue under the write lock constraint only allows a single thread to perform a write operation on the processing result at the same time. The second-type read queue is used by the scheduling module to obtain the processing result, and the second-type read queue allows multiple threads to perform read operations in parallel at the same time.

11. The method according to claim 10, characterized in that Writing the processing result into the second-type write queue includes: Obtaining a read-write set identifier for the processing result, where the read-write set identifier is used to identify a read-write set of transaction information corresponding to the processing result, and the read-write set is used to record the transaction information corresponding to the processing result, and access and modification of state data of the blockchain system where the blockchain node is located; Determining, according to the read-write set identifier of the processing result, a write position corresponding to the processing result in the second-type write queue; The processing result is written into the second-type write queue according to the write position.

12. The method according to claim 11, characterized in that The second type of write queue includes at least one subqueue, and each subqueue is connected end to end in sequence; The determining, according to the read-write set identifier of the processing result, a write position corresponding to the processing result in the second-type write queue includes: For each of the subqueues, a subqueue having no read / write set identifier identical to the read / write set identifier of the processing result is determined as a candidate subqueue; Determine the first candidate subqueue in the candidate subqueues as the target subqueue; Determining a write position of the processing result in the target subqueue according to the read-write set identifier of the processing result, wherein the processing results in the subqueue are arranged in ascending order of the read-write set identifier; The write position of the processing result in the target sub-queue is determined as the write position corresponding to the processing result in the second-type write queue.

13. The method according to claim 12, characterized in that The method further comprises: If the candidate subqueue does not exist in the second-type write queue, adding a new subqueue at the end of the second-type write queue; The processing result is written into the head of the new sub-queue.

14. The method according to claim 10, characterized in that The result queue in the initial state includes a second-type read-write queue, the second-type read-write queue is constrained by a read-write lock, and the second-type read-write queue under the read-write lock constraint allows only a single thread to perform a write operation at the same time, and allows multiple threads to perform a read operation in parallel at the same time; Before writing the processing result into the second type write queue, the method further includes: Writing the processing result into the second type read-write queue; When the second type read and write queue is full, the second type read and write queue is changed to the second type read queue, and the second type write queue is added after the second type read queue. The second type write queue is not connected to the second type read queue.

15. The method according to claim 10, characterized in that After writing the processing result into the second type write queue, the method further includes: When the processing results in the second-type read queue are cleared, the second-type read queue is moved to the end of the second-type write queue, and the second-type read queue is changed into a new sub-queue to obtain a new second-type write queue; Changing the first subqueue in the second-class read queue to a new second-class read queue; Among them, the new second-type read queue is used by the scheduling module to obtain the processing result, and the new second-type write queue is used by the virtual machine engine of the blockchain node to write the processing result.

16. A blockchain node, characterized in that: The blockchain node includes a transaction pool module, a virtual machine engine and a scheduling module; The transaction pool module is configured to receive a transaction information sending request sent by the scheduling module, wherein the transaction information sending request is used to request the transaction pool module to start sending transaction information; and in response to the transaction information sending request, determine a plurality of transaction information stored by the transaction pool module; In a case where the transaction queue used to transmit the multiple transaction information includes a first-type read queue and a first-type write queue, the multiple transaction information is written into the first-type write queue, the first-type write queue is constrained by a write lock, and the first-type write queue under the write lock constraint allows only a single thread to perform a write operation on transaction information among the multiple transaction information at the same time, while the first-type read queue allows multiple threads to perform a read operation on transaction information among the multiple transaction information in parallel at the same time; The virtual machine engine is configured to read the plurality of transaction information from the first type of read queue; Performing transaction processing on the plurality of transaction information to obtain processing results corresponding to the plurality of transaction information; Sending the plurality of transaction information and the processing results to the scheduling module; The scheduling module is configured to package the plurality of transaction information into a new block based on the processing result.

17. A computer-readable storage medium, characterized in that The storage medium stores a computer program, which is loaded and executed by a processor to implement the transaction information processing method applied to a blockchain node as described in any one of claims 1 to 8, or the transaction information processing method applied to a blockchain node as described in any one of claims 9 to 15.

18. A computer program product, characterized in that The computer program product includes a computer program, which is stored in a computer-readable storage medium. The processor reads and executes the computer program from the computer-readable storage medium to implement the transaction information processing method applied to a blockchain node as described in any one of claims 1 to 8, or the transaction information processing method applied to a blockchain node as described in any one of claims 9 to 15.

Images