WO2025185409A1 - 区块链节点及应用于区块链节点的事务信息处理方法 - Google Patents

区块链节点及应用于区块链节点的事务信息处理方法

Info

Publication number
WO2025185409A1
WO2025185409A1 PCT/CN2025/076884 CN2025076884W WO2025185409A1 WO 2025185409 A1 WO2025185409 A1 WO 2025185409A1 CN 2025076884 W CN2025076884 W CN 2025076884W WO 2025185409 A1 WO2025185409 A1 WO 2025185409A1
Authority
WO
WIPO (PCT)
Prior art keywords
queue
write
transaction information
read
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/076884
Other languages
English (en)
French (fr)
Other versions
WO2025185409A8 (zh
Inventor
卢光宏
蔡志宏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Publication of WO2025185409A1 publication Critical patent/WO2025185409A1/zh
Publication of WO2025185409A8 publication Critical patent/WO2025185409A8/zh
Anticipated expiration legal-status Critical
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/62—Queue scheduling characterised by scheduling criteria
    • H04L47/6295—Queue scheduling characterised by scheduling criteria using multiple queues, one for each individual QoS, connection, flow or priority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms

Definitions

  • 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.
  • the blockchain node 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.
  • 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.
  • a read-write lock is usually added to the transaction information when the transaction information is transmitted.
  • 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.
  • the present application provides a blockchain node and a transaction information processing method applied to the blockchain node.
  • a transaction information processing method applied to a blockchain node wherein the blockchain node includes a scheduling module, a transaction pool module, and a virtual machine engine, and the method includes:
  • 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
  • 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
  • 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.
  • a transaction information processing method applied to a blockchain node wherein the blockchain node includes a scheduling module, a transaction pool module, and a virtual machine engine, and the method includes:
  • 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
  • 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.
  • a 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, 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;
  • 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;
  • the scheduling module is configured to package the plurality of transaction information into a new block based on the processing result.
  • a computer-readable storage medium 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.
  • a computer program product 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.
  • FIG1 is a schematic diagram of an implementation environment of a solution provided by an embodiment of the present application.
  • FIG2 is a schematic diagram of a blockchain node provided by one embodiment of the present application.
  • FIG3 is a schematic diagram of the interaction relationship between various modules in a blockchain node provided by one embodiment of the present application.
  • FIG4 is a flowchart of a transaction information processing method applied to a blockchain node provided by one embodiment of the present application.
  • FIG5 is a schematic diagram of a transaction queue provided by an embodiment of the present application.
  • FIG6 is a flowchart of a method for determining a write location of transaction information provided by one embodiment of the present application.
  • FIG7 is a schematic diagram of a first type of write queue provided by one embodiment of the present application.
  • FIG8 is a schematic diagram of a first type of write queue provided by another embodiment of the present application.
  • 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;
  • FIG11 is a flowchart of a transaction information processing method applied to a blockchain node provided in another embodiment of the present application.
  • FIG12 is a flowchart of a method for transmitting processing results according to an embodiment of the present application.
  • FIG13 is a schematic diagram of a result queue provided by one embodiment of the present application.
  • FIG14 is a schematic diagram of a second type of write queue provided by one embodiment of the present application.
  • FIG15 is a flowchart of a transaction information processing method applied to a blockchain node provided by another embodiment of the present application.
  • 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
  • FIG17 is a structural block diagram of a computer device provided in one embodiment of the present application.
  • 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 cryptographic means to form an unalterable chain (i.e. blockchain). Each block contains transaction records and the hash value of the previous block).
  • 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.
  • the underlying blockchain platform can include processing modules such as user management, basic services, smart contracts, and operation management.
  • 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.
  • the basic service 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.
  • 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.
  • 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.
  • Blockchain is the core data structure in the blockchain system. It is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithm.
  • Blockchain is essentially a decentralized database, a string of data blocks (i.e. blocks) generated by cryptographic methods. Each data block contains information about a batch of network transactions (i.e. transaction information), which is used to verify the validity of its information (anti-counterfeiting) and generate the next block.
  • transaction information i.e. transaction information
  • blockchain can be used to store and manage all confirmed blocks.
  • the blockchain is organized in a chain structure, and each block contains a set of transactions, a block header (including the hash value of the previous block, timestamp and other metadata), and other information.
  • the blockchain provides a public, tamper-proof transaction history for the blockchain system, ensuring the transparency and consistency of the blockchain system.
  • the blockchain can also be called a block ledger.
  • 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.
  • 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.
  • 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.
  • 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.
  • the hash value of the root node is the root hash.
  • transaction information within the main block can be arranged according to the Merkle tree structure to ensure the integrity and security of transaction information.
  • 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.
  • PoW Proof-of-Work
  • the transaction pool is the internal memory space used by blockchain node programs to cache transaction information. Transaction information in the transaction pool has not yet been written to the blockchain ledger (also known as the blockchain). Any transaction in the transaction pool simply indicates that the blockchain node has received the transaction information.
  • the blockchain node extracts a batch of transaction information from the transaction pool and removes it from the transaction pool, using it to form a block.
  • the transaction pool is a data structure in the blockchain system that stores transaction information that has not yet been packaged into a block.
  • the blockchain node When preparing to generate a new block, the blockchain node selects a certain number of transactions from the transaction pool to package.
  • the transaction pool helps improve the processing capacity of the blockchain network and can also serve as a strategy to prioritize transactions with higher fees for packaging, thereby increasing blockchain node revenue.
  • a smart contract is a computer protocol designed to disseminate, 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.
  • a smart contract can be implemented as a program stored on a blockchain that automatically executes when preset conditions are met, such as automatically executing all operations in an agreement or contract. Smart contracts are mainly used to execute transactions and access status data. For example, query the logistics status of the goods purchased by the buyer, 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, but can also execute contracts for processing received information.
  • 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.
  • state data is typically stored in the form of Merkle trees or other encrypted data structures to ensure its integrity and security.
  • state data can be stored in a state database, which can be used to store the entire blockchain system's state data.
  • 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).
  • 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.
  • 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.
  • the master node 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.
  • the slave nodes 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.
  • Figure 1 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.
  • 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.
  • 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).
  • TCP Transmission Control Protocol
  • any machine such as a server or terminal device, can become a blockchain node.
  • Blockchain nodes consist of a hardware layer, a middleware layer, an operating system layer, and an application layer.
  • the blockchain node 101 has at least the functions of transaction information processing, blockchain maintenance, consensus, sending and receiving, calculation, and storage.
  • 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.
  • each blockchain node 101 in the blockchain system 100 includes but are not limited to one of the following:
  • Routing is a basic function of the blockchain node 101, used to achieve communication between blockchain nodes 101.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the result queue sender can also be implemented independently of virtual machine engine 1015, which is not limited in this embodiment of the application.
  • 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.
  • distributed ledger i.e., blockchain
  • 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
  • the state data is responsible for storing state information in the blockchain system, such as account balances and smart contract data.
  • the interaction relationship between the modules in the blockchain node 101 may be as follows:
  • 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.
  • network module 1011 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.
  • transaction pool module 1013 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.
  • 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.
  • FIG 4 is a flowchart of a transaction information processing method applied to a blockchain node provided by one embodiment of the present application.
  • 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.
  • the method can include at least one of the following steps (401-403):
  • 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.
  • 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
  • the result queue reader retrieves transaction processing results from the virtual machine engine.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Step 402 In response to the transaction information sending request, determine a plurality of transaction information stored in the transaction pool module.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • transaction information i.e., executing the transaction
  • a processing result through the corresponding smart contract.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the virtual machine engine 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.
  • 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.
  • 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.
  • all write and read operations on the processing results are prohibited to avoid errors in the transmission of processing results.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the critical section is the code or program fragment used to perform write operations on the first type of write queue.
  • a write lock can be added to the critical section.
  • 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.
  • 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.
  • 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.
  • the first-class write queue 501 is subject to a write lock, while the first-class read queue 502 is not.
  • 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.
  • a reader thread 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a writer thread i.e., the transaction pool module
  • 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.
  • a reader thread i.e., the virtual machine engine
  • 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.
  • 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).
  • the embodiment of the present application may also include the following content:
  • 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.
  • 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.
  • the first-class read/write queue is full when all corresponding locations in the first-class read/write queue are written with transaction information.
  • 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.
  • a write lock is added to the first-class write queue.
  • the first type write queue in an initial state includes only one sub-queue.
  • the first type write queue expands to include multiple sub-queues.
  • 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.
  • 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.
  • 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.
  • 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.
  • the transaction queue management workload can be effectively reduced.
  • switching to a bidirectional multi-group sortable transaction queue can effectively improve the transmission efficiency of transaction information.
  • 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.
  • 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.
  • 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.
  • the write position refers to the position where the transaction information is written in the first-class write queue.
  • step 403 may also include the following sub-steps:
  • 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
  • the arrival time refers to the time when the transaction information arrives at the transaction pool module.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the write area where the target transaction information is located can be determined as the write area corresponding to the transaction information.
  • 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.
  • the transaction pool module 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.
  • 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.
  • 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.
  • 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.
  • 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)
  • the first position in the write area 503 can be determined as the write position of the transaction information 504.
  • 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.
  • each transaction information after the write position and the original transaction information at the write position can be moved back one position in sequence (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.
  • 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 .
  • Step 403d Write the transaction information to the first type of write queue according to the write position.
  • the transaction information is written into the write location to implement writing the transaction information into the first type of write queue.
  • the transaction information 504 can be directly written into the first location in the write area 503 .
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • the embodiment of the present application may further include the following content:
  • 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).
  • 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.
  • 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.
  • the transaction pool module automatically deletes the transaction information to make room.
  • the transaction pool module automatically deletes the transaction information.
  • 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.
  • 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.
  • 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.
  • the first subqueue 505 in the first-class read queue 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a write queue is used to write transaction information
  • a read queue is used to read transaction information
  • the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information
  • 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.
  • Figure 11 is a flowchart of a transaction information processing method applied to a blockchain node according to another embodiment of the present application.
  • 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.
  • this method may include at least one of the following steps (1101-1103):
  • 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.
  • 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.
  • 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 needs to hold a read lock to sequentially write transaction information to the first-class 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.
  • 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.
  • Step 1102 perform transaction processing on the multiple transaction information to obtain processing results corresponding to the multiple transaction information.
  • 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.
  • the same smart contract can be used 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the virtual machine engine can also send transaction information to the scheduling module in a single queue, RPC (Remote Procedure Call Protocol), etc.
  • RPC Remote Procedure Call Protocol
  • a single queue, RPC (Remote Procedure Call Protocol), etc. can also be used for transmission.
  • RPC Remote Procedure Call Protocol
  • the Remote Procedure Call Protocol is a method of transmitting transaction information between the virtual machine engine and the scheduling module, and between the transaction pool module and the virtual machine engine.
  • step 1102 may further include the following sub-steps.
  • Step 1102a Send multiple transaction information to the scheduling module in the form of transaction queues.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • a critical section the code or program fragment used to write to the second type of write queue.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second-type write queue 1301 is subject to a write lock, while the second-type read queue 1302 is not.
  • a writer thread wishes to write a processing result to the second-type write queue 1301
  • the writer thread waits for the other writer thread to release 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.
  • a read thread 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.
  • 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.
  • 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.
  • 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.
  • a write thread i.e., a virtual machine engine
  • the write thread waits for the other write thread/read thread to release 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.
  • a read thread i.e., the scheduling module
  • 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.
  • 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).
  • the embodiment of the present application may also include the following content:
  • 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.
  • 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.
  • 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.
  • 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.
  • a write lock is added to the second type of write queue.
  • 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.
  • 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.
  • 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.
  • 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.
  • multiple subqueues provide the basis for conversion between the second type of read queue and the subqueue.
  • 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.
  • 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.
  • 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.
  • 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.
  • the write position refers to the position where the processing result is written in the second type of write queue.
  • step 1102b may also include the following content:
  • 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.
  • 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.
  • 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.
  • the process of determining the write position corresponding to the processing result in the second type write queue may include the following:
  • 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.
  • 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.
  • 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.
  • the first candidate subqueue in the candidate subqueues is determined as the target subqueue.
  • 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.
  • 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.
  • the position after the processing result with the read-write set identifier of read-write set key6 can be determined as the write position.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • the processing result is written to the write location to write the processing result to the second type write queue.
  • 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.
  • 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.
  • 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.
  • 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.
  • the read-write set identifiers in each subqueue can be made different as much as possible.
  • the embodiment of the present application may further include the following content:
  • 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.
  • 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.
  • 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.
  • the virtual machine engine automatically deletes the processing results to make room.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a write queue is used to write transaction information
  • a read queue is used to read transaction information
  • the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the virtual machine engine is used to send multiple transaction information and corresponding processing results of the multiple transaction information to the scheduling module.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Scheduling module used to package multiple transaction information into a new block.
  • the complete transaction processing process of a new block may include the following:
  • the user initiates a transaction request through the client.
  • the transaction request is used to request the execution of a transaction, and the client generates transaction data according to the transaction request.
  • the user signs the transaction information corresponding to the transaction request.
  • 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.
  • the user sends the transaction data and signature data to the blockchain node.
  • the user can send the transaction data and signature data together to the blockchain node connected to the client through the client.
  • the blockchain node receives the transaction data and signature data.
  • Blockchain nodes can receive transaction data and signature data through the network module.
  • Blockchain nodes perform certificate and signature verification.
  • 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.
  • Blockchain nodes perform permission verification.
  • 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.
  • the blockchain node prepares to generate a new block.
  • 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.
  • the scheduling module sends a transaction information sending request to the transaction pool module.
  • 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.
  • the transaction pool module adds transaction information to the transaction queue.
  • the transaction pool module may write the above-mentioned multiple transaction information into the transaction queue in sequence through the transaction queue sender.
  • 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).
  • the transaction pool module obtains the write lock of the first-class read-write queue.
  • the transaction pool module puts the transaction information into the transaction queue and goes to 20.
  • the first type of read queue is used by the virtual machine engine to read transaction information
  • 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.
  • 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.
  • the transaction pool module acquires the write lock of the first type write queue.
  • the transaction pool module writes the transaction information into the first type write queue.
  • 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.
  • the virtual machine engine acquires a read lock.
  • the virtual machine engine obtains a read lock of the first type of read/write queue to read transaction information for transaction processing.
  • the virtual machine engine reads the transaction information and performs transaction processing on the transaction information to obtain the processing result.
  • the VM engine 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.
  • the virtual machine engine writes the processing results to the result queue.
  • 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.
  • the scheduling module reads the processing results from the result queue.
  • 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.
  • the scheduling module puts the processing results into the consensus block.
  • the master node sends the new block to all slave nodes for consensus.
  • the scheduling module can package the processed multiple transaction information into a new block.
  • step 27 If the consensus is reached, go to step 27; if the consensus is not reached, end.
  • All blockchain nodes store state data in the state database.
  • the status data may be updated based on the processing results.
  • 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.
  • the dynamic switching process between the write and read queues can include the following.
  • the virtual machine engine reads the read queue in the bidirectional multi-group sortable queue.
  • step 4 If the write queue is empty, go to step 4; if the write queue is not empty, go to step 6.
  • step 5 The transaction information is packaged into a new block.
  • 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.
  • 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, go to 9. If the total number of queues is not 1, go to 10.
  • 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.
  • 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.
  • the technical solutions provided by the embodiments of the present application can be applied in at least the following scenarios:
  • 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.
  • 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.
  • 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.
  • 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.
  • a write queue is used to write transaction information
  • a read queue is used to read transaction information
  • the write queue is constrained by a write lock, thereby ensuring the synchronization consistency of the transaction information
  • 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.
  • 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 17 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.
  • the computer device 1700 includes a processor 1701 and a memory 1702 .
  • 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.
  • 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.
  • the processor 1701 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.
  • AI Artificial Intelligence
  • 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.
  • 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.
  • 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 in 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.
  • RAM Random Access Memory
  • ROM Read-Only Memory
  • EPROM Erasable Programmable Read-Only Memory
  • EEPROM Electrical Erasable Programmable Read-Only Memory
  • flash memory or other solid-state storage technology
  • 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.
  • a prompt interface, pop-up window or voice prompt information 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种应用于区块链节点的事务信息处理方法，区块链节点包含调度模块、事务池模块和虚拟机引擎，该方法包括：接收调度模块所发送的事务信息发送请求，事务信息发送请求用于请求事务池模块开始发送事务信息(401)；响应于事务信息发送请求，确定事务池模块存储的多个事务信息(402)；及在用于传输多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将多个事务信息写入第一类写队列，第一类写队列受写锁约束，写锁约束下的第一类写队列同一个时刻仅允许单个线程进行多个事务信息中事务信息的写操作，第一类读队列同一个时刻允许多个线程并行进行多个事务信息中事务信息的读操作，第一类读队列用于供虚拟机引擎读取事务信息，对多个事务信息进行事务处理获得处理结果，多个事务信息和处理结果用于指示调度模块基于处理结果将多个事务信息打包成新区块(403)。

Description

区块链节点及应用于区块链节点的事务信息处理方法
相关申请
本申请要求2024年03月06日申请的，申请号为2024102610871，名称为“区块链节点及应用于区块链节点的交易处理方法”的中国专利申请的优先权，在此将其全文引入作为参考。
技术领域
本申请涉及区块链技术领域，特别涉及一种区块链节点及应用于区块链节点的事务信息处理方法。
背景技术
在区块链系统中，区块链节点在获取新事务信息后，会先将新事务信息暂存在该区块链节点的缓存池模块中，区块链节点在准备生成新区块时，再从事务池模块中选择一定数量的事务信息进行处理与打包。
相关技术中，事务池模块以单一队列的方式，将需要打包成新区块的多个事务信息传递给区块链节点的虚拟机引擎，如事务池模块将事务信息写入该队列，虚拟机引擎从该队列中读取并处理事务信息。同时为了保护队列中的事务信息的同步一致性，在传递事务信息时，通常会给事务信息添加读写锁，然而，如此会产生读写锁冲突的问题，即往队列写入事务信息时需要持有写锁，从队列中读取事务信息时需要持有读锁，写线程占用写锁往队列中写入事务信息时，其他的写线程和读线程只能等待，读线程占用读锁从队列中读取事务信息时，写线程只能等待，如此容易导致事务信息的读写堵塞，事务信息在区块链节点中的传递效率不高。
发明内容
本申请提供了一种区块链节点及应用于区块链节点的事务信息处理方法。
根据本申请实施例的一个方面，提供了一种应用于区块链节点的事务信息处理方法，所述区块链节点包含调度模块、事务池模块和虚拟机引擎，所述方法包括：
接收所述调度模块所发送的事务信息发送请求，所述事务信息发送请求用于请求所述事务池模块开始发送事务信息；
响应于所述事务信息发送请求，确定所述事务池模块存储的多个事务信息；及
在用于传输所述多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将所述多个事务信息写入所述第一类写队列，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作，所述第一类读队列用于供所述虚拟机引擎读取所述事务信息，对所述多个事务信息进行所述事务处理获得处理结果，所述多个事务信息和所述处理结果用于指示所述调度模块基于所述处理结果将所述多个事务信息打包成新区块。
根据本申请实施例的一个方面，提供了一种应用于区块链节点的事务信息处理方法，所述区块链节点包含调度模块、事务池模块和虚拟机引擎，所述方法包括：
在用于传输事务信息的事务队列包括第一类读队列和第一类写队列的情况下，从所述第一类读队列中读取多个事务信息，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作，所述第一类写队列中的所述多个事务信息由所述事务池模块写入，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作；
对所述多个事务信息进行事务处理，得到所述多个事务信息各自对应的处理结果；及
将所述多个事务信息和所述处理结果发送给所述调度模块，所述多个事务信息和所述处理结果用于指示所述调度模块基于所述处理结果将所述多个事务信息打包成新区块。
根据本申请实施例的一个方面，提供了一种区块链节点，所述区块链节点包含事务池模块、虚拟机引擎和调度模块；
所述事务池模块，用于接收所述调度模块所发送的事务信息发送请求，所述事务信息发送请求用于请求所述事务池模块开始发送事务信息；响应于所述事务信息发送请求，确定所述事务池模块存储的多个事务信息；在用于传输所述多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将所述多个事务信息写入所述第一类写队列，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作；
所述虚拟机引擎，用于从所述第一类读队列中读取所述多个事务信息；对所述多个事务信息进行事务处理，得到所述多个事务信息各自对应的处理结果；将所述多个事务信息和所述处理结果发送给所述调度模块；
所述调度模块，用于基于所述处理结果将所述多个事务信息打包成新区块。
根据本申请实施例的一个方面，提供了一种计算机可读存储介质，所述存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现上述应用于区块链节点的事务信息处理方法。
根据本申请实施例的一个方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，处理器从所述计算机可读存储介质读取并执行所述计算机程序以实现上述应用于区块链节点的事务信息处理方法。
本申请的一个或多个实施例的细节在下面的附图和描述中提出。本申请的其它特征、目的和优点将从说明书、附图以及权利要求书变得明显。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请一个实施例提供的方案实施环境的示意图；
图2是本申请一个实施例提供的区块链节点的示意图；
图3是本申请一个实施例提供的区块链节点中的各个模块之间的交互关系的示意图；
图4是本申请一个实施例提供的应用于区块链节点的事务信息处理方法的流程图；
图5是本申请一个实施例提供的事务队列的示意图；
图6是本申请一个实施例提供的事务信息的写入位置的确定方法的流程图；
图7是本申请一个实施例提供的第一类写队列的示意图；
图8是本申请另一个实施例提供的第一类写队列的示意图；
图9和10是本申请一个实施例提供的第一类读队列与子队列之间的切换方法的示意图；
图11是本申请另一个实施例提供的应用于区块链节点的事务信息处理方法的流程图；
图12是本申请一个实施例提供的处理结果的传输方法的流程图；
图13是本申请一个实施例提供的结果队列的示意图；
图14是本申请一个实施例提供的第二类写队列的示意图；
图15是本申请另一个实施例提供的应用于区块链节点的事务信息处理方法的流程图；
图16是本申请一个实施例提供的读队列与写队列之间的切换方法的流程图；
图17是本申请一个实施例提供的计算机设备的结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
首先，对本申请中涉及到的名词进行介绍说明。
区块链技术是信息技术领域中的一种分布式账本技术，一般由共识、事务区块和状态数据存储、密码学身份安全等内容构成，由于账本是分布式存储的，而且区块是经过共识的，所以具有不可篡改、可追溯、共同维护等特征(它将事务信息打包成一个个区块，并通过密码学的方式链接在一起，形成一个不可篡改的链条(即区块链)，每个区块都包含了事务记录和前一个区块的哈希值)。
区块链系统可以是指基于区块链技术实现的分布式系统。区块链系统可以包括区块链底层平台、平台产品服务层以及应用服务层。区块链系统也可以被称之为区块链网络。
区块链底层平台可以包括用户管理、基础服务、智能合约以及运营管理等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的事务情况，提供风险控制的规则配置(审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求(即事务信息)的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链系统上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营管理模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、管理网络情况、管理节点设备健康状态等。
平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链系统实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。
区块链(Block Chain)是区块链系统中的核心数据结构，其是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块(即区块)，每一个数据块中包含了一批次网络事务的信息(即事务信息)，用于验证其信息的有效性(防伪)和生成下一个区块。例如，区块链可用于存储和管理所有已确认的区块。区块链以链式结构组织，每个区块包含一组事务、区块头(包括前一个区块的哈希值、时间戳等元数据)以及其他信息。区块链为区块链系统提供了一个公共、不可篡改的事务历史记录，确保了区块链系统的透明性和一致性。区块链也可被称之为区块账本。
区块链包括一系列按照产生的先后时间顺序相互接续的区块，新区块一旦加入到区块链中就不会再被移除。区块由区块头和区块主体组成；其中，区块头包括：区块的版本号、根哈希、用于表征区块创建的时间戳等、难度值(Target_bits)、随机数(Nonce)。区块主体中记录了该区块中的事务信息，这些事务信息可以按照默克尔(Merkle)树结构排列。根哈希通常指的是默克尔树(Merkle Tree)的根节点的哈希值。默克尔树是一种二叉树结构，用于高效验证大量数据的完整性。根哈希是通过递归地对树中节点的哈希值进行计算得到的。从叶子节点开始，每个叶子节点存储一个数据块(如事务信息)的哈希值。相邻的两个叶子节点的哈希值会被组合起来，再进行哈希计算，得到它们父节点的哈希值。这个过程会一直重复，直到最终得到根节点的哈希值，即根哈希。在区块链中，根哈希被包含在区块头中。通过验证根哈希，节点可以快速检查整个区块中事务信息的完整性。如果任何一笔事务被篡改，默克尔树的结构会发生变化，根哈希也会随之改变，从而可以很容易地检测到数据的不一致。
默克尔树是一种由一组数据块的哈希值构建而成的二叉树。树的叶子节点是每个数据块的哈希值，非叶子节点是其两个子节点哈希值组合后的哈希值，最终根节点的哈希值就是根哈希。构建默克尔树时，首先对所有要处理的数据块分别进行哈希计算，得到叶子节点的哈希值，然后将相邻叶子节点的哈希值两两组合并进行哈希计算，得到上一层节点的哈希值，重复此过程直至生成根节点。由于其结构特点，任何一个数据块的微小改变都会导致从该数据块对应的叶子节点开始到根节点的所有哈希值发生变化，因此只需验证根哈希是否正确，就可确定整个数据集合是否被篡改。在区块链中，区块主体中的事务信息可按默克尔树结构排列，以保证事务信息的完整性和安全性。
随机数(Nonce)是包含在区块头中的一个任意数字，通常为32位或64位整数。虽然专利未详细阐述其在本系统中的具体作用机制，但在一般区块链概念里，它在工作量证明(PoW)共识机制中起着关键作用。矿工需不断尝试不同的随机数，将其与区块头中的其他信息(如前一个区块的哈希值、事务信息的根哈希等)一起进行哈希计算，直到得到一个满足特定条件(如哈希值小于某个目标值)的结果，找到合适随机数的矿工将获得区块奖励并将新区块添加到区块链中。
在事务信息生成之后，事务信息存储在区块链节点的事务池(Transaction Pool，也称为内存池或mempool)模块中。事务池模块是指区块链节点程序内部用于缓存事务信息的内存空间，事务池模块中的事务信息还没有写到区块账本(也即区块链)中。对于事务池模块中任意一个事务信息，其仅仅表示该区块链节点收到了事务信息。后续需要产生区块的时候，区块链节点从事务池模块中拿出一批事务信息，并将这一批事务信息会从事务池模块中删除，以使用这一批事务信息形成区块。示例性地，事务池模块是区块链系统中的一种数据结构，用于存储尚未被打包到区块的事务信息。当用户提交新事务信息到区块链网络时，该事务信息首先会进入事务池模块。区块链节点在准备生成新区块时，会从事务池模块中选择一定数量的事务信息进行打包。事务池模块有助于提高区块链网络的处理能力，同时也可以作为一种策略，让区块链节点优先选择手续费较高的事务信息进行打包，从而提高区块链节点的收益。
智能合约(Smart Contract)是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信事务，这些事务可追查且不可逆转。示例性地，智能合约可实现为存储在区块链上，在满足预设条件自动执行的程序，如自动执协议或合同中所有的操作。智能合约主要用于执行事务和访问状态数据。例如，查询买家所购买商品的物流状态，在买家签收货物后将买家的电子货币转移到商户的地址；当然，智能合约不仅限于执行用于事务的合约，还可以执行对接收的信息进行处理的合约。
状态数据是区块链系统中用于表示系统当前状态的数据结构。状态数据包括了所有账户的余额、智能合约的状态以及其他相关信息。状态数据随着事务的执行而不断更新，其反映了区块链系统在某个时间点的全局状态。在区块链系统中，状态数据通常以Merkle树或其他加密数据结构的形式存储，以确保其完整性和安全性。示例性地，状态数据可存储在状态数据库中，该状态数据库可用于保存全量的区块链系统的状态数据。
读写集是指在执行区块链事务过程中，涉及的一组数据项。读写集包括两部分：读集(readset，表示执行该笔事务所需要读出的数据集)和写集(writeset，表示存储事务的处理结果所需写入的数据集)。在区块链系统中，读写集用于记录事务对状态数据的访问和修改情况，以确保事务的正确执行和数据一致性。读写集可依据事务信息执行智能合约后生成。读写集标识用于标识读写集，其可以记为读写集key。
事务是用户对部署在区块链上智能合约的一次操作请求，事务信息是用于描述事务的信息，以指代事务。事务由用户发起，如从用户的客户端发往区块链系统中的区块链节点(称为主节点)，主节点接收到事务(如事务信息)后，根据事务指定的合约地址和接口去调用相应的智能合约，之后将事务通知给其他区块链节点(称为从节点)，从节点接收到事务后，根据事务指定的合约地址和接口去调用相应的智能合约，以对该事务进行处理。
请参考图1，其是本申请一个实施例提供的方案实施环境的示意图。该方案实施环境可以实现成为一个区块链系统，该区块链系统100可以包括：多个区块链节点101。
区块链节点101是区块链系统100的基本组成单位，区块链系统100可以包括多个区块链节点101，区块链节点101之间存在通信连接，以便任意两个区块链节点101之间可以进行数据传输，如接收来自其他节点的数据(如区块、事务信息、处理结果等)，或者向其他节点发送数据。
区块链节点101可以是接入网络中的任意形式的计算机设备，如服务器、用户终端等。区块链节点101之间形成点对点(Peer To Peer，点对点)网络，点对点协议是一个运行在TCP(Transmission Control Protocol，传输控制协议)协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端设备都可以加入而成为区块链节点，区块链节点包括硬件层、中间层、操作系统层和应用层。
区块链节点101至少具有事务信息处理、区块链维护、共识、收发、运算和存储等功能，如区块链节点101可向区块链系统100中的其他节点发送事务信息，以及对获取到的事务信息进行事务处理、共识、存储等操作。事务信息处理可以是对事务信息的事务处理。
区块链系统100中的各区块链节点101具备的功能包括但不限于以下之一：
路由，区块链节点101所具有的基本功能，用于实现区块链节点101之间的通信。
应用，用于部署在区块链系统中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。
例如，应用实现的业务包括：共享账本，用于提供账目数据的存储、查询和修改等操作的功能，将对账目数据的操作的记录数据发送到区块链系统中的其他节点，其他节点验证有效后，作为承认账目数据有效的响应，将记录数据存入临时区块中，还可以向发起操作的区块链节点101发送确认。
在一个示例中，参考图2，其是本申请一个实施例提供的区块链节点的示意图。该区块链节点101可以是区块链系统中的任一区块链节点，也可以是区块链系统中专用于对事务信息进行事务处理的区块链节点，本申请实施例对此不作限定。该区块链节点101可以包括网络模块1011、验证模块1012、事务池模块1013、调度模块1014、虚拟机引擎1015、共识模块1016和存储模块1017。
网络模块1011，用于负责区块链节点之间的通信，具有路由功能，能够实现区块链节点之间的数据传输，如事务信息广播、区块同步等。
验证模块1012，用于负责对事务信息进行证书验证和权限验证。其中，证书验证是指：验证事务信息对应的事务发起者的身份证书，以确保事务发起者的身份合法的过程。权限验证是指：验证事务发起者是否具有执行事务的权限的过程。
事务池模块1013，用于存储事务信息。该事务池模块1013可以包括事务队列发送器，该事务队列发送器用于将事务信息发送给虚拟机引擎1015。可选地，该事务队列发送器也可以实现为独立于事务池模块1013之外，本申请实施例对此不作限定。
调度模块1014，用于负责事务信息的打包，以及区块的生成。该调度模块1014可以包括事务打包器、区块生成器和结果队列读取器，事务打包器用于将已处理的事务信息打包到区块中，区块生成器用于生成新区块，包括区块头和区块主体。结果队列读取器用于从虚拟机引擎1015获取事务信息的处理结果。
虚拟机引擎1015，用于负责执行和验证对事务信息的事务处理。该虚拟机引擎1015可以包括事务执行与验证模块、事务队列读取器和结果队列发送器，该事务执行与验证模块用于负责执行事务处理，得到处理结果，并验证处理结果的正确性。事务队列读取器用于从事务池模块1013获取事务信息，结果队列发送器用于将事务信息的处理结果发送给调度模块1014。可选地，结果队列发送器也可以实现为独立于虚拟机引擎1015之外，本申请实施例对此不作限定。
共识模块1016，用于负责在区块链系统中达成对区块和事务信息的共识，以确保区块链的正确性和安全性。其中，共识是指：是让区块链系统中各个区块链节点之间的分布式账本(即区块链)保持一致的过程。
存储模块1017，用于负责存储区块链的数据，包括区块账本和状态数据。其中，区块账本负责存储已经处理过的区块数据，状态数据负责存储区块链系统中的状态信息，如账户余额、智能合约数据等。
在一个示例中，参考图3，区块链节点101中的各个模块之间的交互关系可以如下：
网络模块1011和验证模块1012之间通信连接，验证模块1012与事务池模块1013之间通信连接，事务池模块1013与虚拟机引擎1015和调度模块1014之间通信连接，虚拟机引擎1015和调度模块1014之间通信连接，调度模块1014和共识模块1016之间通信连接，共识模块1016与存储模块1017之间通信连接。
网络模块1011在获取新事务信息之后，将其发送给验证模块1012进行证书验证和权限验证，验证模块1012将验证通过的事务信息发送给事务池模块1013以进行存储。事务池模块1013在接收到来自调度模块1014的事务信息发送请求后，将要打包成新区块的多个事务信息添加至事务队列中，以通过事务队列将该多个事务信息发送给虚拟机引擎1015，虚拟机引擎1015对该多个事务信息进行事务处理，得到多个事务信息的处理结果，以及将多个处理结果添加至结果队列中，以通过结果队列将该多个处理结果发送给调度模块1014。可选地，虚拟机引擎1015还将已处理的多个事务信息发送给调度模块1014。调度模块1014将已处理的事务信息打包到新区块，并将新区块和处理结果发送给共识模块1016，共识模块1016将新区块分发给其他区块链节点以进行共识，以及在共识完成后，将新区块和处理结果发送给存储模块1017，存储模块1017根据新区块和处理结果更新区块链(如将新区块添加在原有区块链中)和状态数据(如根据处理结果对状态数据进行更新)。
下文将采用方法实施例对本申请实施例提供的技术方案进行说明，方法实施例未说明的内容，可以参考上述实施例。
请参考图4，其是本申请一个实施例提供的应用于区块链节点的事务信息处理方法的流程图。示例性地，该方法的执行主体可以是图1所示的方案实施环境中的节区块链节点101，如节区块链节点101中的事务池模块1013，节区块链节点101包含调度模块1014、事务池模块1013和虚拟机引擎1015。如图4所示，该方法可以包括如下几个步骤(401～403)中的至少一个步骤：
步骤401，接收调度模块所发送的事务信息发送请求，事务信息发送请求用于请求事务池模块开始发送事务信息。
调度模块是区块链节点中的一个模块，负责事务信息的打包以及区块的生成。该模块可以包括事务打包器、区块生成器和结果队列读取器，事务打包器用于将已处理的事务信息打包到区块中，区块生成器用于生成新区块，包括区块头和区块主体，结果队列读取器用于从虚拟机引擎获取事务信息的处理结果。此外，调度模块会在确定需要生成新区块的情况下，生成事务信息发送请求，告知事务池模块开始发送事务信息。
事务池模块是指区块链节点程序内部用于缓存事务信息的内存空间，用于存储事务信息。该模块可以包括事务队列发送器，负责将事务信息发送给虚拟机引擎。事务池模块会接收调度模块发送的事务信息发送请求，并响应该请求确定待处理的多个事务信息，然后将这些事务信息写入事务队列中的第一类写队列。
事务信息用于描述区块链系统中的事务，是用户对部署在区块链上智能合约的一次操作请求的信息指代。事务信息可以包括事务信息的身份标识(TxID)、事务的属性信息(如所属区块的版本号、具体事务内容、时间戳等)，其用途根据调用的智能合约来确定，例如调用存证合约的事务信息可用于存储数据，调用转账合约的事务信息可用于转账或物物交换等。
事务信息发送请求是调度模块在确定需要生成新区块的情况下生成的。示例性地，调度模块可以按照第一时间间隔生成新区块，如调度模块每10s、15s等生成一个新区块。调度模块可以按照第一事务数量生成新区块，如调度模块每2000个事务信息、1500个事务信息等生成一个新区块，本申请实施例对此不作限定。
区块是由调度模块针对多个已处理的事务信息打包得到的。事务信息用于描述区块链系统中的事务，事务是用户对部署在区块链上智能合约的一次操作请求。示例性地，事务信息可以是指区块链中进行的操作的表征方式。事务信息的用途可以根据事务信息调用的智能合约来确定。例如，调用存证合约的事务信息可以用于存储数据；又例如，调用转账合约的事务信息可以用于转账或物物交换；又例如，调用某游戏合约的事务信息可以用于调用游戏程序，本申请实施例对此不作限定。
在一些实施例中，事务信息中包括事务信息的身份标识(TxID)、事务的属性信息等。事务信息的身份标识也称为事务哈希，用于唯一标识事务信息。事务的属性信息包括事务信息所属区块的版本号、具体事务内容(如事务输入序列、事务输出序列)等。此外，属性信息中还可以包括事务信息的时间戳，用于指示事务信息的创建时刻。事务哈希是通过特定的哈希算法(如SHA-256)对事务信息进行处理后生成的一个固定长度的字符串。这个字符串是事务信息的唯一数字指纹，无论事务信息的内容有多长或多短，哈希值的长度都是固定的。在区块链中，事务哈希用于唯一标识每一笔事务。当用户发起一笔事务时，该事务的所有细节(如发送方地址、接收方地址、事务金额等)会被组合在一起，经过哈希算法计算得到事务哈希。其他节点可以通过这个哈希值快速验证事务的完整性和唯一性，确保事务在传输和存储过程中没有被篡改。在区块链网络中，打包事务时会使用事务哈希来识别和组织事务；节点之间同步事务信息时也依靠事务哈希来确认事务是否已经处理过。
可选地，上述该事务信息发送请求可以包括待打包进新区块的、待处理的多个事务信息的标识信息，如事务信息的身份标识、事务信息的创建时间、新区块的根哈希、版本号等。例如，调度模块可根据第一时间间隔，确定当前打包时间段，以及将创建时间处于当前打包时间段内的事务信息，确定为待打包进新区块的事务信息，然后基于事务信息的身份标识或创建时间，生成事务信息发送请求，以告知事务池模块发送哪些事务信息。可选地。上述该事务信息发送请求还可以包括当前打包时间段，事务池模块可根据当前打包时间段确定需要发送的事务信息，本申请实施例对此不作限定。
事务池模块中存储有事务信息，事务信息用于指示待执行的事务。事务信息可以是该区块链节点接收到的其他区块链节点发送的事务信息。事务信息也可以是该区块链节点收集到的事务信息，区块链节点收集到的事务信息可以是该区块链节点生成的事务信息。事务信息还可是事务发起者通过终端设备发送给该区块链节点的事务信息，本申请实施例对此不作限定。
步骤402，响应于事务信息发送请求，确定事务池模块存储的多个事务信息。
可选地，事务池模块基于事务信息发送请求中的身份标识，确定该多个事务信息，也可以基于事务信息发送请求中的创建时间，确定该多个事务信息，还可以基于事务信息发送请求中的当前打包时间段，确定该多个事务信息，本申请实施例对此不作限定。
在一个可行示例中，该事务信息发送请求仅用于请求事务池模块开始发送事务信息，具体发送哪些事务信息可由事务池模块自行确定，如优先发送创建时间较早的事务信息，以提高事务信息的处理及时性。
步骤403，在用于传输多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将多个事务信息写入第一类写队列，第一类写队列受写锁约束，写锁约束下的第一类写队列同一个时刻仅允许单个线程进行多个事务信息中事务信息的写操作，第一类读队列同一个时刻允许多个线程并行进行多个事务信息中事务信息的读操作，第一类读队列用于供虚拟机引擎读取事务信息，对多个事务信息进行事务处理获得处理结果，多个事务信息和处理结果用于指示调度模块基于处理结果将多个事务信息打包成新区块。
在本申请实施例中，事务队列是指用于传输事务信息的队列，如用于在事务池模块和虚拟机引擎之间传输事务信息的队列。队列是一种数据结构，本申请实施例中的事务队列区别于普通的队列，其可以包括第一类读队列和第一类写队列。第一类读队列是指用于读取事务信息的队列，其不用于写入事务信息。第一类写队列是指用于写入事务信息的队列，其不用于读取事务信息，第一类读队列和第一类写队列不相连。
事务处理是指通过事务信息对应的智能合约对事务信息进行处理(即执行事务)并得到处理结果的过程。在区块链系统中，用户发起的事务信息会被区块链节点接收，虚拟机引擎会根据事务信息调用相应的智能合约，执行合约中定义的逻辑，完成事务操作并生成处理结果，该处理结果可用于更新区块链系统中的状态数据。
虚拟机引擎负责执行和验证对事务信息的事务处理。该模块可以包括事务执行与验证模块、事务队列读取器和结果队列发送器，事务执行与验证模块用于执行事务处理，得到处理结果，并验证处理结果的正确性；事务队列读取器用于从事务池模块获取事务信息；结果队列发送器用于将事务信息的处理结果发送给调度模块。
锁约束是一种用于保护共享资源同步一致性的机制，在区块链事务处理中主要涉及读写锁约束。写锁约束下，同一时刻仅允许单个线程对受约束的资源(如第一类写队列、第二类写队列)进行写操作，以避免数据不一致的问题；读锁通常允许多个线程同时对资源进行读操作。通过合理设置锁约束，可以提高事务信息和处理结果在区块链节点不同模块之间的传输效率。
打包指调度模块基于虚拟机引擎对事务信息进行事务处理得到的处理结果，将多个已处理的事务信息整合到一起，形成新区块的过程。新区块由区块头和区块主体组成，事务信息会被添加到新区块的区块主体中，待共识完成后，新区块会被添加进区块链系统中的区块链。调度模块在确定需要生成新区块后，构建新区块的区块头和区块主体，该多个事务信息被进行事务处理后，可由调度模块打包进新区块的区块主体中。
可选地，第一类写队列受写锁约束，第一类读队列不受锁约束。其中，写锁是读写锁(一种自旋锁)中的写锁，读写锁只有一把，写锁是指写模式加锁时的读写锁。读写锁是一种用于保护共享资源的同步原语，它允许多个线程同时读取共享资源(读锁)，但在写入资源时，只允许单个线程执行写操作(写锁)。读写锁可以确保在写操作期间，其他线程不能对共享资源进行读写操作，从而避免了数据不一致的问题。在区块链事务处理中，读取操作通常不修改数据，因此第一类读队列设计为不受锁约束，可避免因读写锁冲突导致的等待。这种设计提高了读取操作的并发性，使得虚拟机引擎能并行读取，减少事务处理耗时，提升区块链节点对大量事务并发的处理能力，增强系统整体性能。
由于第一类写队列受写锁约束，第一类读队列不受锁约束，虚拟机引擎可并行使用线程读取第一类读队列中的事务信息，而无需占用读锁，也无需等待第一类写队列对应的写锁的释放，从而提高了事务信息的读取效率。而事务池模块仅需占用写锁依次将事务信息写入第一类写队列，而无需等待读锁(第一类读队列不受锁约束)的释放，从而提高了事务信息的写入效率，进而有效提高事务信息在事务池模块和虚拟机引擎之间的传输效率。
在一个可行示例中，虚拟机引擎对多个事务信息进行事务处理获得处理结果的过程如下：虚拟机引擎通过事务信息对应的智能合约，对读取到的事务信息进行事务处理，以得到事务信息的处理结果。对于同一个事务组(即写入区域)中的各个事务信息，采用同一个智能合约进行事务处理；对于不同事务组中的事务信息，需切换至对应的智能合约进行事务处理。由于事务信息是按照合约名和到达时间排序的，所以这样做可降低智能合约的切换成本，以及减少智能合约切换时的响应耗时。虚拟机引擎按照事务信息被读取的顺序，依次对读取到的事务信息进行事务处理，从而得到多个事务信息对应的处理结果。
在一个可行示例中，虚拟机引擎将多个事务信息和处理结果发送给调度模块，这些事务信息和处理结果用于指示调度模块基于处理结果将多个事务信息打包成新区块。新区块是待共识完成后添加进区块链系统中的区块链的区块，多个事务信息可被添加进新区块的区块主体中，处理结果可用于在共识完成后对区块链系统中的状态数据进行更新。具体发送方式如下：
事务信息的发送：虚拟机引擎和调度模块之间设置有第二个事务队列，虚拟机引擎将处理后的事务信息，依次写入该第二个队列中的第一类写队列，调度模块则依次从该第二个事务队列中的第一类读队列中读取处理后的事务信息。该第二个事务队列的工作原理，与事务池模块和虚拟机引擎之间的事务队列的工作原理相同。
处理结果的发送：当用于传输处理结果的结果队列包括第二类读队列和第二类写队列时，虚拟机引擎将处理结果写入第二类写队列。第二类写队列受写锁约束，写锁约束下的第二类写队列同一个时刻仅允许单个线程进行处理结果的写操作，第二类读队列用于调度模块读取处理结果，且第二类读队列同一个时刻允许多个线程并行进行读操作。具体步骤如下：获取读写集标识：虚拟机引擎根据处理结果对应的事务信息，确定处理该事务信息以及该事务信息对应的处理结果所需的读写集，并获取该读写集的读写集标识，如读写集key。确定写入位置：确定候选子队列：对于第二类写队列所包括的各个子队列，将不存在读写集标识与该处理结果的读写集标识相同的子队列，确定为候选子队列。确定目标子队列：将候选子队列中的第一个候选子队列确定为目标子队列。确定目标子队列中的写入位置：根据处理结果的读写集标识，确定该处理结果在目标子队列中的写入位置，子队列中的各个处理结果按照读写集标识从小到大的顺序排列。确定在第二类写队列中的写入位置：将处理结果在目标子队列中的写入位置，确定为处理结果在第二类写队列中对应的写入位置。写入处理结果：将该处理结果写入该写入位置，以实现将处理结果写入第二类写队列。若第二类写队列中不存在候选子队列，则在第二类写队列的尾部增加新的子队列，并将处理结果写入新的子队列的头部。
当第二类读队列中的处理结果被清空时，进行子队列和第二类读队列的切换操作。具体为将第二类读队列移动至第二类写队列的尾部，以及将第二类读队列变更为新的子队列，得到新的第二类写队列；同时将第二类读队列中的第一个子队列变更为新的第二类读队列。在切换过程中，禁止针对处理结果的所有写操作和读操作，以避免处理结果传输错误。在一个批量处理结果(即新区块对应的所有事务信息的处理结果)被传输完成后，结果队列可以保留一个子队列(即恢复到初始状态)，以进行下一批量处理结果的传输，从而降低结果队列对传输资源的占用。第二类读队列也可以包括少量的子队列，如2个、3个等，这样有利于降低子队列与第二类读队列之间切换频率，进而降低结果队列的管理工作量，同时保证处理结果的稳定读取，以及降低读取等待时长，提高处理结果的读取效率。
上述实施例中，通过将事务队列分为受写锁约束的第一类写队列和不受锁约束的第一类读队列，保证了事务信息写入时的同步一致性，避免了读写操作的相互影响。虚拟机引擎可并行读取第一类读队列中的事务信息，无需等待写锁释放，提高了读取效率；事务池模块仅需占用写锁依次写入事务信息，无需等待读锁释放，提高了写入效率，进而有效提高了事务信息在事务池模块和虚拟机引擎之间的传输效率，最终提升了事务信息在区块链节点中的处理效率。同时，通过调度模块基于处理结果将事务信息打包成新区块，确保了区块链的正常运行和事务记录的有序存储。
在一个示例中，第一类写队列受写锁约束可实现为：针对第一类写队列添加写锁，线程均需占用写锁，才可针对第一类写队列进行事务信息的写操作，写操作是指将事务信息写入第一类写队列的过程。例如，对第一类写队列对应的存储地址加写锁，线程需要占用写锁，才可对加写锁后的存储地址进行访问以及写操作。该写锁可以实现为一段代码，加写锁时，将第一类写队列引入该段代码即可，解写锁时，将第一类写队列从该段代码中删除即可，本申请实施例对此不作限定。
在另一个示例中，可对临界区(用于对第一类写队列进行写操作的代码或程序片段)加写锁，在当前线程用写锁占用该临界区时，其他线程无论是用于写操作还是读操作都会堵塞。读操作是指将事务信息从第一类读队列中读出的过程。临界区是用于对第一类写队列进行写操作的代码或程序片段。在多线程环境下，为保证共享资源(如第一类写队列)的同步一致性，可对临界区加写锁。当当前线程用写锁占用该临界区时，其他线程无论是进行写操作还是读操作都会被堵塞，以此确保同一时刻仅允许单个线程对第一类写队列进行事务信息的写操作，避免数据冲突和不一致。
可选地，上述第一类写队列还可以包括至少一个子队列，每个子队列依次首尾相连。每个子队列均可用于写入事务信息，如至少一个子队列中的第一个子队列和第二子队列，在第一个子队列填满之后，再对第二个子队列进行事务信息的写入。示例性地，该子队列的数量可以是根据经验值预设的，如固定有10个子队列，该子队列的数量也可以是根据写入的事务信息实时调整的，如若每个子队列可写入10个事务信息，则每写入10个事务信息，第一类写队列在尾部新增一个子队列。第一类写队列的长度也可以根据写入的事务信息的数量自动调整。
示例性地，参考图5，其是本申请一个实施例提供的事务队列的示意图。事务队列500包括第一类写队列501和第一类读队列502，第一类写队列501和第一类读队列502不相连，第一类写队列501中的多个子队列首尾相连，每个子队列的长度可以相同。第一类读队列502的长度可以与子队列的长度相同。
第一类写队列501受写锁约束，第一类读队列502不受锁约束。在有写线程想要将事务信息写入第一类写队列501的情况下，若检测到已有其他写线程占用写锁，该写线程则等待该其他写线程释放写锁，在其他写线程释放写锁后，该写线程可占用写锁，将事务信息写入第一类写队列501。若检测到写锁未被占用，该写线程则可直接占用写锁，将事务信息写入第一类写队列501。
在有读线程想要读取第一类读队列502中的事务信息的情况下，无论是否检测到已有其他读线程正在进行读操作，该读线程则均可直接读取第一类读队列502中的事务信息。第一类读队列502中的事务信息依次被虚拟机引擎所读取，如从第一类读队列502的头部到尾部的顺序、从第一类读队列502的尾部到头部的顺序。图5中的空白格子用于指示该位置处没有事务信息。
在一个示例中，初始状态下的事务队列包括一个第一类读写队列，该第一类读写队列受读写锁约束，读写锁约束下的第一类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作。初始状态下的事务队列包括一个受读写锁约束的第一类读写队列，该读写锁约束使得第一类读写队列在同一个时刻仅允许单个线程进行写操作，以保证写入数据的一致性，同时同一个时刻允许多个线程并行进行读操作，提高读取效率。在此基础上，该权利要求将事务队列进一步分为受写锁约束的第一类写队列和不受锁约束的第一类读队列，进一步优化了读写操作的并发处理。这种设计保证了事务信息写入时的同步一致性，避免了读写操作的相互影响。虚拟机引擎可并行读取第一类读队列中的事务信息，无需等待写锁释放，提高了读取效率；事务池模块仅需占用写锁依次写入事务信息，无需等待读锁释放，提高了写入效率，进而有效提高了事务信息在事务池模块和虚拟机引擎之间的传输效率，最终提升了事务信息在区块链节点中的处理效率。同时，通过调度模块基于处理结果将事务信息打包成新区块，确保了区块链的正常运行和事务记录的有序存储。
其中，第一类读写队列既用于事务池模块写入事务信息，又用于虚拟机引擎读取事务信息。可选地，该第一类读写队列的长度可以与上述子队列的长度相同，也即初始状态下的事务队列仅包括一个子队列。
可选地，在写线程(即事务池模块)想要将事务信息写入第一类读写队列的情况下，若检测到已有其他写线程/读线程占用读写锁，该写线程则等待该其他写线/读线程释放读写锁，在其他写线程/读线程释放读写锁后，该写线程可占用读写锁(即写锁)，将事务信息写入第一类读写队列。若检测到没有其他写线程，也没有读线程占用读写锁，该写线程则可直接占用读写锁(即写锁)，将事务信息写入第一类读写队列。
在读线程(即虚拟机引擎)想要从第一类读写队列中读取事务信息的情况下，若检测到已有其他写线程占用读写锁，该读线程则等待该其他写线释放读写锁，在其他写线程释放读写锁后，该读线程可占用读写锁(即读锁)，从第一类读写队列中读取事务信息。若检测到没有其他写线程占用读写锁或有读线程占用读写锁，该写线程则可直接占用读写锁(即读锁)，从第一类读写队列中读取事务信息。
可选地，在第一类读写队列被填满的情况下，初始状态下的事务队列可变更为上述状态下的事务队列(记为双向多组可排序事务队列，双向：读和写；多组：包括第一类读队列和第一类子队列；可排序：第一类读队列中的事务信息可排序)。示例性地，本申请实施例还可以包括如下内容：
1、将事务信息写入第一类读写队列。
可选地，事务池模块可调用写线程占用读写锁，从上述多个事务信息中的第一个事务信息开始，依次将事务信息写入第一类读写队列。
2、在第一类读写队列被填满的情况下，将第一类读写队列变更为第一类读队列，以及在第一类读队列之后添加第一类写队列，第一类写队列与第一类读队列不相连。
其中，第一类读写队列被填满是指第一类读写队列对应的各个位置均被写入有事务信息。在将第一类读写队列变更为第一类读队列的同时，释放第一类读写队列对应的读写锁，并不为第一类读队列添加锁。在第一类读队列之后添加第一类写队列的同时，为第一类写队列添加写锁。
可选地，初始状态下的第一类写队列仅包括一个子队列，随着被写入的事务信息的数量的增多，第一类写队列扩展为包括多个子队列。
本申请实施例中，将初始状态下的事务队列设置为仅包括一个受读写锁约束的第一类读写队列。在事务数量较少时，这种设置可以有效减少事务队列的管理工作量。而当被写入的事务数量较多，第一类读写队列被填满时，将其变更为第一类读队列，并添加第一类写队列，切换为双向多组可排序事务队列，提高了事务信息的传输效率，实现了根据事务负载动态调整队列结构，优化了区块链节点的性能。
在一个示例中，在第一类写队列所包括的至少一个子队列被填满的情况下，在第一类写队列的尾部添加新的子队列，该新的子队列的头部与第一类写队列的尾部相连。
示例性地，在第一类写队列所包括的一个子队列被填满的情况下，在该子队列之后添加一个新的子队列；或者，在第一类写队列所包括的多个子队列被填满的情况下，在最后一个子队列之后添加一个新的子队列。该新的子队列的长度与第一类写队列所包括的子队列的长度相同。后续待被写入的事务信息可以被写入该新的子队列。
本申请实施例中，当第一类写队列的至少一个子队列被填满时，意味着随着被写入的事务信息数量增多，此时在队列尾部添加新的子队列。这种适应性增加新子队列的方式，可确保一个新区块所对应的所有事务信息能够完整地写入到事务队列中，并传输到虚拟机引擎进行处理。同时，多个子队列为第一类读队列与子队列之间的转换提供了基础，有利于后续的队列管理和事务信息的高效传输，从而提升区块链节点处理事务信息的整体性能。
上述实施例中，通过将初始状态下的事务队列设置为仅包括一个第一类读写队列，可以有效减少事务队列的管理工作量。在被写入的事务数量较多时，切换为双向多组可排序事务队列，可有效提高事务信息的传输效率。
可选地，上述事务队列中的事务信息可排序，如第一类写队列中的事务信息可排序。示例性地，该排序可由事务池模块实现，也可以由事务队列自行实现，本申请实施例对此不作限定。例如，事务池模块在确定事务信息的写入位置后，可直接将其添加至第一类写队列中对应的写入位置，事务池模块也可以仅将事务信息添加进第一类写队列，事务队列自行对该事务信息进行排序，也即自动确定该事务信息在第一类写队列中的写入位置。其中，写入位置是指事务信息在第一类写队列中被写入的位置。
对于事务池模块和事务队列，写入位置的确定方法相同，下文以事务池模块为例进行说明。在一个示例中，如图6所示，步骤403还可以包括如下几个子步骤：
步骤403a，获取事务信息的合约名和到达时间，该合约名是指用于处理事务信息的智能合约的名称，该到达时间是指事务信息到达事务池模块的时间。
可选地，事务池模块根据事务信息所指定的合约地址，确定所需调用的智能合约，进而确定出该事务信息的合约名。例如，用于处理事务信息A的智能合约的名称为B，则可以将B确定为该事务信息的合约名。
事务池模块根据事务信息到达事务池模块的时间，确定出该事务信息的到达时间。例如，若事务信息在20：17达到事务池模块，则可将20：17确定为该事务信息的到达时间。
可选地，对于用于事务信息的排序的数据，本申请实施例不局限于上述合约名，能够唯一标识智能合约的标识信息，均可用于事务信息的排序。
步骤403b，根据该事务信息的合约名，确定该事务信息在第一类写队列中对应的写入区域，该写入区域内的事务信息的合约名，与该事务信息的合约名相同。
上述写入区域是指具有相同合约名的事务信息在第一类写队列中所占的区域，不同的合约名对应不同的写入区域，该写入区域可采用其对应的存储地址进行标识。可选地，同一个写入区域内的各个事务信息具有相同的合约名，也即同一个写入区域内的各个事务信息均由同一个智能合约处理，在一个写入区域内的各个事务信息被对应的智能合约处理完后，才进行智能合约的切换，以进行下一个写入区域内的各个事务信息的处理，如此可避免智能合约的频繁切换，从而降低了智能合约的切换成本，以及减少了智能合约切换时的响应耗时，进而有效提高了事务信息的处理效率。
例如，参考图7，第一类写队列501中包括4个写入区域：合约1对应的写入区域、合约2对应的写入区域、合约3对应的写入区域和合约4对应的写入区域。每个写入区域中的事务信息的合约名相同。
可选地，在第一类写队列中存在合约名与该事务信息的合约名相同的目标事务信息的情况下，可以将该目标事务信息所在的写入区域确定为，该事务信息对应的写入区域。在第一类写队列中不存在合约名与事务信息的合约名相同的事务信息的情况下，在第一类写队列中的最后一个事务信息之后，写入事务信息，也即针对该事务信息，新增一个写入区域，该写入区域以该事务信息对应的合约名标识。如此，当第一类写队列中不存在与当前事务信息合约名相同的事务信息时，即没有对应的写入区域，此时直接将该事务信息写入队列的最后一个事务信息之后，也就是第一类写队列的队尾。如此操作，可以有效减少因事务信息而对第一类写队列进行调整所产生的工作量，提高了事务信息写入的效率，避免了不必要的队列调整操作，使事务信息能够更快速地进入队列等待处理。
例如，参考图5和8，在事务池模块将事务信息504写入第一类写队列501的过程中，事务池模块可根据事务信息504的合约名，确定事务信息504在第一类写队列501中对应的写入区域503，事务池模块可将事务信息504写入该写入区域503。虚拟机引擎可不受写锁影响，直接从第一类读队列502中读取事务信息。在图5和图8中，相同填充图案的格子组成一个写入区域，也即相同填充图案的格子对应的事务信息具有相同的合约名。
步骤403c，根据该事务信息的到达时间，从写入区域中确定该事务信息的写入位置，写入区域内的事务信息按照到达时间从先到后的顺序排列。
可选地，将该事务信息的到达时间，与写入区域中的各个事务信息依次进行比对，以确定该事务信息的写入位置。示例性地，若该事务信息的到达时间，早于写入区域中的第一个事务信息的到达时间，则将写入区域中的第一个位置确定为该事务信息的写入位置；若该事务信息的到达时间，早于写入区域中的第n个事务信息的到达时间，且晚于第n-1个事务信息的到达时间，则将第n个事务信息对应的位置确定为该事务信息的写入位置，n为大于1的整数；若该事务信息的到达时间，晚于写入区域中的最后一个事务信息的到达时间，则将该最后一个事务信息之后的事务信息对应的位置确定为该事务信息的写入位置。
例如，参考图7和8(图7与图8对应，图7中记录有第一类写队列501中各个事务信息对应的合约名和到达时间)，事务信息504的到达时间(20：10)，早于写入区域503中的第一个事务信息的到达时间(20：11)，则可将写入区域503中的第一个位置确定为该事务信息504的写入位置。
在一个可行示例中，若该事务信息的到达时间，早于写入区域中的第一个事务信息的到达时间，则可在写入区域中的第一个位置之前插入一个位置(如存储地址)，以作为该事务信息的写入位置；若该事务信息的到达时间，早于写入区域中的第n个事务信息的到达时间，且晚于第n-1个事务信息的到达时间，则可在第n个事务信息对应的位置和第n-1个事务信息对应的位置之间插入一个位置，以作为该事务信息的写入位置；若该事务信息的到达时间，晚于写入区域中的最后一个事务信息的到达时间，则可在该最后一个事务信息对应的位置之后插入一个位置，以作为该事务信息的写入位置。
可选地，对于写入位置之后的各个事务信息，以及写入位置上原来的事务信息，可依次后移一个位置(即存储地址适应性变更)，以为上述事务信息留出写入位置，本申请实施例对此不作限定。
例如，参考图7和8，对于写入区域503中的各个事务信息，以及写入区域503之后的各个事务信息，均依次后移一个位置，以为事务信息504留出写入位置。
步骤403d，根据写入位置，向第一类写队列写入事务信息。
可选地，将该事务信息写入该写入位置，以实现将该事务信息写入第一类写队列。例如，参考图7和8，可将事务信息504直接写入写入区域503中的第一个位置。
在本申请实施例中，通过按照合约名和到达时间，对被写入第一类写队列中的事务信息进行排序，可在降低智能合约的切换成本(减少响应耗时)的同时，及时完成事务信息的处理(即对于同一个写入区域，优先处理到达时间早的事务信息)。根据合约名确定写入区域，使得同一写入区域内的事务信息由同一个智能合约处理。这种方式可有效降低智能合约的切换成本，减少切换时的响应耗时。同时，按照到达时间对写入区域内的事务信息进行排序，对于同一个写入区域优先处理到达时间早的事务信息，能够及时完成事务信息的处理，保证了事务信息处理的及时性，进一步提高了事务信息的处理效率。
在一个示例中，本申请实施例还能够实现写入区域的自动排序，该写入区域中的各个事务信息可被统称为事务组，写入区域的自动排序可实现为事务组的自动排序。
示例性地，可基于事务组(写入区域)所包括的事务信息的事务数量，对事务组进行排序，该过程可以包括如下内容：
1、获取第一类写队列中各个事务组的事务数量。
获取事务组的事务数量，即是获取事务组对应的写入区域中的事务信息的事务数量；其中，事务组是以合约名聚类得到的，事务数量用于指示事务组中用于事务处理的事务信息的数量。
可选地，事务队列中每新写入一个事务信息，事务池模块就对事务组进行一次排序；或者，在第一类读队列中的事务信息被清空的情况下，事务池模块对事务组进行一次排序，如此有利于降低事务组的排序工作量，本申请实施例对此不作限定。
2、按照事务数量从大到小的顺序，对各个事务组进行排序，得到调整后的第一类写队列。
可选地，按照事务数量从大到小的顺序，对各个事务组进行排序，得到事务组序列，按照事务组序列依次排布各个事务组，从而得到调整后的第一类写队列，如将事务数量最大的事务组放置在第一类写队列的头部，将事务数量最小的事务组放置在第一类写队列的尾部。如此根据事务数量对各个事务组进行排序，优先执行事务数量较多的智能合约，可尽量避免智能合约在短时间内频繁切换，从而降低响应总时长，进而提高事务合约的处理效率，使区块链节点能够更高效地处理大量事务信息。
示例性地，还可基于事务组(写入区域)所包括的事务信息的到达时间，对事务组进行排序，该过程可以包括如下内容：
1、获取第一类写队列中各个事务组的最早到达时间。
其中，事务组是以合约名聚类得到的，最早到达时间是指事务组中各个用于事务处理的事务信息对应的最早的到达时间。
可选地，对于各个事务组，按照从先到后的顺序，对事务组中各个事务信息对应的到达时间进行排序，得到到达时间序列，将到达时间序列中的第一个到达时间确定为该事务组对应的最早到达时间。
2、按照最早到达时间从先到后的顺序，对各个事务组进行排序，得到调整后的第一类写队列。
可选地，按照最早到达时间从先到后的顺序，对各个事务组进行排序，得到事务组序列，按照事务组序列依次排布各个事务组，从而得到调整后的第一类写队列，如将最早到达时间最早的事务组放置在第一类写队列的头部，将最早到达时间最晚的事务组放置在第一类写队列的尾部。如此根据到达时间对各个事务组进行排序，优先处理到达时间较早的事务信息，有利于提高事务信息的处理及时性，确保较早到达的事务信息能够优先得到处理，减少了事务信息的等待时间，提高了区块链系统的整体性能。
在一个示例中，在第一类读队列中的事务信息被清空的情况下，本申请实施例还可以包括如下内容：
1、将第一类读队列移动至第一类写队列的尾部，以及将第一类读队列变更为新的子队列，得到新的第一类写队列。
将第一类读队列移动至第一类写队列的尾部，是指将第一类读队列添加在第一类写队列中的最后一个子队列之后，并将第一类读队列与该最后一个子队列相连接。新的第一类写队列用于事务池模块写入事务信息，如在最后一个子队列被填满之后，可直接将新的事务信息填入移动后的第一类读队列(即新的子队列)。
可选地，在将第一类读队列移动至第一类写队列的尾部之后，可对该第一类读队列添加写锁，以实现将该第一类读队列转换为新的子队列，从而得到新的第一类写队列。
第一类读队列中的事务信息被清空，是指第一类读队列中的所有事务信息均被虚拟机引擎所读取，在第一类读队列中的事务信息被虚拟机引擎所读取后，事务池模块自动对该事务信息进行删除，以腾出位置。
例如，参考图9和10，对于第一类读队列502中的各个事务信息，在事务信息被虚拟机引擎所读取后，事务池模块自动删除该事务信息，在第一类读队列502中的事务信息被清空的情况下，将第一类读队列502移动至第一类写队列501的尾部，移动后的第一类读队列502的头部与第一类写队列501相连接。对移动后的第一类读队列502添加写锁，以将该第一类读队列502转换为第一类写队列501中的新的子队列。
2、将第一类读队列中的第一个子队列变更为新的第一类读队列。
可选地，将第一个子队列与第一类写队列中的第二个子队列断开连接，并解除第一个子队列的写锁，从而将第一个子队列变更为新的第一类读队列。新的第一类读队列用于虚拟机引擎获取事务信息，也即虚拟机引擎将切换为从该新的第一类读队列中读取事务信息。
上述实施例中，当第一类读队列中的事务信息被清空时，进行子队列和第一类读队列的切换操作，即将第一类读队列移动至第一类写队列的尾部并变更为新的子队列，同时将第一类读队列中的第一个子队列变更为新的第一类读队列。这种切换方式有利于继续避免写操作和读操作之间的相互影响，使得写操作在新的第一类写队列进行，读操作在新的第一类读队列进行，保证了事务信息的传输过程不受干扰。并且，这种机制提高了事务信息的传输效率，使区块链节点能够持续高效地处理事务信息，确保了区块链系统中事务处理的流畅性和稳定性。
可选地，在子队列和第一类读队列的切换过程中，禁止针对事务信息的所有写操作和读操作，以避免事务信息传输错误。
例如，参考图9和10，对于第一类读队列中的第一个子队列505，将第一个子队列505与第一类写队列501中的第二个子队列断开连接，并解除第一个子队列505的写锁，以将第一个子队列变更为新的第一类读队列，虚拟机引擎可无需持锁继续从第一个子队列505中读取事务信息。
在一个示例中，事务队列中的事务信息也可以预写入，如预写入一个子队列的事务信息，或者，预写入小于指定数据量的事务信息，预写入的事务信息或指定数据量可根据新区块来确定，本申请实施例对此不作限定。通过预写入，可有效进一步提高事务信息的传输效率。
在一个示例中，在一个批量事务信息(即新区块对应的所有事务信息)被传输完成后，事务队列可以保留一个子队列(即恢复到初始状态)，以进行下一批量事务信息的传输，如此有利于降低事务队列对传输资源的占用。
在一个示例中，第一类读队列也可以包括少量的子队列，如2个、3个等，如此有利于降低子队列与第一类读队列之间切换频率，进而降低事务队列的管理工作量。同时，可保证事务信息的稳定读取，以及降低读取等待时长，进而提高事务信息的读取效率。
虚拟机引擎用于获取事务信息的处理结果，处理结果是指对事务信息进行事务处理(即执行事务)所得到的结果。可选地，虚拟机引擎可通过事务信息对应的智能合约，对该事务信息进行事务处理，以得到事务信息的处理结果。
综上，采用本申请实施例提供的技术方案，在事务信息在区块链节点中传递的过程中，通过将事务队列设置为两类队列：写队列用于写入事务信息，读队列用于读取事务信息，且写队列受写锁约束，从而保证了事务信息的同步一致性，读队列不受锁约束，避免了针对事务信息的读操作受针对事务信息的写操作的影响，也避免了针对事务信息的写操作受针对事务信息的读操作的影响，有效提高了针对事务信息的写操作的效率，以及针对事务信息的读操作的效率，从而提高了事务信息在区块链节点中的传递效率，进而提高了事务信息在区块链节点中的处理效率。
请参考图11，其是本申请另一个实施例提供的应用于区块链节点的事务信息处理方法的流程图。示例性地，该方法的执行主体可以是图1所示的方案实施环境中的节区块链节点101，如节区块链节点101中的虚拟机引擎1015。如图11所示，该方法可以包括如下几个步骤(1101～1103)中的至少一个步骤：
步骤1101，在用于传输多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，从第一类读队列中读取多个事务信息，第一类读队列同一个时刻允许多个线程并行进行多个事务信息中事务信息的读操作，第一类写队列中的多个事务信息由事务池模块写入，第一类写队列受写锁约束，写锁约束下的第一类写队列同一个时刻仅允许单个线程进行多个事务信息中事务信息的写操作。
其中，事务队列、第一类读队列、第一类写队列、事务信息、写事务池模块和虚拟机引擎与上述实施例介绍相同，本申请实施例未说明的内容可参考上述实施例，这里不再赘述。
可选地，由于第一类读队列不受锁约束，虚拟机引擎可同时通过至少单个线程从第一类读队列中读取事务信息，而无需占用读锁，也无需等待写锁的释放。事务池模块则需要占用读锁，以将事务信息依次写入第一类写队列。在一个示例中，在事务队列仅包括第一类读写队列的情况下，虚拟机引擎需要占用读锁，以依次从该第一类读写队列中读取事务信息。
可选地，虚拟机引擎可按照从第一类读队列的头部到尾部的顺序，依次对事务信息进行读取，以及按照该顺序依次对读取到的事务信息进行事务处理。
步骤1102，对多个事务信息进行事务处理，得到多个事务信息各自对应的处理结果。
可选地，虚拟机引擎可通过事务信息对应的智能合约，对该事务信息进行事务处理，以得到事务信息的处理结果。被处理后的多个事务信息可用于打包成一个新区块。
其中，对于同一个事务组(即上述写入区域)中的各个事务信息，可采用同一个智能合约进行事务处理。对于不同事务组中的事务信息，需切换至对应的智能合约进行事务处理。虚拟机引擎可按照事务信息被读取的顺序，依次对读取到的事务信息进行事务处理，以得到该多个事务信息对应的处理结果，由于事务信息是按照合约名和到达时间排序的，如此可降低智能合约的切换成本，以及减少智能合约切换时的响应耗时。处理结果是指对事务信息进行事务处理(即执行事务)所得到的结果。
步骤1103，将多个事务信息和处理结果发送给调度模块，多个事务信息和处理结果用于指示调度模块基于处理结果将多个事务信息打包成新区块。
新区块是指待共识完成后添加进区块链系统中的区块链的区块，该多个事务信息可被添加进新区块的区块主体中。处理结果可用于在共识完成后对区块链系统中的状态数据进行更新。
上述实施例中，从虚拟机引擎的角度出发，在事务队列分为第一类读队列和第一类写队列的情况下，虚拟机引擎可不受锁约束地从第一类读队列中读取事务信息，提高了读取效率。对读取的事务信息进行事务处理后，将事务信息和处理结果发送给调度模块进行打包成新区块，保证了区块链系统中事务信息的正常处理和新区块的生成。同时，通过读写分离的队列设计，避免了读写操作的相互影响，提高了事务信息在区块链节点中的传递效率和处理效率。
在一个示例中，虚拟机引擎可以将事务信息和事务信息对应的处理结果关联在一起，发送给调度模块，如通过下述的结果队列一起发送给调度模块；虚拟机引擎也可以将事务信息和处理结果分别发送给调度模块，如以事务队列的方式发送事务信息，以及以结果队列的方式发送处理结果，本申请实施例对此不作限定。
在一个可行示例中，虚拟机引擎还可以以单个队列、RPC(Remote Procedure Call Protocol，远程过程调用协议)等方式将事务信息发送给调度模块。对于事务池模块和虚拟机引擎之间的事务信息，也可以采用单个队列、RPC(Remote Procedure Call Protocol，远程过程调用协议)等方式进行传输。需要说明的是，对于虚拟机引擎与调度模块、事务池模块和虚拟机引擎，两者中有一个应用本申请实施例提供的技术方案，均可以提高事务信息在区块链节点中的传输效率。远程过程调用协议(RPC)是虚拟机引擎和调度模块之间、事务池模块和虚拟机引擎之间可采用的一种传输事务信息的方式。它允许一台计算机上的程序调用另一台计算机上的程序中的过程或函数，就像调用本地程序一样。在区块链系统中，RPC用于不同模块之间的通信，优点是使用方便，开发人员可像调用本地函数一样调用远程函数，提高开发效率，还可实现不同模块之间的解耦，便于系统的扩展和维护；缺点是网络延迟会影响调用性能，且需要采取措施确保通信的安全性，防止数据泄露和恶意攻击。
示例性地，如图12所示，步骤1102还可以包括如下几个子步骤。
步骤1102a，将多个事务信息按照事务队列的方式发送给调度模块。
可选地，虚拟机引擎和调度模块之间设置有第二个事务队列，虚拟机引擎可将处理后的事务信息，依次写入该第二个队列中的第一类写队列，调度模块可依次从该第二个事务队列中的第一类读队列中读取处理后的事务信息。该第二个事务队列的工作原理，与事务池模块和虚拟机引擎之间的事务队列的工作原理相同，这里不再赘述。
步骤1102b，在用于传输处理结果的结果队列包括第二类读队列和第二类写队列的情况下，将处理结果写入第二类写队列，该第二类写队列受写锁约束，写锁约束下的第二类写队列同一个时刻仅允许单个线程进行处理结果的写操作，第二类读队列用于调度模块读取处理结果，第二类读队列同一个时刻允许多个线程并行进行读操作。
在本申请实施例中，结果队列是指用于传输事务信息对应的处理结果的队列，如用于在虚拟机引擎和调度模块之间传输处理结果的队列。本申请实施例中的结果队列区别于普通的队列，其可以包括第二类读队列和第二类写队列。第二类读队列是指用于读取处理结果的队列，其不用于写入处理结果。第二类写队列是指用于写入处理结果的队列，其不用于读取处理结果，第二类读队列和第二类写队列不相连。结果队列的数据结构与事务队列的数据结构相同，其也可以被称之为双向多组可排序结果队列。
可选地，第二类写队列受写锁约束，第二类读队列不受锁约束。其中，写锁是读写锁(一种自旋锁)中的写锁，读写锁只有一把，写锁是指写模式加锁时的读写锁。读写锁是一种用于保护共享资源的同步原语，它允许多个线程同时读取共享资源(读锁)，但在写入资源时，只允许单个线程执行写操作(写锁)。读写锁可以确保在写操作期间，其他线程不能对共享资源进行读写操作，从而避免了数据不一致的问题。
上述实施例中，将事务信息和处理结果的传输分别通过事务队列和结果队列进行。结果队列同样采用读写分离的设计，即受写锁约束的第二类写队列和不受锁约束的第二类读队列。由于第二类写队列受写锁约束，第二类读队列不受锁约束，调度模块可并行使用线程读取第二类读队列中的处理结果，而无需占用读锁，也无需等待第二类写队列对应的写锁的释放，从而提高了处理结果的读取效率。而虚拟机引擎仅需占用写锁依次将处理结果写入第二类写队列，而无需等待读锁(因为第二类读队列不受锁约束)的释放，从而提高了处理结果的写入效率。这种设计保证了处理结果写入时的同步一致性，有效提高了处理结果在虚拟机引擎和调度模块之间的传输效率，进一步提升了区块链节点的整体性能。
在一个示例中，第二类写队列受写锁约束可实现为：针对第二类写队列添加写锁，线程均需占用写锁，才可针对第二类写队列进行处理结果的写操作，写操作是指将处理结果写入第二类写队列的过程。例如，对第二类写队列对应的存储地址加写锁，线程需要占用写锁，才可对加写锁后的存储地址进行访问以及写操作。该写锁可以实现为一段代码，加写锁时，将第二类写队列引入该段代码即可，解写锁时，将第二类写队列从该段代码中删除即可，本申请实施例对此不作限定。
在另一个示例中，可对临界区(用于对第二类写队列进行写操作的代码或程序片段)加写锁，在当前线程用写锁占用该临界区时，其他线程无论是用于写操作还是读操作都会堵塞。读操作是指将处理结果从第二类读队列中读出的过程。
可选地，上述第二类写队列还可以包括至少一个子队列，每个子队列依次首尾相连。每个子队列均可用于写入处理结果，如至少一个子队列中的第一个子队列和第二子队列，在第一个子队列填满之后，再对第二个子队列进行处理结果的写入。示例性地，该子队列的数量可以是根据经验值预设的，如固定有10个子队列，该子队列的数量也可以是根据写入的处理结果实时调整的，如若每个子队列可写入10个处理结果，则每写入10个处理结果，第二类写队列在尾部新增一个子队列。第二类写队列的长度也可以根据写入的处理结果的数量自动调整。
示例性地，参考图13，其是本申请一个实施例提供的结果队列的示意图。结果队列1300包括第二类写队列1301和第二类读队列1302，第二类写队列1301和第二类读队列1302不相连，第二类写队列1301中的多个子队列首尾相连，每个子队列的长度可以相同。第二类读队列1302的长度可以与子队列的长度相同。
第二类写队列1301受写锁约束，第二类读队列1302不受锁约束。在有写线程想要将处理结果写入第二类写队列1301的情况下，若检测到已有其他写线程占用写锁，该写线程则等待该其他写线程释放写锁，在其他写线程释放写锁后，该写线程可占用写锁，将处理结果写入第二类写队列1301。若检测到写锁未被占用，该写线程则可直接占用写锁，将处理结果写入第二类写队列1301。
在有读线程想要读取第二类读队列1302中的处理结果的情况下，无论是否检测到已有其他读线程正在进行读操作，该读线程则均可直接读取第二类读队列1302中的处理结果。第二类读队列1302中的处理结果依次被调度模块所读取，如从第二类读队列1302的头部到尾部的顺序、从第二类读队列1302的尾部到头部的顺序。图13中的空白格子用于指示该位置处没有处理结果，相同填充图案的格子对应的处理结果对应有相同的读写集标识。
在一个示例中，初始状态下的结果队列包括一个第二类读写队列，该第二类读写队列受读写锁约束，读写锁约束下的第二类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作。
其中，第二类读写队列既用于虚拟机引擎写入事务信息，又用于调度模块读取事务信息。可选地，该第二类读写队列的长度可以与上述子队列的长度相同，也即初始状态下的结果队列仅包括一个子队列。
可选地，在写线程(即虚拟机引擎)想要将处理结果写入第二类读写队列的情况下，若检测到已有其他写线程/读线程占用读写锁，该写线程则等待该其他写线/读线程释放读写锁，在其他写线程/读线程释放读写锁后，该写线程可占用读写锁(即写锁)，将处理结果写入第二类读写队列。若检测到没有其他写线程，也没有读线程占用读写锁，该写线程则可直接占用读写锁(即写锁)，将处理结果写入第二类读写队列。
在读线程(即调度模块)想要从第二类读写队列中读取处理结果的情况下，若检测到已有其他写线程占用读写锁，该读线程则等待该其他写线释放读写锁，在其他写线程释放读写锁后，该读线程可占用读写锁(即读锁)，从第二类读写队列中读取处理结果。若检测到没有其他写线程占用读写锁或有读线程占用读写锁，该写线程则可直接占用读写锁(即读锁)，从第二类读写队列中读取处理结果。
可选地，在第二类读写队列被填满的情况下，初始状态下的结果队列可变更为上述状态下的结果队列(记为双向多组可排序结果队列，双向：读和写；多组：包括第二类读队列和第二类子队列；可排序：第二类读队列中的处理结果可排序)。示例性地，本申请实施例还可以包括如下内容：
1、将处理结果写入第二类读写队列。
可选地，虚拟机引擎可调用写线程占用读写锁，从上述多个事务信息对应的处理结果中的第一个处理结果开始，依次将处理结果写入第二类读写队列。
2、在第二类读写队列被填满的情况下，将第二类读写队列变更为第二类读队列，以及在第二类读队列之后添加第二类写队列，该第二类写队列与第二类读队列不相连。
其中，第二类读写队列被填满是指第二类读写队列对应的各个位置均被写入有处理结果。在将第二类读写队列变更为第二类读队列的同时，释放第二类读写队列对应的读写锁，并不为第二类读队列添加锁。在第二类读队列之后添加第二类写队列的同时，为第二类写队列添加写锁。
可选地，初始状态下的第二类写队列仅包括一个子队列，随着被写入的处理结果的数量的增多，第二类写队列扩展为包括多个子队列。
在一个示例中，在第二类写队列所包括的至少一个子队列被填满的情况下，在第二类写队列的尾部添加新的子队列，该新的子队列的头部与第二类写队列的尾部相连。
示例性地，在第二类写队列所包括的一个子队列被填满的情况下，在该子队列之后添加一个新的子队列；或者，在第二类写队列所包括的多个子队列被填满的情况下，在最后一个子队列之后添加一个新的子队列。该新的子队列的长度与第二类写队列所包括的子队列的长度相同。后续待被写入的处理结果可以被写入该新的子队列。随着被写入的处理结果的数量的增多，适应性增加新的子队列，可确保一个新区块所对应的所有事务信息的处理结果能够被写入到结果队列，以传输到调度模块，同时，多个子队列为第二类读队列与子队列之间的转换提供了基础。
本申请实施例，初始状态下结果队列设置为仅包含一个受读写锁约束的第二类读写队列，在处理结果数量较少时，可有效减少结果队列的管理工作量。随着处理结果增多，第二类读写队列被填满后，将其变更为第二类读队列，并添加第二类写队列，切换为双向多组可排序结果队列。这种动态调整方式既兼顾了低负载时的管理便捷性，又能在高负载时提高处理结果的传输效率，实现了根据处理结果负载灵活优化队列结构，提升了区块链节点处理处理结果的性能。
可选地，上述结果队列中的处理结果可排序，如第二类写队列中的处理结果可排序。示例性地，该排序可由虚拟机引擎实现，也可以由结果队列自行实现，本申请实施例对此不作限定。例如，虚拟机引擎在确定处理结果的写入位置后，可直接将其添加至第二类写队列中对应的写入位置，虚拟机引擎也可以仅将处理结果添加进第二类写队列，结果队列自行对该处理结果进行排序，也即自动确定该处理结果在第二类写队列中的写入位置。其中，写入位置是指处理结果在第二类写队列中被写入的位置。
对于虚拟机引擎和结果队列，写入位置的确定方法相同，下文以虚拟机引擎为例进行说明。在一个示例中，步骤1102b还可以包括如下内容：
1、获取处理结果的读写集标识，该读写集标识用于标识处理结果对应的事务信息的读写集，该读写集用于记录处理结果对应的事务信息，对区块链节点所在的区块链系统的状态数据的访问和修改情况。
可选地，虚拟机引擎根据处理结果对应的事务信息，确定处理该事务信息，以及该事务信息对应的处理结果所需的读写集，并获取该读写集的读写集标识，如读写集key。
2、根据处理结果的读写集标识，确定处理结果在第二类写队列中对应的写入位置。
在本申请实施例中，对于第二类写队列所包括的各个子队列，可基于处理结果的读写集标识，尽可能使得子队列中各个处理结果对应的读写集标识不相同，如此使得短时间内尽可能地处理具有不同的读写集标识的处理结果，以及访问不同的读写集，从而可避免由于同一个子队列中存在大量具有相同读写集标识的处理结果而导致的读写锁冲争抢问题(如访问相同的读写集时，可能存在的读写锁冲争抢)，进而提高了处理结果的处理效率，以及提高了区块链系统的事务处理性能。
示例性地，处理结果在第二类写队列中对应的写入位置的确定过程可以包括如下内容：
(1)对于各个子队列，将不存在读写集标识与该处理结果的读写集标识相同的子队列，确定为候选子队列。
可选地，以子队列为单位，将各个子队列对应的读写集标识，与该处理结果的读写集标识进行比对，得到候选子队列。
例如，参考图14，第二类写队列1301中包括4个子队列，第一个子队列对应有读写集key1至读写集key10，且每个位置上对应的读写集key均不相同。第二个子队列和第三个子队列也分别对应有读写集key1至读写集key10，第四个子队列对应有读写集key1至读写集key6，若待被写入的处理结果的读写集标识为读写集key7至读写集key10中的任意一个，则可将第四个子队列确定为候选子队列。
(2)将候选子队列中的第一个候选子队列确定为目标子队列。
可选地，在候选子队列的数量为1的情况下，可以直接将该候选子队列确定为目标子队列；在候选子队列的数量为2或2以上的数值的情况下，可将候选子队列中的第一个候选子队列确定为目标子队列。该目标子队列是指待被写入处理结果的子队列。例如，参考图14，可直接把第四个子队列确定为目标子队列。
(3)根据处理结果的读写集标识，确定该处理结果在目标子队列中的写入位置，其中，子队列中的各个处理结果按照读写集标识从小到大的顺序排列。
可选地，将处理结果的读写集标识，与目标子队列中的各个处理结果的读写集标识进行比对，若该处理结果的读写集标识，小于目标子队列中的第一个处理结果的读写集标识，则将目标子队列中的第一个位置确定为该处理结果的写入位置；若该处理结果的读写集标识，小于目标子队列中的第n个处理结果的读写集标识，且大于第n-1个处理结果的读写集标识，则将第n个处理结果对应的位置确定为该处理结果的写入位置，n为大于1的整数。
例如，参考图14，若待被写入的处理结果的读写集标识为读写集key7，则可将读写集标识为读写集key6的处理结果之后的位置确定为写入位置。
可选地，对于目标子队列中写入位置之后的各个处理结果，以及写入位置上原来的处理结果，可依次后移一个位置(即存储地址适应性变更)，以为上述处理结果留出写入位置，本申请实施例对此不作限定。
例如，参考图14，若第四个子队列中第五个位置对应的读写集标识为读写集key7，待被写入的处理结果的读写集标识为读写集key6，则第五个位置上原有的处理结果后移至第六个位置，将第五个位置确定为写入位置。
在一个示例中，若每个子队列中的各个位置，与读写集标识一一对应，则可直接将读写集标识对应的位置确定为写入位置。参考图14，若待被写入的处理结果的读写集标识为读写集key8，则可将第四个子队列中第8个位置确定为写入位置，本申请实施例对此不作限定。
本申请实施例对子队列中的各个处理结果的排序方式不作限定，子队列中的各个处理结果也可以按照读写集标识从大到小的顺序排列；子队列中的各个处理结果也可以无排列顺序，如此有利于减少处理结果的写入工作量，进而提高处理结果的传输效率。
(4)将处理结果在目标子队列中的写入位置，确定为处理结果在第二类写队列中对应的写入位置。
例如，参考图14，将处理结果在第四个子队列中的写入位置，确定为该处理结果在第二类写队列1301中对应的写入位置。
针对第二类写队列包括多个子队列的情况，通过确定候选子队列和目标子队列，并按照读写集标识从小到大的顺序确定处理结果在目标子队列中的写入位置。这种方式进一步优化了处理结果在第二类写队列中的存储和排列，使得不同读写集的处理结果能够更有序地分布在各个子队列中，减少了读写锁冲突，提高了处理结果的处理效率，增强了区块链系统的稳定性和性能。
3、根据写入位置，向第二类写队列写入处理结果。
可选地，将该处理结果写入该写入位置，以实现将该出处理结果写入第二类写队列。在本申请实施例中，优先填满排列靠前的子队列，以便于第二类读队列被清空时，替换第二类读队列进行处理结果的读取。
上述实施例中，通过获取处理结果的读写集标识，并根据该标识确定处理结果在第二类写队列中的写入位置。这样可以使处理结果在第二类写队列中按照读写集标识进行合理分布，避免不同处理结果对同一读写集的频繁争抢，保证了处理结果写入的高效性和稳定性，从而提高了区块链系统处理事务信息及生成新区块的整体效率。
在一个示例中，在第二类写队列中不存在候选子队列的情况下，在第二类写队列的尾部增加新的子队列；将处理结果写入新的子队列的头部。
本实施例中，当第二类写队列中不存在候选子队列时，在队列尾部增加新的子队列，并将处理结果写入新子队列的头部。这种处理方式可以尽可能地使各个子队列中的读写集标识不同，避免了读写锁争抢问题，提高了处理结果的处理效率，保证了区块链系统能够高效地处理大量的事务信息。
例如，参考图14，若待被写入的处理结果的读写集标识为读写集key1至读写集key6中的任意一个，则可在第四个子队列之后加新的子队列，以作为候选子队列，以及可直接将该处理结果写入新的子队列的头部。如此通过新增子队列，可尽可能地使得各个子队列中的读写集标识不同。
在一个示例中，在第二类读队列中的处理结果被清空的情况下，本申请实施例还可以包括如下内容：
1、将第二类读队列移动至第二类写队列的尾部，以及将第二类读队列变更为新的子队列，得到新的第二类写队列。
将第二类读队列移动至第二类写队列的尾部，是指将第二类读队列添加在第二类写队列中的最后一个子队列之后，并将第二类读队列与该最后一个子队列相连接。新的第二类写队列用于虚拟机引擎写入处理结果，如移动后的第一类读队列(即新的子队列)为目标子队列，则可以将处理结果写入移动后的第一类读队列。
可选地，在将第二类读队列移动至第二类写队列的尾部之后，可对该第二类读队列添加写锁，以实现将该第二类读队列转换为新的子队列，从而得到新的第二类写队列。新的第二类写队列用于区块链节点的虚拟机引擎写入处理结果。
第二类读队列中的处理结果被清空，是指第二类读队列中的所有处理结果均被调度模块所读取，在第二类读队列中的处理结果被调度模块所读取后，虚拟机引擎自动对该处理结果进行删除，以腾出位置。
2、将第二类读队列中的第一个子队列变更为新的第二类读队列。
可选地，将第一个子队列与第二类写队列中的第二个子队列断开连接，并解除第一个子队列的写锁，从而将第一个子队列变更为新的第二类读队列。新的第二类读队列用于调度模块读取处理结果，也即调度模块将切换为从该新的第二类读队列中读取处理结果。
本实施例中，在第二类读队列中的处理结果被清空的情况下，进行子队列和第二类读队列的切换操作，即将第二类读队列移动至第二类写队列的尾部并变更为新的子队列，同时将第二类读队列中的第一个子队列变更为新的第二类读队列。这种切换方式有利于继续避免读写锁争抢问题，使得写操作在新的第二类写队列进行，读操作在新的第二类读队列进行，保证了处理结果的传输过程不受干扰。并且，该机制极大地提高了处理结果的传输效率，使区块链节点能够持续高效地处理和传输处理结果，确保了区块链系统中事务处理结果流转的流畅性和稳定性，进一步提升了整个区块链系统的性能和可靠性。
可选地，在子队列和第二类读队列的切换过程中，禁止针对处理结果的所有写操作和读操作，以避免处理结果传输错误。第二类写队列中的子队列和第二类读队列的切换过程，与上述第一类写队列中的子队列和第一类读队列的切换过程相同，本申请实施例未说明的内容，可以参考上述实施例，这里不再赘述。
在一个示例中，在一个批量处理结果(即新区块对应的所有事务信息的处理结果)被传输完成后，结果队列可以保留一个子队列(即恢复到初始状态)，以进行下一批量处理结果的传输，如此有利于降低结果队列对传输资源的占用。
在一个示例中，第二类读队列也可以包括少量的子队列，如2个、3个等，如此有利于降低子队列与第二类读队列之间切换频率，进而降低结果队列的管理工作量。同时，可保证处理结果的稳定读取，以及降低读取等待时长，进而提高处理结果的读取效率。
调度模块，用于将已处理的多个事务信息打包成新区块，以及将新区块和处理结果发送给共识模块，以完成新区块和处理结果的共识。
综上，采用本申请实施例提供的技术方案，在事务信息在区块链节点中传递的过程中，通过将事务队列设置为两类队列：写队列用于写入事务信息，读队列用于读取事务信息，且写队列受写锁约束，从而保证了事务信息的同步一致性，读队列不受锁约束，避免了针对事务信息的读操作受针对事务信息的写操作的影响，也避免了针对事务信息的写操作针对事务信息的读操作的影响，有效提高了针对事务信息的写操作的效率，以及针对事务信息的读操作的效率，从而提高了事务信息在区块链节点中的传递效率，进而提高了事务信息在区块链节点中的处理效率。
另外，在处理结果在区块链节点中传递的过程中，通过将结果队列设置为两类队列：写队列用于写入处理结果，读队列用于读取处理结果，且写队列受写锁约束，从而保证了处理结果的同步一致性，读队列不受锁约束，避免了针对处理结果的读操作受针对处理结果的写操作的影响，也避免了针对处理结果的写操作受针对处理结果的读操作的影响，有效提高了针对处理结果的写操作的效率，以及针对处理结果的读操作的效率，从而提高了处理结果在区块链节点中的传递效率，进而提高了处理结果在区块链节点中的处理效率。
下文将对事务池模块、虚拟机引擎和调度模块之间的交互过程进行说明，本申请实施例未说明的内容，可参考上述实施例。
1、事务池模块，用于接收调度模块所发送的事务信息发送请求，该事务信息发送请求用于请求事务池模块开始发送事务信息。
2、事务池模块，用于响应于事务信息发送请求，确定事务池模块存储的多个事务信息。
3、事务池模块，用于在用于传输事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将事务信息写入第一类写队列，该第一类写队列受写锁约束，该写锁约束下的第一类写队列同一个时刻仅允许单个线程进行多个事务信息中事务信息的写操作，第一类读队列不受锁约束。
在一个示例中，事务池模块，还用于获取事务信息的合约名和到达时间，该合约名是指用于事务处理事务信息的智能合约的名称，到达时间是指事务信息到达事务池模块的时间；根据事务信息的合约名，确定事务信息在第一类写队列中对应的写入区域，该写入区域内的事务信息的合约名，与事务信息的合约名相同；根据事务信息的到达时间，从写入区域中确定事务信息的写入位置，该写入区域内的事务信息按照到达时间从先到后的顺序排列；根据写入位置，向第一类写队列写入事务信息。
在一个示例中，事务池模块，还用于获取第一类写队列中各个事务组的事务数量，该事务组是以合约名聚类得到的，事务数量用于指示事务组中用于事务处理的事务信息的数量；按照事务数量从大到小的顺序，对各个事务组进行排序，得到调整后的第一类写队列。
在一个示例中，事务池模块，还用于获取第一类写队列中各个事务组的最早到达时间，该事务组是以合约名聚类得到的，最早到达时间是指事务组中各个用于事务处理的事务信息对应的最早的到达时间；按照最早到达时间从先到后的顺序，对各个事务组进行排序，得到调整后的第一类写队列。
在一个示例中，事务池模块，还用于在第一类写队列中不存在合约名与事务信息的合约名相同的事务信息的情况下，在第一类写队列中的最后一个事务信息之后，写入事务信息。
在一个示例中，上述第一类写队列包括至少一个子队列，每个子队列依次首尾相连；事务池模块，还用于在至少一个子队列被填满的情况下，在第一类写队列的尾部添加新的子队列，该新的子队列的头部与第一类写队列的尾部相连。
在一个示例中，初始状态下的事务队列包括一个第一类读写队列，第一类读写队列受读写锁约束，读写锁约束下的第一类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作；事务池模块，还用于将事务信息写入第一类读写队列；在第一类读写队列被填满的情况下，将第一类读写队列变更为第一类读队列，以及在第一类读队列之后添加第一类写队列，第一类写队列与第一类读队列不相连。
在一个示例中，事务池模块，还用于在第一类读队列中的事务信息被清空的情况下，将第一类读队列移动至第一类写队列的尾部，以及将第一类读队列变更为新的子队列，得到新的第一类写队列；将第一类读队列中的第一个子队列变更为新的第一类读队列；其中，新的第一类读队列用于虚拟机引擎获取事务信息，新的第一类写队列用于事务池模块写入事务信息。
4、虚拟机引擎，用于从第一类读队列中读取多个事务信息；对这些多个事务信息进行事务处理，得到多个事务信息各自对应的处理结果。
5、虚拟机引擎，用于将多个事务信息，以及多个事务信息对应的处理结果发送给调度模块。
在一个示例中，虚拟机引擎，还用于将经事务处理后的多个事务信息按照事务队列的方式发送给调度模块；在用于传输处理结果的结果队列包括第二类读队列和第二类写队列的情况下，将处理结果写入第二类写队列，第二类写队列受写锁约束，写锁约束下的第二类写队列同一个时刻仅允许单个线程进行处理结果的写操作，第二类读队列用于调度模块读取处理结果，第二类写队列同一个时刻允许多个线程并行进行读操作。
在一个示例中，虚拟机引擎，还用于获取经事务处理后处理结果的读写集标识，该读写集标识用于标识处理结果对应的事务信息的读写集，该读写集用于记录处理结果对应的事务信息，对区块链节点所在的区块链系统的状态数据的访问和修改情况；根据处理结果的读写集标识，确定处理结果在第二类写队列中对应的写入位置；根据写入位置，向第二类写队列写入处理结果。
在一个示例中，上述第二类写队列包括至少一个子队列，每个子队列依次首尾相连；虚拟机引擎，还用于对于各个子队列，将不存在读写集标识与处理结果的读写集标识相同的子队列，确定为候选子队列；将候选子队列中的第一个候选子队列确定为目标子队列；根据处理结果的读写集标识，确定处理结果在目标子队列中的写入位置，其中，子队列中的各个处理结果按照读写集标识从小到大的顺序排列；将处理结果在目标子队列中的写入位置，确定为处理结果在第二类写队列中对应的写入位置。
在一个示例中，虚拟机引擎，还用于在第二类写队列中不存在候选子队列的情况下，在第二类写队列的尾部增加新的子队列；将处理结果写入新的子队列的头部。
在一个示例中，初始状态下的结果队列包括一个第二类读写队列，该第二类读写队列受读写锁约束，读写锁约束下的第二类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作；虚拟机引擎，还用于将处理结果写入第二类读写队列；在第二类读写队列被填满的情况下，将第二类读写队列变更为第二类读队列，以及在第二类读队列之后添加第二类写队列，该第二类写队列与第二类读队列不相连。
在一个示例中，虚拟机引擎，还用于在第二类读队列中的处理结果被清空的情况下，将第二类读队列移动至第二类写队列的尾部，以及将第二类读队列变更为新的子队列，得到新的第二类写队列；将第二类读队列中的第一个子队列变更为新的第二类读队列；其中，新的第二类读队列用于调度模块读取处理结果，新的第二类写队列用于区块链节点的虚拟机引擎写入处理结果。
6、调度模块，用于将多个事务信息打包成新区块。
在一些实施例中，参考图15，一个新区块的完整的事务处理过程可以包括如下内容：
1.用户通过客户端发起一笔事务请求。
该事务请求用于请求执行事务，客户端根据该事务请求生成事务数据。
2.用户对事务请求对应的事务信息进行签名。
用户可通过客户端完成事务信息的签名，客户端可根据用户的签名，生成签名数据。
3.用户将事务数据和签名数据发送到区块链节点上。
可选地，用户可通过客户端将事务数据和签名数据，一同发送到与该客户端相连接的区块链节点上。
4.区块链节点接收到事务数据和签名数据。
区块链节点可通过网络模块接收到事务数据和签名数据。
5.区块链节点进行证书和签名验证。
区块链节点可通过验证模块，对事务数据进行证书和签名验证。若证书和签名验证通过，则转到7，若证书和签名验证未通过，则转到6。
6.向客户端返回验证不通过的结果，并结束。
7.区块链节点进行权限验证。
区块链节点可通过验证模块，对事务数据进行权限验证。若权限验证通过，则转到9，若未验证通过，则转到8。
8.向客户端返回权限验证不通过的结果，并结束。
9.将事务数据放入事务池模块。
10.区块链节点准备产生新区块。
区块链节点可基于调度模块准备所需产生的新区块，如为新区块准备区块头和区块主体。该区块链节点可被称之为主节点。
11.调度模块向事务池模块发送事务信息发送请求。
该事务信息发送请求用于请求区块链节点中的事务池模块开始发送，要打包进新区块的多个事务信息。
12.事务池模块向事务队列中添加事务信息。
事务池模块可通过事务队列发送器，将上述多个事务信息依次写入事务队列。
13.事务队列的队列数是否为1。
若事务队列的队列数为1，则转到14，若事务队列的队列数不为1，则转到17。
14.将事务队列确定为第一类读写队列。
也即事务池模块发送事务信息，以及虚拟机引擎读取事务信息，均在这个第一类读写队列中进行，针对事务信息的读操作和写操作均需要加锁(如读写锁)。
15.事务池模块获取第一类读写队列的写锁。
16.事务池模块将事务信息放入事务队列，转到20。
17.将事务队列确定为第一类读队列和第一类写队列。
第一类读队列用于虚拟机引擎读取事务信息，第一类写队列用于事务池模块写入事务信息，第一类写队列受写锁约束，第一类读队列不受锁约束。
第一类写队列中的各个子队列首尾相连，第一排序规则为事务信息的合约名，且尽量保证事务数量较大的合约组排在第一类写队列中的前面，如此可避免虚拟机引擎频繁切换智能合约的运行。第二排序规则为事务信息的到达时间，且尽量保证到达时间较早的事务信息排在合约组的前面，以保证事务信息的处理及时性。
18.事务池模块获取第一类写队列的写锁。
19.事务池模块将事务信息写入第一类写队列。
事务池模块可通过事务队列发送器将事务信息写入第一类写队列，第一类写队列自动对写入的事务信息进行排序。
20.虚拟机引擎获取读锁。
对于第一类读写队列，虚拟机引擎获取第一类读写队列的读锁，以便读取用于事务处理的事务信息。
21.虚拟机引擎读取事务信息，并对这些事务信息进行事务处理以获取处理结果。
当虚拟机引擎想要从第一类读写队列中读取事务信息时，若检测到已有其他写线程占用读锁，该虚拟机引擎则等待该其他写线程释放读锁，在其他写线程释放读锁后，该虚拟机引擎可占用读锁，从第一类读写队列中读取事务信息。对于第一类读队列，由于其不受锁约束，虚拟机引擎可通过事务队列读取器，直接从第一类读队列中读取事务信息。
22.虚拟机引擎将处理结果写入结果队列。
虚拟机引擎可通过结果队列发送器，将处理结果写入结果队列中的第二类写队列。结果队列的数据结构、读写锁和用法，分别与事务队列的数据结构、读写锁和用法相同，但排序规则不同，结果队列主要按照事务信息的读写集key进行区分性排序，也即对于第二类写队列中的各个子队列，尽量保证子队列中的各个事务信息的读写集key不同，从而避免出现锁争抢带来的耗时。
23.调度模块从结果队列中读取处理结果。
调度模块可通过结果队列读取器，从结果队列中的第二类读队列中读取事务信息的处理结果。
24.调度模块将处理结果放到共识区块中。
25.上述多个事务信息处理完成时，主节点将新区块发送给所有从节点，以进行共识。
上述多个事务信息处理完成时，调度模块可将处理后的多个事务信息打包成新区块。
26.从节点是否共识通过。
若共识通过，则转到27，若共识未通过则结束。
27.所有区块链节点将新区块存储到区块链中。
28.所有区块链节点将状态数据存储到状态数据库中。
其中，状态数据可基于处理结果进行更新。结束。
在一些实施例中，可将上述事务队列和结果队列统称为双向多组可排序队列，第一类写队列和第二类写队列统称为写队列，第一类读队列和第二类读队列统称为读队列。参考图16，以虚拟机引擎获取事务信息为例，写队列和读队列的动态切换过程可以包括如下内容。
1.虚拟机引擎读取双向多组可排序队列中的读队列。
2.读队列是否为空。
即检测读队列是否被清空。若读队列为空，则转到3，若读队列不为空，则转到1。
3.双向多组可排序队列中的写队列是否为空。
若写队列为空，则转到4，若写队列不为空，则转到6。
4.多个事务信息是否全部执行完成。
若多个事务信息全部执行完成，则结束，若多个事务信息未全部执行完成，则转到5。该多个事务信息用于打包成新区块。
5.等待双向多组可排序队列中出现新事务信息。
6.队列开始加锁，禁止所有写操作和读操作。
即在检测到读队列被清空的情况下，可开始读队列和写队列的转换，此时无论虚拟机引擎还是事务池模块，均无法对双向多组可排序队列进行操作。
7.队列开始轮换，将读队列切换为写队列的最后一个子队列，将写队列的第一个子队列切换为读队列。
8.队列总数是否为1。
队列总数是指双向多组可排序队列中所有子队列的总数。若队列总数为1，则转到9，若队列总数不为1，则转到10。
9.将双向多组可排序队列确定为读写队列，转到11。
即双向多组可排序队列受读写锁约束，即可用于写入事务信息，又可用于读取事务信息。
10.继续采用读写分离的模式进行事务信息的传输。
即除一个读队列以外，剩余的队列均是写队列，且剩余的队列首尾相连并受写锁约束，而读队列不受锁约束。
11.队列解除加锁，转到1。
即此时无论虚拟机引擎还是事务池模块，均可对双向多组可排序队列进行操作。结束。
在一些实施例中，本申请实施例提供的技术方案至少可应于下述几个场景中：
1、高性能金融事务处理：金融事务处理对实时性、安全性和吞吐量有较高要求。本申请实施例提供的技术方案能够使得区块链系统更高效地处理事务信息，从而提高事务信息的处理性能，降低智能合约运行时切换成本和减少读写锁冲突。因此，本申请实施例提供的技术方案非常适合高性能金融事务处理场景，如证券事务、支付结算、跨境汇款等。
2、供应链金融与物流管理：供应链金融与物流管理涉及多方参与，对数据一致性和实时性有较高要求。本申请实施例提供的技术方案可以确保事务处理的高效性和实时性，有利于提高整个供应链金融与物流管理系统的运行效率。应用场景包括供应链融资、货物追随、仓储管理等。
3、物联网数据处理：物联网设备产生的数据量巨大，对数据处理能力有较高要求。本申请实施例提供的技术方案通过双向多组可排序队列(如事务队列和结果队列)的读写锁解耦机制、动态轮换机制和优化排序策略，提高区块链系统在物联网数据处理场景的性能。应用场景包括智能家居、智能交通、智能工厂等。
4、跨行业数据共享与隐私保护：跨行业数据共享与隐私保护涉及多方数据交换，对数据处理能力和数据安全性有较高要求。本申请实施例提供的技术方案可以提高区块链系统在处理跨行业数据共享与隐私保护场景的性能，同时确保数据的一致性和安全性。应用场景包括医疗数据共享、征信数据共享、知识产权保护等。
综上，采用本申请实施例提供的技术方案，在事务信息在区块链节点中传递的过程中，通过将事务队列设置为两类队列：写队列用于写入事务信息，读队列用于读取事务信息，且写队列受写锁约束，从而保证了事务信息的同步一致性，读队列不受锁约束，避免了针对事务信息的读操作受针对事务信息的写操作的影响，也避免了针对事务信息的写操作针对事务信息的读操作的影响，有效提高了针对事务信息的写操作的效率，以及针对事务信息的读操作的效率，从而提高了事务信息在区块链节点中的传递效率，进而提高了事务信息在区块链节点中的处理效率。
另外，在处理结果在区块链节点中传递的过程中，通过将结果队列设置为两类队列：写队列用于写入处理结果，读队列用于读取处理结果，且写队列受写锁约束，从而保证了处理结果的同步一致性，读队列不受锁约束，避免了针对处理结果的读操作受针对处理结果的写操作的影响，也避免了针对处理结果的写操作受针对处理结果的读操作的影响，有效提高了针对处理结果的写操作的效率，以及针对处理结果的读操作的效率，从而提高了处理结果在区块链节点中的传递效率，进而提高了处理结果在区块链节点中的处理效率。
本申请的区块链节点事务信息处理方法涉及调度模块、事务池模块和虚拟机引擎三个主要模块，其工作流如下：
调度模块触发。调度模块根据预设规则(如时间间隔或事务数量)判定生成新区块的时机，生成事务信息发送请求，告知事务池模块开始发送事务信息。
事务池模块处理事务信息。确定待处理事务：事务池模块接收请求后，依据请求中的标识、创建时间或当前打包时间段等，确定事务池模块存储的多个事务信息。写入事务队列：初始时，事务队列包含受读写锁约束的第一类读写队列，事务池模块调用写线程将事务信息依次写入。当第一类读写队列被填满，将其变更为第一类读队列，并在其后添加受写锁约束的第一类写队列。事务信息排序：事务池模块获取事务信息的合约名和到达时间，根据合约名确定写入区域，使同一区域内事务由同一智能合约处理；再根据到达时间在写入区域内确定写入位置，优先处理早到达的事务。此外，还可基于事务组的事务数量或最早到达时间对事务组排序。队列动态调整：当第一类写队列的子队列被填满，在尾部添加新子队列；当第一类读队列中的事务信息被清空，将其移动至第一类写队列尾部变为新子队列，同时将第一类写队列的第一个子队列变为新的第一类读队列。
虚拟机引擎处理事务。读取事务信息：由于第一类读队列不受锁约束，虚拟机引擎可并行使用线程从中读取事务信息。执行智能合约处理：对读取的事务信息进行事务处理，得到处理结果。传输事务信息和结果：将处理后的事务信息按事务队列方式发送给调度模块；对于处理结果，在结果队列包括第二类读队列和第二类写队列时，将其写入受写锁约束的第二类写队列。结果队列管理：虚拟机引擎获取处理结果的读写集标识，确定其在第二类写队列的写入位置，使子队列中处理结果的读写集标识尽量不同，减少读写锁争抢。当第二类写队列无合适候选子队列，在尾部增加新子队列；当第二类读队列中的处理结果被清空，进行队列切换，操作与事务队列类似。
调度模块打包新区块。调度模块接收虚拟机引擎发送的多个事务信息和处理结果，基于处理结果将事务信息打包成新区块，然后将新区块和处理结果发送给共识模块，完成共识后更新区块链和状态数据。
本申请的效果如下：
提高事务信息传输效率：采用读写分离的队列设计，事务队列分为受写锁约束的第一类写队列和不受锁约束的第一类读队列，结果队列分为受写锁约束的第二类写队列和不受锁约束的第二类读队列。这种设计避免了读写操作的相互影响，虚拟机引擎可并行读取无锁的读队列，事务池模块和虚拟机引擎只需占用写锁依次写入信息，提高了事务信息和处理结果的读写效率，进而提升了在区块链节点中的传递效率。
降低智能合约切换成本：事务信息按合约名和到达时间排序，同一写入区域内的事务由同一智能合约处理，减少了智能合约的频繁切换，降低了切换成本和响应耗时，提高了事务信息的处理效率。
减少读写锁冲突：通过合理设计队列结构和排序规则，如结果队列按读写集标识排序，使子队列中处理结果的读写集标识尽量不同，避免了因访问相同读写集导致的读写锁争抢问题，提高了处理结果的处理效率和区块链系统的事务处理性能。
优化队列管理：初始状态下队列结构简单，随着事务或处理结果数量增加，动态调整为双向多组可排序队列，并根据队列状态进行子队列和读队列的切换，既能在低负载时减少管理工作量，又能在高负载时提高传输效率，实现了根据负载灵活优化队列结构。
增强系统稳定性和适应性：整个事务处理流程中，各模块协同工作，确保了区块链网络能够准确、及时地处理大量事务信息，维持网络正常运行，适用于高性能金融事务处理、供应链金融与物流管理、物联网数据处理、跨行业数据共享与隐私保护等多种场景。
请参考图17，其是本申请一个实施例提供的计算机设备的结构框图。该计算机设备可实现为上述区块链节点。
通常，计算机设备1700包括有：处理器1701和存储器1702。
处理器1701可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1701可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1701也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central Processing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1701可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1701还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。
存储器1702可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是有形的和非暂态的。存储器1702还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1702中的非暂态的计算机可读存储介质存储有计算机程序，该计算机程序由处理器1701加载并执行以实现上述各方法实施例提供的应用于区块链节点的事务信息处理方法。
本申请实施例还提供一种计算机可读存储介质，该存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现上述各方法实施例提供的应用于区块链节点的事务信息处理方法。
该计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM(Random Access Memory，随机存取存储器)、ROM(Read-Only Memory，只读存储器)、EPROM(Erasable Programmable Read-Only Memory，可擦写可编程只读存储器)、EEPROM(Electrically Erasable Programmable Read-Only Memory，电可擦写可编程只读存储器)、闪存或其他固态存储技术，CD-ROM、DVD(Digital Video Disc，高密度数字视频光盘)或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知该计算机存储介质不局限于上述几种。
本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，处理器从所述计算机可读存储介质读取并执行所述计算机程序，以实现上述各方法实施例提供的应用于区块链节点的事务信息处理方法。
需要说明的是，本申请实施例在收集用户的相关数据之前以及在收集用户的相关数据的过程中，都可以显示提示界面、弹窗或输出语音提示信息，该提示界面、弹窗或语音提示信息用于提示用户当前正在搜集其相关数据，使得本申请仅仅在获取到用户对该提示界面或者弹窗发出的确认操作后，才开始执行获取用户相关数据的相关步骤，否则(即未获取到用户对该提示界面或者弹窗发出的确认操作时)，结束获取用户相关数据的相关步骤，即不获取用户的相关数据。换句话说，本申请所采集的所有用户数据，处理严格根据相关国家法律法规的要求，获取个人信息主体的知情同意或单独同意都是在用户同意并授权的情况下进行采集的，并在法律法规及个人信息主体的授权范围内，开展后续数据使用及处理行为且相关用户数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。例如，本申请中涉及到的事务信息等都是在充分授权的情况下获取的。
应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同切换、改进等，均应包含在本申请的保护范围之内。
以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (18)

  1. 一种应用于区块链节点的事务信息处理方法，其特征在于，所述区块链节点包含调度模块、事务池模块和虚拟机引擎，所述方法包括：
    接收所述调度模块所发送的事务信息发送请求，所述事务信息发送请求用于请求所述事务池模块开始发送事务信息；
    响应于所述事务信息发送请求，确定所述事务池模块存储的多个事务信息；及
    在用于传输所述多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将所述多个事务信息写入所述第一类写队列，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作，所述第一类读队列用于供所述虚拟机引擎读取所述多个事务信息中的事务信息，对所述多个事务信息进行事务处理获得处理结果，所述多个事务信息和所述处理结果用于指示所述调度模块基于所述处理结果将所述多个事务信息打包成新区块。
  2. 根据权利要求1所述的方法，其特征在于，所述将所述多个事务信息写入所述第一类写队列，包括：
    获取所述事务信息的合约名和到达时间，所述合约名是指用于处理所述事务信息的智能合约的名称，所述到达时间是指所述事务信息到达所述事务池模块的时间；
    根据所述事务信息的合约名，确定所述事务信息在所述第一类写队列中对应的写入区域，所述写入区域内的事务信息的合约名，与所述事务信息的合约名相同；
    根据所述事务信息的到达时间，从所述写入区域中确定所述事务信息的写入位置，所述写入区域内的事务信息按照所述到达时间从先到后的顺序排列；
    根据所述写入位置，向所述第一类写队列写入所述事务信息。
  3. 根据权利要求2所述的方法，其特征在于，所述根据所述写入位置，向所述第一类写队列写入所述事务信息之后，还包括：
    获取所述第一类写队列中各个事务组的事务数量，所述事务组是以所述合约名聚类得到的，所述事务数量用于指示所述事务组中的事务信息的数量；
    按照所述事务数量从大到小的顺序，对所述各个事务组进行排序，得到调整后的所述第一类写队列。
  4. 根据权利要求2所述的方法，其特征在于，所述根据所述写入位置，向所述第一类写队列写入所述事务信息之后，还包括：
    获取所述第一类写队列中各个事务组的最早到达时间，所述事务组是以所述合约名聚类得到的，所述最早到达时间是指所述事务组中各个事务信息对应的最早的到达时间；
    按照所述最早到达时间从先到后的顺序，对所述各个事务组进行排序，得到调整后的所述第一类写队列。
  5. 根据权利要求2-4任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一类写队列中不存在合约名与所述事务信息的合约名相同的事务信息的情况下，在所述第一类写队列中的最后一个事务信息之后，写入所述事务信息。
  6. 根据权利要求1-5任一项所述的方法，其特征在于，所述第一类写队列包括至少一个子队列，每个子队列依次首尾相连；所述方法还包括：
    在所述至少一个子队列被填满的情况下，在所述第一类写队列的尾部添加新的子队列，所述新的子队列的头部与所述第一类写队列的尾部相连。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，初始状态下的所述事务队列包括一个第一类读写队列，所述第一类读写队列受读写锁约束，所述读写锁约束下的所述第一类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作；
    所述将所述多个事务信息写入所述第一类写队列之前，还包括：
    将所述多个事务信息写入所述第一类读写队列；
    在所述第一类读写队列被填满的情况下，将所述第一类读写队列变更为所述第一类读队列，以及在所述第一类读队列之后添加所述第一类写队列，所述第一类写队列与所述第一类读队列不相连。
  8. 根据权利要求1-7任一项所述的方法，其特征在于，所述将所述多个事务信息写入所述第一类写队列之后，还包括：
    在所述第一类读队列中的事务信息被清空的情况下，将所述第一类读队列移动至所述第一类写队列的尾部，以及将所述第一类读队列变更为新的子队列，得到新的第一类写队列；
    将所述第一类读队列中的第一个子队列变更为新的第一类读队列；
    其中，所述新的第一类读队列用于所述虚拟机引擎获取所述事务信息，所述新的第一类写队列用于所述事务池模块写入所述事务信息。
  9. 一种应用于区块链节点的事务信息处理方法，其特征在于，所述区块链节点包含调度模块、事务池模块和虚拟机引擎，所述方法包括：
    在用于传输事务信息的事务队列包括第一类读队列和第一类写队列的情况下，从所述第一类读队列中读取多个事务信息，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作，所述第一类写队列中的所述多个事务信息由所述事务池模块写入，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作；
    对所述多个事务信息进行事务处理，得到所述多个事务信息各自对应的处理结果；及
    将所述多个事务信息和所述处理结果发送给所述调度模块，所述多个事务信息和所述处理结果用于指示所述调度模块基于所述处理结果将所述多个事务信息打包成新区块。
  10. 根据权利要求9所述的方法，其特征在于，所述将所述多个事务信息和所述处理结果发送给所述调度模块，包括：
    将所述多个事务信息按照所述事务队列的方式发送给所述调度模块；
    在用于传输所述处理结果的结果队列包括第二类读队列和第二类写队列的情况下，将所述处理结果写入所述第二类写队列，所述第二类写队列受写锁约束，所述写锁约束下的所述第二类写队列同一个时刻仅允许单个线程进行所述处理结果的写操作，所述第二类读队列用于所述调度模块获取所述处理结果，所述第二类读队列同一个时刻允许多个线程并行进行读操作。
  11. 根据权利要求10所述的方法，其特征在于，所述将所述处理结果写入所述第二类写队列，包括：
    获取所述处理结果的读写集标识，所述读写集标识用于标识所述处理结果对应的事务信息的读写集，所述读写集用于记录所述处理结果对应的事务信息，对所述区块链节点所在的区块链系统的状态数据的访问和修改情况；
    根据所述处理结果的读写集标识，确定所述处理结果在所述第二类写队列中对应的写入位置；
    根据所述写入位置，向所述第二类写队列写入所述处理结果。
  12. 根据权利要求11所述的方法，其特征在于，所述第二类写队列包括至少一个子队列，每个子队列依次首尾相连；
    所述根据所述处理结果的读写集标识，确定所述处理结果在所述第二类写队列中对应的写入位置，包括：
    对于各个所述子队列，将不存在读写集标识与所述处理结果的读写集标识相同的子队列，确定为候选子队列；
    将所述候选子队列中的第一个候选子队列确定为目标子队列；
    根据所述处理结果的读写集标识，确定所述处理结果在所述目标子队列中的写入位置，其中，所述子队列中的各个处理结果按照所述读写集标识从小到大的顺序排列；
    将所述处理结果在所述目标子队列中的写入位置，确定为所述处理结果在所述第二类写队列中对应的写入位置。
  13. 根据权利要求12所述的方法，其特征在于，所述方法还包括：
    在所述第二类写队列中不存在所述候选子队列的情况下，在所述第二类写队列的尾部增加新的子队列；
    将所述处理结果写入所述新的子队列的头部。
  14. 根据权利要求10所述的方法，其特征在于，初始状态下的所述结果队列包括一个第二类读写队列，所述第二类读写队列受读写锁约束，所述读写锁约束下的所述第二类读写队列同一个时刻仅允许单个线程进行写操作，以及同一个时刻允许多个线程并行进行读操作；
    所述将所述处理结果写入所述第二类写队列之前，还包括：
    将所述处理结果写入所述第二类读写队列；
    在所述第二类读写队列被填满的情况下，将所述第二类读写队列变更为所述第二类读队列，以及在所述第二类读队列之后添加所述第二类写队列，所述第二类写队列与所述第二类读队列不相连。
  15. 根据权利要求10所述的方法，其特征在于，所述将所述处理结果写入所述第二类写队列之后，还包括：
    在所述第二类读队列中的处理结果被清空的情况下，将所述第二类读队列移动至所述第二类写队列的尾部，以及将所述第二类读队列变更为新的子队列，得到新的第二类写队列；
    将所述第二类读队列中的第一个子队列变更为新的第二类读队列；
    其中，所述新的第二类读队列用于所述调度模块获取所述处理结果，所述新的第二类写队列用于所述区块链节点的虚拟机引擎写入所述处理结果。
  16. 一种区块链节点，其特征在于，所述区块链节点包含事务池模块、虚拟机引擎和调度模块；
    所述事务池模块，用于接收所述调度模块所发送的事务信息发送请求，所述事务信息发送请求用于请求所述事务池模块开始发送事务信息；响应于所述事务信息发送请求，确定所述事务池模块存储的多个事务信息；在用于传输所述多个事务信息的事务队列包括第一类读队列和第一类写队列的情况下，将所述多个事务信息写入所述第一类写队列，所述第一类写队列受写锁约束，所述写锁约束下的所述第一类写队列同一个时刻仅允许单个线程进行所述多个事务信息中事务信息的写操作，所述第一类读队列同一个时刻允许多个线程并行进行所述多个事务信息中事务信息的读操作；
    所述虚拟机引擎，用于从所述第一类读队列中读取所述多个事务信息；对所述多个事务信息进行事务处理，得到所述多个事务信息各自对应的处理结果；将所述多个事务信息和所述处理结果发送给所述调度模块；
    所述调度模块，用于基于所述处理结果将所述多个事务信息打包成新区块。
  17. 一种计算机可读存储介质，其特征在于，所述存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现如权利要求1至8任一项所述的应用于区块链节点的事务信息处理方法，或者，如权利要求9至15任一项所述的应用于区块链节点的事务信息处理方法。
  18. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，处理器从所述计算机可读存储介质读取并执行所述计算机程序，以实现如权利要求1至8任一项所述的应用于区块链节点的事务信息处理方法，或者，如权利要求9至15任一项所述的应用于区块链节点的事务信息处理方法。
PCT/CN2025/076884 2024-03-06 2025-02-11 区块链节点及应用于区块链节点的事务信息处理方法 Pending WO2025185409A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410261087.1A CN120614366A (zh) 2024-03-06 2024-03-06 区块链节点及应用于区块链节点的交易处理方法
CN202410261087.1 2024-03-06

Publications (2)

Publication Number Publication Date
WO2025185409A1 true WO2025185409A1 (zh) 2025-09-12
WO2025185409A8 WO2025185409A8 (zh) 2025-10-02

Family

ID=96929396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/076884 Pending WO2025185409A1 (zh) 2024-03-06 2025-02-11 区块链节点及应用于区块链节点的事务信息处理方法

Country Status (2)

Country Link
CN (1) CN120614366A (zh)
WO (1) WO2025185409A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115114311A (zh) * 2022-06-15 2022-09-27 深圳市腾讯计算机系统有限公司 一种事务执行方法以及相关装置
WO2023070925A1 (zh) * 2021-10-28 2023-05-04 湖南天河国云科技有限公司 区块链交易池的分片方法、系统、存储介质和计算机系统
CN116561137A (zh) * 2022-01-28 2023-08-08 腾讯科技（深圳）有限公司 事务处理方法、装置、计算机设备及存储介质
CN117596298A (zh) * 2023-11-24 2024-02-23 南方电网数字电网集团信息通信科技有限公司 一种数据处理方法、装置、电子设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023070925A1 (zh) * 2021-10-28 2023-05-04 湖南天河国云科技有限公司 区块链交易池的分片方法、系统、存储介质和计算机系统
CN116561137A (zh) * 2022-01-28 2023-08-08 腾讯科技（深圳）有限公司 事务处理方法、装置、计算机设备及存储介质
CN115114311A (zh) * 2022-06-15 2022-09-27 深圳市腾讯计算机系统有限公司 一种事务执行方法以及相关装置
CN117596298A (zh) * 2023-11-24 2024-02-23 南方电网数字电网集团信息通信科技有限公司 一种数据处理方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
WO2025185409A8 (zh) 2025-10-02
CN120614366A (zh) 2025-09-09

Similar Documents

Publication Publication Date Title
JP7826384B2 (ja) シャード化された許可型の分散型台帳
US20250068597A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US20230161756A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US11249947B2 (en) Distributed digital ledger transaction network for flexible, lazy deletion of data stored within an authenticated data structure
CN110915166B (zh) 区块链
US20210157793A1 (en) Method of generating globally verifiable unique identifiers using a scalable interlinked blockchain structure
CN113419823B (zh) 一种适用于高并发事务的联盟链系统及其设计方法
US20200396072A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
CN109493223B (zh) 一种记账方法及装置
US20200394177A1 (en) Scalable, secure, efficient, and adaptable distributed digital ledger transaction network
US20250392477A1 (en) Data processing method, computer device, and storage medium
Qi et al. Schain: Scalable concurrency over flexible permissioned blockchain
CN112579261A (zh) 退出跨片事务的方法和系统、主链节点和目标分片节点
WO2026086463A1 (zh) 一种基于区块链网络的交易处理方法及相关设备
EP4561027A1 (en) Data processing method and apparatus based on hierarchical chain network, and device and medium
Chen et al. Thunderbolt: Causal concurrent consensus and execution
CN120614366A (zh) 区块链节点及应用于区块链节点的交易处理方法
Geng et al. Blockchain Parallel Mechanism Based on Transaction Process Decoupling for Complex Digital Asset
Zhang et al. Secure and Efficient Read-Write Synchronization in Re-sharding Via Lightweight Global State Tree
Li et al. Streamline: A High-Parallelized BFT Consensus Protocol for Blockchain
Ma et al. RF-Chain: A rollback-free inter-shard transaction processing scheme against malicious brokers
CN120803621A (zh) 一种跨分片事务处理方法和装置
HK40093140B (zh) 区块链数据处理方法、装置、设备及计算机可读存储介质
CN121660682A (zh) 一种面向稳定币的高性能并行区块链方法及系统
CN120200897A (zh) 区块链集群的主节点切换方法、装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25767152

Country of ref document: EP

Kind code of ref document: A1