Blockchain transaction processing system and method

Abstract

Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for processing blockchain transactions. An example of a system for processing blockchain transactions includes a storage subsystem comprising one or more storage devices that store blockchain data, and one or more processors configured to support a first thread pool and a second thread pool. The second thread pool is dedicated to the storage subsystem. The system receives M blockchain transactions and executes N of the M blockchain transactions in parallel using K threads of the first thread pool. For each blockchain transaction assigned to each thread of the K threads, each blockchain transaction uses one or more coroutines such that the blockchain transaction is executed asynchronously using the coroutines. A blockchain block is generated to contain the M blockchain transactions and the blockchain block is added to a blockchain stored in the storage subsystem.

Description

Technical Field

[0001] This article deals with processing blockchain transactions. Background Technology

[0002] With the rapid development of blockchain technology, its applications and service scenarios are constantly expanding, for example, in areas such as judicial authentication, traceability, invoicing, and supply chain finance. The amount of data generated by various blockchain services is also growing rapidly. Processing and storing large-scale blockchain data (e.g., data generated for a large number of accounts, large amounts of state data for a single account, and large amounts of block data for a single blockchain) requires significant computing resources, such as computational resources, storage resources, and network resources. Furthermore, the growth in data volume, especially after blockchain systems have been operating for an extended period, further increases the demand for computing resources.

[0003] Therefore, a more efficient way to process blockchain data and transactions is needed to meet the growing demands of various blockchain applications. Summary of the Invention

[0004] The embodiments described in this paper may include one or more features, individually or in combination.

[0005] For example, in one embodiment, a system for processing blockchain transactions includes: a storage subsystem including one or more storage devices for storing blockchain data; and one or more processors configured to support a first thread pool and a second thread pool dedicated to the storage subsystem. The system also includes one or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon. The instructions are executable by the one or more processors to perform an operation including: receiving M blockchain transactions to be executed, where M is an integer greater than 1. The operation further includes executing the M blockchain transactions. Specifically, N blockchain transactions are identified from the M blockchain transactions, where N is less than or equal to M. The N blockchain transactions are allocated for parallel execution by K threads of the first thread pool, wherein the corresponding N of the N blockchain transactions are... KEach blockchain transaction is assigned to a corresponding Kth thread. Then, the N blockchain transactions are executed in parallel by the K threads. Executing the N blockchain transactions in parallel by the K threads includes: for N1 blockchain transactions assigned to a first thread in a first thread pool, identifying P1 coroutines, where P1 is greater than or equal to N1. The N1 blockchain transactions are executed asynchronously by executing the P1 coroutines. Asynchronously executing the P1 coroutines includes accessing the blockchain data stored in the storage subsystem using the second thread pool. After executing the M blockchain transactions, a blockchain block containing the M blockchain transactions is generated and added to the blockchain of the storage subsystem.

[0006] In some embodiments, these general and specific aspects may be implemented using a system, method, or computer program, or any combination of a system, method, and computer program. The foregoing and other described embodiments may each optionally include one or more of the following aspects.

[0007] In some embodiments, accessing blockchain data stored in the storage subsystem includes one or more of the following: reading data stored in the blockchain stored in the storage subsystem; or writing new data to the blockchain. The blockchain data includes one or more of block data, state data, index data, or streaming data.

[0008] In some embodiments, one or more of the M blockchain transactions are executed after the N blockchain transactions are executed.

[0009] In some embodiments, identifying P1 coroutines to be executed asynchronously based on the N1 blockchain transactions includes: for each of the N1 blockchain transactions, identifying one or more coroutines to be executed asynchronously.

[0010] In some embodiments, the N1 blockchain transactions comprise a series of operations. The series of operations includes a first operation and a second operation following the first operation. The first operation includes an input / output (I / O) operation to access the storage subsystem.

[0011] In some embodiments, the I / O operation includes at least one of an asynchronous GET request or an asynchronous PUT request. The storage subsystem provides an I / O application programming interface (API) that supports the asynchronous GET request and the asynchronous PUT request.

[0012] In some embodiments, the P1 coroutines include a first coroutine and a second coroutine. Executing the N1 blockchain transactions by asynchronously executing the P1 coroutines includes: executing the first operation using the first coroutine; and executing the second operation asynchronously with respect to the first operation. Executing the second operation asynchronously with respect to the first operation includes executing the second operation using the second coroutine before receiving the execution result of the first operation.

[0013] In some embodiments, executing the second operation using the second coroutine before receiving the execution result of the first operation includes: saving a first operation context of the first operation, the first operation context including at least one of register data, a stack pointer, or a program counter of the first operation; and performing a context switch from the first operation context of the first operation to the second operation context of the second operation.

[0014] In some embodiments, the first coroutine includes a callback identifier corresponding to a callback function of the first operation. Executing the second operation asynchronously with the first operation further includes: receiving a value returned by the callback function of the first operation; saving a second operation context of the second operation; restoring a first operation context of the first operation; and resuming execution of the first operation based on the value returned by the callback function of the first operation.

[0015] In some embodiments, one or more storage devices for storing blockchain data include: a first storage device for storing block data; a second storage device for storing state data; a third storage device for storing index data; and a fourth storage device for storing stream data.

[0016] In some embodiments, the second thread pool includes two or more threads configured to access the one or more storage devices in parallel.

[0017] In some embodiments, the storage subsystem includes a dispatcher, wherein the dispatcher is configured to schedule the two or more threads in the second thread pool based on a round-robin scheduling method or a random hash scheduling method.

[0018] It should be understood that the methods described herein may include any combination of the aspects and features described herein. That is, the methods described herein are not limited to the combinations of the aspects and features specifically described herein, but also include any combination of the aspects and features provided.

[0019] Details of one or more embodiments herein will be set forth in the accompanying drawings and the following description. Other features and advantages of this document will become apparent from the description, the drawings, and the claims. Attached Figure Description

[0020] Figure 1 This is a diagram illustrating an example of an environment that can be used to perform the embodiments described herein.

[0021] Figure 2 This is a diagram illustrating an example of an architecture according to embodiments of this document.

[0022] Figure 3 This is a diagram illustrating an example of a system for processing blockchain transactions according to embodiments of this document.

[0023] Figure 4 This is a diagram illustrating an example of a storage kernel according to an embodiment of this article.

[0024] Figure 5 This is a diagram illustrating an example of a process for processing blockchain transactions that can be performed according to embodiments herein.

[0025] Figure 6 This is a diagram illustrating an example of a process for accessing blockchain data stored in a storage system, which can be performed according to embodiments of this document.

[0026] Figure 7 This is a flowchart illustrating an example of a process for processing blockchain transactions that can be performed according to embodiments herein.

[0027] Figure 8 This is a diagram illustrating an example of a module of a device according to an embodiment of this article.

[0028] In the various figures, the same reference numerals and names denote the same elements. Detailed Implementation

[0029] This paper describes techniques for processing blockchain transactions. A blockchain transaction (also simply a transaction) may include data, instructions, or operations to be executed by blockchain nodes in a blockchain network. Blockchain transactions may be generated, for example, by client devices or participating systems in the blockchain network. A blockchain node may receive a blockchain transaction, perform consensus processing on the blockchain transaction, and, after reaching consensus, publish the blockchain transaction by saving it to a block in the blockchain for persistent storage. Processing blockchain transactions may require significant computational resources, including computing resources (e.g., central processing unit (CPU) resources) and input / output (I / O) resources (e.g., storage resources and network resources), especially as the scale of the blockchain system increases, the runtime of the blockchain system lengthens, and / or the length of the blockchain maintained in the blockchain system increases. The techniques described in this paper can, for example, improve the processing efficiency of multiple blockchain transactions across multiple dimensions by leveraging the parallel and concurrent processing of multiple blockchain transactions. For example, each or each subset of multiple blockchain transactions can be assigned to be executed in parallel by a corresponding thread in multiple threads, thereby achieving parallel processing of multiple blockchain transactions. As another example, a blockchain transaction or its operation can be executed before the execution result of a previous blockchain transaction or its previous operation is received, to achieve asynchronous or concurrent processing without impairing or otherwise altering the execution result of the blockchain transaction and / or its operation.

[0030] The techniques described herein produce several technical effects. In some embodiments, by appropriately configuring the blockchain system and strategically scheduling multiple blockchain transactions to achieve parallel and concurrent processing of multiple blockchain transactions, the described techniques can significantly improve the processing efficiency of multiple blockchain transactions (e.g., measured in transactions per second (TPS)) without increasing available computing resources. In the processing of blockchain transactions, although blockchain blocks are generated synchronously or serially, certain blockchain transactions and / or certain I / O operations of one or more blockchain transactions can be processed or executed asynchronously and / or in parallel, for example, depending on whether there are conflicts between the blockchain transactions and / or the I / O operations of the blockchain transactions. In some embodiments, the described techniques can use multiple threads to process blockchain transactions in parallel and use coroutines to process blockchain transactions concurrently or asynchronously, thereby improving the utilization of computing and storage resources.

[0031] In some embodiments, the described technology can improve computer technology by more efficiently utilizing the computing resources of computer systems to process blockchain transactions. In some embodiments, for example, based on blockchain transaction applications or use cases and / or the operations included in blockchain transactions, blockchain transactions can be classified as CPU-bound or I / O-bound. CPU-bound blockchain transactions are those limited by CPU bottlenecks. CPU-bound blockchain transactions may primarily consist of CPU-bound operations, such that the time to complete a CPU-bound blockchain transaction is primarily determined by the speed of the central processing unit. I / O-bound blockchain transactions are those limited by I / O bottlenecks. I / O-bound blockchain transactions may include one or more I / O operations (e.g., reading or writing to disk, network, etc.), such that the time to complete an I / O-bound blockchain transaction is primarily determined by the time spent waiting for the I / O operations to complete. For example, blockchain transactions for large-scale blockchain accounts typically require a large number of random disk access operations, which are I / O-intensive and can therefore be considered I / O-bound transactions. Compared to existing transaction processing schemes, the asynchronous scheme disclosed herein can better utilize disk I / O processing capabilities (e.g., measured in input / output operations per second (IOPS)) and improve the TPS of blockchain transactions. In some embodiments, the described techniques can schedule blockchain transactions based on the type of blockchain transaction to more effectively utilize the CPU and I / O resources of the computer system and improve the execution efficiency of blockchain transactions. In some embodiments, the described techniques can implement an AxB computing architecture to improve processing efficiency in two dimensions. Here, A is the number of threads used for parallel processing to solve the scale of CPU-bound blockchain operations, and B is the number of concurrent I / O operations that each thread can execute to solve the scale of I / O-bound operations. Thus, in some cases, the processing efficiency of blockchain transactions can be improved by AxB times.

[0032] In some embodiments, the described technique can distribute a number of blockchain transactions among multiple threads in a first thread pool, such that each thread is scheduled to process a subset of the blockchain transactions. In this way, different subsets of blockchain transactions can be processed in parallel using their respective threads, thereby improving the efficiency of processing blockchain transactions.

[0033] Furthermore, for blockchain transactions scheduled to the same thread, one or more coroutines can be used for each blockchain transaction. The blockchain transactions can then be processed by executing the coroutines asynchronously or concurrently. Asynchronous or concurrent execution of an operation and a previous operation can refer to, for example, starting the execution of an operation before receiving the execution result of a previous operation. In some embodiments, asynchronous or concurrent execution of two or more operations can be achieved by using coroutines and performing coroutine switching. In some embodiments, a coroutine can be a script, logic, code, or any other computer-readable program that includes one or more operations. Operations within a coroutine are executed synchronously or sequentially. Multiple coroutines can be executed asynchronously or in an order different from the order in which they are written in a computer-readable program (e.g., script, logic, code), thereby reducing idle time of computing resources and improving the overall throughput of the system. In some embodiments, a coroutine has its own stack, local variables, and instruction pointer, but shares global variables with other coroutines. In some embodiments, coroutines can be used for non-preemptive multitasking, allowing execution to be paused and resumed, and enabling asynchronous concurrent processing of blockchain transactions and / or operations. Existing computer-readable programs for blockchain-based systems are written with synchronous logic, and operations or functions written in these programs are executed synchronously. By using coroutines in executing blockchain transactions, the described technique achieves asynchronous concurrent processing of blockchain transactions without requiring a revolutionary or substantial change to the programming logic of the computer-readable program. In some embodiments, programmers (e.g., developers, clients, or administrators of the blockchain system) can still use synchronous logic to write computer-readable programs for blockchain transactions, while the described system can generate coroutines based on these programs and implement asynchronous processing of blockchain transactions. This reduces the complexity and effort required to develop and implement blockchain-based systems for asynchronous processing of blockchain transactions and provides backward compatibility.

[0034] As an example of asynchronous or concurrent execution of two blockchain transactions, instead of letting computing resources idle, the described technique allows computing resources to be used to process subsequent blockchain transactions when the previous blockchain transaction has been executed to the point where it becomes I / O bound, waiting to retrieve data from the blockchain storage system. This reduces idle time of computing resources, improves the utilization of computing resources, reduces the total processing time of all received blockchain transactions, and reduces the block generation wait time for generating a new block that includes all executed blockchain transactions in the blockchain system. Therefore, the efficiency of the computer and the performance of the entire blockchain system can be improved.

[0035] In some embodiments, the described techniques can configure a blockchain storage system with a separate second thread pool to handle I / O operations in blockchain transactions. In some embodiments, the second thread pool is dedicated to interfacing with I / O devices in the blockchain storage system and to I / O operations for reading / writing blockchain data in the blockchain storage system. For example, for multiple I / O operations on a blockchain transaction, the I / O operations can be scheduled to be executed by different threads in the second thread pool so that I / O operations can be processed in parallel. In some embodiments, the described techniques can significantly increase the number of I / O operations per second (IOPS) and can utilize I / O resources more efficiently, especially for I / O-bound blockchain transactions.

[0036] To provide further background for the embodiments described herein, as mentioned above, a distributed ledger system (DLS), also known as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to securely and immutably transact and store data. While the term blockchain is often associated with specific networks and / or use cases, in this document, blockchain generally refers to a DLS without reference to any particular use case.

[0037] A blockchain is a data structure that stores transactions in an immutable manner. Therefore, transactions recorded on a blockchain are reliable and trustworthy. A blockchain consists of one or more blocks. Each block in the chain is linked to the preceding block by containing the hash of the block immediately preceding it. Each block also includes (e.g., provided by the computing device that generated the block or the computing system that manages the blockchain) a local timestamp, its own hash, and one or more transactions. For example, a block may include a block header and a block body. The block header may include a local timestamp, its own hash, and the hash of the preceding block. The block body may include payload information, such as one or more transactions (or transaction data). Transactions that have been verified by nodes in the blockchain network are hashed and encoded into a Merkle tree. A Merkle tree is a data structure in which data at the leaf nodes of a tree is hashed, and all hashes in each branch of the tree are concatenated at the root of the branch. This process continues along the tree to the root, where hashes representing all data in the tree are stored. A hash value can be quickly verified by determining whether the hash value of a transaction that claims to be stored in the tree is consistent with the structure of the tree.

[0038] A blockchain is a decentralized or at least partially decentralized data structure used to store transactions, while a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains through activities such as broadcasting, verifying, and confirming transactions. As mentioned above, blockchain networks can be provided as public, private, or consortium blockchain networks.

[0039] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, consensus processing can be described as the authorized set of nodes controlled by consensus nodes, with one or more consensus nodes operated by their respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the network.

[0040] In some examples, in consortium blockchain networks, a global blockchain is provided as a blockchain replicated across all nodes. That is, all consensus nodes are in a state of complete consensus relative to the global blockchain. To reach consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, a consortium blockchain network can implement Practical Byzantine Fault Tolerance (PBFT) consensus, which will be described in further detail below.

[0041] In some embodiments, centralized ledger systems may also employ a blockchain data structure to leverage the immutability, reliability, and trustworthiness of data stored on the blockchain. In some embodiments, such a centralized ledger system may be referred to as a blockchain-based centralized ledger system or a general-purpose auditable ledger service system. In some embodiments, a blockchain-based centralized ledger system may include a central trusted authority that provides transparent, immutable, and cryptographically verifiable data stored in blocks within the blockchain data structure. The stored data may be in a log format, including not only transaction logs but also other transaction data and block data. Due to the presence of the central trusted authority, blockchain-based centralized ledger systems do not require consensus processing to establish trust. In some embodiments, blockchain-based centralized ledger systems can be more efficient than typical blockchain-based distributed or decentralized ledger systems. In some embodiments, blockchain-based centralized ledger systems can provide cloud-based storage services with enhanced trust, efficiency, and storage performance.

[0042] In some embodiments, a centralized ledger system can be a node in a blockchain network. For example, a centralized ledger system can be a non-consensus node in a blockchain network and can provide a highly reliable and high-performance auditable ledger service to consensus nodes or other non-consensus nodes in the blockchain network or entities outside the blockchain network.

[0043] In some embodiments, distributed ledger systems (DLS) and blockchain-based centralized ledger systems can be collectively referred to as blockchain-based systems. In other words, blockchain-based systems is used to refer to and is broad enough to encompass distributed ledger systems (DLS), blockchain-based centralized ledger systems, or other systems that employ the blockchain data structure to leverage the immutability, reliability, and trustworthiness of data stored on the blockchain.

[0044] Figure 1 This diagram illustrates an example of an environment 100 that can be used to perform embodiments of this document. In some examples, environment 100 enables entities to participate in a consortium blockchain network 102. Environment 100 includes computing systems 106, 108 and network 110. In some examples, network 110 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and backend systems. In some examples, network 110 can be accessed via wired and / or wireless communication links. In some examples, network 110 enables communication with and within the consortium blockchain network 102. Typically, network 110 represents one or more communication networks. In some cases, computing systems 106, 108 may be nodes of a cloud computing system (not shown), or each of computing systems 106, 108 may be a separate cloud computing system comprising multiple computers interconnected via a network and used as a distributed processing system.

[0045] In the depicted examples, computing systems 106 and 108 may each include any suitable computing system capable of participating as a node in the consortium blockchain network 102. Examples of computing systems include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smartphones. In some examples, computing systems 106 and 108 carry one or more computer-implemented services for interacting with the consortium blockchain network 102. For example, computing system 106 may carry computer-implemented services for a first entity (e.g., user A), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). Computing system 108 may carry computer-implemented services for a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). Figure 1 In the example, the consortium blockchain network 102 is represented as a peer-to-peer network of nodes, and computing systems 106 and 108 provide nodes for the first and second entities participating in the consortium blockchain network 102, respectively.

[0046] Figure 2This is a diagram illustrating an example of architecture 200 according to embodiments of this document. The exemplary conceptual architecture 200 includes participant systems 202, 204, and 206, respectively corresponding to participant A, participant B, and participant C. Each participant (e.g., a user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network, which includes multiple nodes 214, at least some of which immutably record information in a blockchain 216. As further detailed herein, although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained on blockchain network 212.

[0047] In the depicted example, each participant system 202, 204, and 206 is provided by or represents participants A, B, and C, respectively, and functions as their respective nodes 214 in the blockchain network. As used herein, a node typically refers to an individual system (e.g., a computer, a server) connected to the blockchain network 212 and enabling the corresponding participant to participate in the blockchain network. Figure 2 In the example, a participant corresponds to each node 214. However, it is expected that a participant can operate multiple nodes 214 within the blockchain network 212, and / or multiple participants can share a single node 214. In some examples, participant systems 202, 204, 206 communicate with or through the blockchain network 212 using protocols (e.g., Hypertext Transfer Security Protocol (HTTPS)) and / or using Remote Procedure Calls (RPC).

[0048] Node 214 can have different levels of participation within the blockchain network 212. For example, some nodes 214 may participate in consensus processing (e.g., as mining nodes adding blocks to blockchain 216), while other nodes 214 may not participate in this consensus processing. As another example, some nodes 214 may store a complete copy of blockchain 216, while other nodes 214 may store only a partial copy of blockchain 216. For example, data access privileges can restrict the amount of blockchain data that a given participant can store within their respective system. Figure 2 In the example, participant systems 202, 204 and 206 store complete copies 216', 216” and 216”' of blockchain 216, respectively.

[0049] Blockchain (e.g., Figure 2A blockchain (216) consists of a series of blocks, each storing data. Examples of data include transaction data representing transactions between two or more participants. Transaction data is used as an example of data records stored in the blockchain. Examples of transactions can include, but are not limited to, the exchange of valuables (e.g., assets, products, services, currencies). Transaction data is immutably stored in the blockchain. That is, transaction data cannot be changed. In some embodiments, one or more operations performed in the ledger system can be stored in the blockchain as transaction data. For example, transaction data can include one or more operations or manipulations of data stored in the blockchain, information obtained from external resources (e.g., timestamp information), or any suitable data that can be stored in the blockchain (e.g., documents, images, videos, audio). Transaction data is immutably stored in the blockchain. That is, transaction data cannot be changed.

[0050] Before transaction data is stored in a block, it is hashed. Hash processing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to dehash the hash value to obtain the transaction data. Hash processing ensures that even slight changes to the transaction data will result in a completely different hash value. Furthermore, as mentioned above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. Hash processing involves processing the transaction data using a hash function to generate a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

[0051] Transaction data from multiple transactions is hashed and stored in a block. For example, two transactions are provided with hashes, and then they are hashed themselves to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is called the Merkle root hash and is stored in the block header. Any change to a transaction will cause its hash to change, and ultimately, the Merkle root hash will change.

[0052] Blocks are added to the blockchain via a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and perform work to add blocks to the blockchain. Such nodes are called consensus nodes. PBFT, described above, serves as a non-restricted example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0053] In more detail, consensus nodes generate a block header, hash all transactions within the block, and combine these hashes in pairs to generate further hashes until a single hash (the Merkle root hash) is provided for all transactions in the block. This hash is then added to the block header. Consensus nodes also determine the hash of the most recent block in the blockchain (i.e., the last block added to the blockchain). Consensus nodes also add a nonce value and a timestamp to the block header.

[0054] Typically, PBFT provides a practical Byzantine state machine replication that tolerates Byzantine errors (e.g., faulty nodes, malicious nodes). This is achieved by assuming failures will occur in PBFT (e.g., assuming independent node failures and / or manipulated messages sent by consensus nodes). In PBFT, consensus nodes are provided in a sequence including a primary consensus node and backup consensus nodes. The primary consensus node is changed periodically, and transactions are added to the blockchain by reaching consensus on the global state of the blockchain network among all consensus nodes within the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus node proves that the message was received from a designated peer node and verifies that the message has not been tampered with during the transaction.

[0055] In PBFT, the consensus protocol is provided in multiple phases, assuming all consensus nodes start in the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to receiving the request, the primary consensus node multicasts the request to backup consensus nodes. The backup consensus nodes execute the request, and each node sends a reply to the client. The client waits until it receives a threshold number of replies. In some examples, the client waits until it receives f+1 replies, where f is the maximum number of faulty consensus nodes that the blockchain network can tolerate. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain, and the record is either accepted or rejected.

[0056] In some blockchain networks, cryptography is used to maintain transaction privacy. For example, if two nodes want to keep transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction, these two nodes can encrypt the transaction data. Examples of encryption include, but are not limited to, symmetric and asymmetric encryption. Symmetric encryption refers to encryption that uses a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key can be used by multiple nodes, so each node can encrypt / decrypt the transaction data.

[0057] Asymmetric encryption uses key pairs, each consisting of a private key and a public key. The private key is known only to the corresponding node, while the public key is known to any or all other nodes in the blockchain network. A node can encrypt data using another node's public key, and that encrypted data can be decrypted using another node's private key. For example, refer again... Figure 2 Participant A can use Participant B's public key to encrypt data and send the encrypted data to Participant B. Participant B can use their private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using that node's private key.

[0058] Asymmetric encryption is used to provide digital signatures, which allows participants in a transaction to verify the other participants and the validity of the transaction. For example, a node can digitally sign a message, and another node can verify that the message was sent by participant A based on that digital signature. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, see again... Figure 2 Participant A sends a message to Participant B. Participant A generates a hash value for the message and then encrypts the hash value using its private key to provide a digital signature as the encrypted hash. Participant A appends this digital signature to the message and sends the digitally signed message to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values ​​are the same, Participant B can confirm that the message did indeed originate from Participant A and has not been tampered with.

[0059] Figure 3 This is a diagram illustrating an example of a blockchain system 300 according to embodiments of this document. In some embodiments, the blockchain system 300 can be implemented in a blockchain network (e.g., Figure 1 Blockchain network 102 or Figure 2 The network nodes of the blockchain network 212) (e.g., Figure 2 The blockchain system 300 can be implemented on node 214 to process blockchain transactions. For example, the blockchain system 300 can be implemented on each participant in the blockchain network (e.g., node 214). Figure 2 The blockchain system 300 is implemented on participant systems 202, 204, or 206. In some embodiments, the blockchain system 300 can be configured to process multiple blockchain transactions in parallel and / or asynchronously to achieve concurrent processing.

[0060] As shown in the figure, the blockchain system 300 includes an execution plugin 302, an executor 304, a storage plugin 306, a storage kernel 308, a first thread pool 310, and a second thread pool 312. The execution plugin 302 includes a scheduler 316 and a smart contract runner / platform runner / TEE runner 317. In some embodiments, the scheduler 316 is configured to schedule the processing of multiple blockchain transactions based on various computer resources (e.g., CPU resources, storage resources, network resources). In some embodiments, the smart contract runner / platform runner / TEE runner 317 is configured to support the testing and operation of smart contracts, various platforms, and trusted execution environments (TEEs) for executing blockchain transactions. In some embodiments, the executor 304 can be configured to support various blockchain service environments, such as native smart contracts, virtual machines, and TEEs. In some embodiments, the storage plugin 306 can be configured to perform conflict detection between multiple blockchain transactions, world state management, and key-value (KV) pair management.

[0061] In some embodiments, storage kernel 308 may be configured to store blockchain data, such as block data, state data, index data, and / or streaming data. As an example of block data, a blockchain block may include a block header and a block body. The block header may include identity information for a specific block, and the block body may include transactions confirmed with that block. In some embodiments, state data may be assembled into a globally shared state (also known as the world state). The world state may include a mapping between account addresses and account states. The world state may be stored in a data structure such as a Merkle Patricia tree (MPT). In some embodiments, state data may be further categorized into current state and historical state. In some embodiments, the current state is the state data corresponding to the latest block and is the data source at the time of executing the latest transaction on the blockchain network. In some embodiments, the historical state is a content-addressed dataset storing all state data from the genesis block to the latest block. In some embodiments, historical state data is stored in a historical state tree. In some embodiments, index data may indicate a mapping between data (e.g., transaction data, block data, and state data) and a data log file storing that data, in order to address or retrieve the data. In some embodiments, index data may indicate the physical location of the corresponding data stored in the storage system. In some embodiments, streaming data may be data (e.g., configuration or metadata) related to a streaming, construct, or processing engine used to process a certain type of blockchain data.

[0062] In some embodiments, blockchain data may be stored in a database 320 on storage device 321. In some embodiments, storage kernel 308 may receive input / output (I / O) operations for accessing blockchain data via storage kernel application programming interface (API) 318. In some embodiments, I / O operations may include synchronous PUT / GET requests and asynchronous PUT / GET requests. In one example, an I / O operation may include a request to retrieve the value of a key-value pair based on a keyword. In this example, storage kernel 308 may obtain the hash value of the keyword, find the corresponding node from the stored Merkle tree 319, determine a new keyword recognizable by database 320 based on the node information, and use the new keyword to read the requested value from database 320.

[0063] In some embodiments, blockchain system 300 may receive multiple blockchain transactions to be executed or processed. A blockchain transaction may include one or more tasks, functions, or operations 305, such as verifying a blockchain transaction (e.g., verifying whether the blockchain transaction can reach consensus in the blockchain network), submitting a blockchain transaction in response to successful verification, writing data or other information from the blockchain transaction to a database (e.g., database 320), and / or declaring a function preamble and conclusion, compiling or otherwise managing (e.g., reserving space for variables, cleaning up the stack before the function completes and returns to the caller of the function) to perform different operations / functions within the blockchain transaction. Some tasks or functions within a blockchain transaction may be CPU-bound, such as verification or submission operations. Some tasks or functions within a blockchain transaction may be I / O-bound, such as writing blockchain data to a database or reading blockchain data from a database.

[0064] In some embodiments, the blockchain system 300 may use a first thread pool 310 to process multiple blockchain transactions, for example, sequentially and / or in parallel. In some embodiments, the first thread pool 310 may include multiple threads (e.g., K threads, where K is an integer greater than 1), each thread capable of executing one or more blockchain transactions, such that multiple blockchain transactions can be executed in parallel by multiple threads. In one example, the blockchain system 300 may receive, for example, M blockchain transactions to be executed, where M is an integer greater than 1. In this example, N blockchain transactions may be selected from the M blockchain transactions, such that the N blockchain transactions are a subset of the M blockchain transactions. In some embodiments, the N blockchain transactions may be identified as candidate blockchain transactions for parallel processing and selected from the M blockchain transactions. Candidate blockchain transactions for parallel processing include blockchain transactions that can be executed independently without depending on or altering each other's execution effects. Candidate blockchain transactions for parallel processing may be identified, for example, based on one or more conflict detection algorithms that detect the presence of conflicts between or among the execution of multiple blockchain transactions. If changing the execution order of two or more blockchain transactions might lead to execution errors (e.g., failure to execute one operation of a blockchain transaction) or might alter the execution effect or outcome of the two or more blockchain transactions, then conflicts may exist between or among the execution of the two or more blockchain transactions. In some embodiments, a conflict detection algorithm can identify blockchain transactions that are not affected by conflicts. Therefore, candidate blockchain transactions for parallel processing can be identified among one or more blockchain transactions that are not affected by conflicts.

[0065] After identifying N blockchain transactions as candidate blockchain transactions eligible for parallel processing, the blockchain system 300 can allocate the N blockchain transactions to be executed by K threads in the first thread pool 310, wherein a corresponding number (e.g., N) of the N blockchain transactions will be processed. K (N) blockchain transactions are assigned to the corresponding Kth thread. For example, N1 blockchain transactions out of N transactions can be assigned to the first thread in the first thread pool 310, N2 blockchain transactions out of N transactions can be assigned to the second thread in the first thread pool 310, N3 blockchain transactions out of N transactions can be assigned to the third thread in the first thread pool 310, and so on. In this way, executing N1 blockchain transactions using the first thread can be performed in parallel with executing N2 blockchain transactions using the second thread and executing other blockchain transactions using other threads (e.g., executing N3 blockchain transactions out of N transactions using the third thread in the first thread pool 310).

[0066] In some embodiments, in addition to parallel processing using multiple threads in the first thread pool 310, blockchain transactions assigned to the same thread in the first thread pool can be executed asynchronously. Asynchronous execution allows blockchain transactions to be executed before the execution result of a previous blockchain transaction is received. In other words, a blockchain transaction can begin execution without waiting after a previous blockchain transaction has been fully executed. In some embodiments, coroutines are created to allow blockchain transactions to be executed asynchronously, for example, by invoking a coroutine to execute a previous blockchain transaction (or some operation of a previous blockchain transaction).

[0067] exist Figure 3 In the example shown, each of the K threads in the first thread pool 310 can execute one or more coroutines 311. Coroutines can allow asynchronous execution of blockchain transactions to achieve concurrent processing of blockchain transactions. In some embodiments, one or more coroutines can be generated for each blockchain transaction. In one example, N1 blockchain transactions out of N transactions can be assigned to the first thread in the first thread pool 310. In this example, P1 coroutines to be executed asynchronously can be identified and generated based on the N1 blockchain transactions, where P1 is greater than or equal to N1. The N1 blockchain transactions can then be executed by asynchronously executing the P1 coroutines. In some embodiments, one coroutine can be generated for one blockchain transaction. In some embodiments, one coroutine can be generated for multiple blockchain transactions. In some embodiments, more than one coroutine can be generated for one blockchain transaction. For example, a blockchain transaction may include two tasks or operations that do not depend on each other for execution (e.g., retrieving two pieces of data from one or more blockchain storage devices). In this example, two coroutines can be generated for these two operations respectively, so that the two operations of the same blockchain transaction can be executed asynchronously using the two coroutines. In some embodiments, coroutines can be generated for blockchain transactions based on the type of the blockchain transaction or the tasks or operations of the blockchain transaction (e.g., whether they are I / O-bound or CPU-bound). In some embodiments, coroutines can be generated for I / O-bound blockchain transactions or tasks of I / O-bound blockchain transactions (e.g., blockchain transactions involving one or more I / O operations accessing the blockchain storage system). In some embodiments, coroutines can be generated for one or more tasks or operations that allow the processor to wait or idle to await the result of a previous task or operation within the same blockchain transaction. For example, coroutines can be generated for operations that wait for interruptions or user input, such that once the coroutine is invoked and a coroutine switch is performed, subsequent operations can be executed. When the waiting operation information is received, the blockchain transaction can return and complete the operation.

[0068] In some embodiments, a scheduler (e.g., scheduler 316) may be configured to schedule the processing of multiple coroutines (e.g., coroutine 311) to better utilize computer resources (e.g., CPU resources, storage resources, network resources) and further improve the processing efficiency of blockchain transactions. For example, multiple coroutines may reuse one or more threads from the first thread pool 310, or use additional threads such as the second thread pool 312 to achieve concurrent processing of coroutines and underlying blockchain transactions.

[0069] In the above example, executing P1 coroutines may include using a second thread pool 312 to access blockchain data stored in storage kernel 308. In some embodiments, the second thread pool 312 may be dedicated to storage kernel 308, and in response to determining that one or more coroutines include I / O operations to access blockchain data stored in storage kernel 308, scheduler 316 may use threads from the second thread pool 312.

[0070] Figure 4 This is a diagram illustrating an example of a storage kernel 400 of a blockchain storage system according to embodiments of this document. In some embodiments, the storage kernel 400 may be implemented as Figure 3 Storage kernel 308. As shown in the figure, storage kernel 400 includes I / O API 402 that supports synchronous GET / PUT requests and asynchronous GET / PUT requests, for example, similar to... Figure 3 Storage kernel API 318.

[0071] The storage kernel 400 also includes one or more storage devices 422 for storing blockchain data. In some embodiments, different types of blockchain data can be stored separately in their respective storage devices, or mixed in one or more shared storage devices. In one example, the one or more storage devices 422 may include a first storage device for storing block data 404, a second storage device for storing state data 406, a third storage device for storing index data 408, and a fourth storage device for storing stream data 410. Block data 404, state data 406, index data 408, and stream data 410 can be stored in their respective databases 420 on the storage devices 422.

[0072] In some embodiments, the thread pool, such as thread pool 414 comprising multiple threads, is dedicated to storing kernel 400. Thread pool 414 may be... Figure 3An example of the second thread pool 312. In some embodiments, threads in thread pool 414 can be configured to access one or more storage devices 422 in parallel. As an example, a first thread in thread pool 414 can be configured to access a first storage device for storing block data, a second thread in thread pool 414 can be configured to access a second storage device for storing state data, a third thread in thread pool 414 can be configured to access a third storage device for storing index data, and a fourth thread in thread pool 414 can be configured to access a fourth storage device for storing stream data. As another example, multiple threads can be used to access the same or a single storage device to leverage the multi-access capabilities supported by the storage device to increase the throughput of storage core 400 and the efficiency of I / O operations on storage core 400.

[0073] The storage kernel 400 also includes a scheduler or dispatcher 412, which schedules I / O operations based on the characteristics of the I / O operations and computer resources, for example, according to one or more scheduling algorithms. In some embodiments, the dispatcher 412 may schedule two or more threads in the thread pool 414 based on a round-robin scheduling algorithm, a random hash scheduling algorithm, or other algorithms.

[0074] In some embodiments, the storage kernel 400 may receive multiple I / O operations via I / O API 402. In some embodiments, the multiple I / O operations originate from one or more blockchain transactions or coroutines of one or more blockchain transactions. In one example, each I / O operation may include a request to retrieve a value corresponding to blockchain data (e.g., block data 404, state data 406, index data 408, or stream data 410) based on a key associated with a value in a key-value pair. In this example, the dispatcher 412 may determine the data type of the requested value of the I / O operation and schedule the I / O operation for threads in thread pool 414. In some embodiments, multiple I / O operations may be scheduled for multiple threads respectively, allowing multiple I / O operations to be executed in parallel using multiple threads. For each I / O operation, the storage kernel 400 may obtain the hash value of the key included in the request, locate the corresponding node from the stored Merkle tree 418, determine a new key recognizable by the corresponding database 420 based on the node information, and use the new key to read the requested value from the database 420.

[0075] In some embodiments, the parallel execution of multiple I / O operations enables multiple coroutines and blockchain transactions to be executed concurrently, particularly considering the thread pool 414 of the decoupled storage kernel 400 and the one or more threads distributed to execute blockchain transactions (e.g., Figure 3 (Threads in the first thread pool 310).

[0076] Figure 5 An example of a process 500 for processing blockchain transactions, which can be executed according to embodiments herein, is shown. For convenience, this process will be described as being executed by a system of one or more computers located in one or more locations and suitably programmed according to this document. For example, a suitably programmed blockchain-based system (e.g., Figure 3 A blockchain system 300) can execute process 500. In some embodiments, each network node of the appropriately programmed blockchain network (e.g., Figure 2 Node 214) can execute process 500. Network nodes can be, for example, consensus nodes or non-consensus nodes. Network nodes can be, for example, participants in a blockchain network system, such as... Figure 2 The participants are system 202, 204, or 206.

[0077] In the depicted example, client 502 may send one or more requests to process multiple blockchain transactions. Client 502 may include one or more user interfaces or other communication interfaces for interacting with users and / or other network nodes of the blockchain network. For example, client 502 may receive multiple blockchain transactions from users and / or other network nodes of the blockchain network associated with client 502. In some embodiments, the multiple blockchain transactions may be blockchain transactions received during block generation in the blockchain network, enabling a new block including the multiple blockchain transactions to be added to the blockchain maintained by the blockchain network.

[0078] In this example, client 502 receives five blockchain transactions ae and sends them to consensus module 504 of the blockchain-based system for processing. In some embodiments, consensus module 504 can perform a consensus process on the blockchain transactions. After determining that consensus has been reached, the five blockchain transactions ae can be sent to scheduler 506 for execution.

[0079] In some embodiments, scheduler 506 may assign or otherwise distribute multiple blockchain transactions to a thread pool (e.g., Figure 3The available threads in the first thread pool 310. Available threads can be assigned one or more blockchain transactions. In this example, five blockchain transactions ae are scheduled to threads 508-1 to 508-N. As shown, blockchain transactions a and b are scheduled to thread 508-1, blockchain transaction c is scheduled to thread 508-2, and blockchain transactions d and e are scheduled to thread 508-N. In some embodiments, multiple blockchain transactions can be executed in parallel using multiple threads. In this example, blockchain transactions a and b can be executed in parallel using thread 508-1, blockchain transaction c can be executed using thread 508-2, and blockchain transactions d and e can be executed in parallel using thread 508-N.

[0080] In some embodiments, one or more coroutines may be created or generated for each blockchain transaction. Figure 5 The example in the example shows the creation of coroutines for blockchain transactions d and e to facilitate asynchronous processing of blockchain transactions d and e, even though they are assigned to be processed by the same thread 508-N.

[0081] In some embodiments, each blockchain transaction may include one or more I / O binding operations, such as I / O operations to access blockchain data stored in the system, CPU binding operations, or other operations. In some embodiments, one or more coroutines may be created for one or more operations (e.g., I / O operations) in a blockchain transaction that require waiting time or may cause computing resources (e.g., threads processing blockchain transactions) to be paused or idle. In some embodiments, one or more coroutines may be created for one or more operations according to a conflict detection algorithm, such that one or more operations can be executed asynchronously without changing the execution result of the one or more operations as if the one or more operations were executed synchronously or sequentially.

[0082] exist Figure 5 In the example shown, blockchain transaction d includes two I / O operations d1 and d2, and blockchain transaction e includes I / O operation e1. Note that this is for illustrative purposes only. Figure 5 This is illustrated as including I / O operations d1, d2, and e1. Each transaction in blockchain transaction ae may include any suitable number of I / O operations and / or non-I / O operations. In some embodiments, separate coroutines may be created for I / O operations d1, d2, and e1. In some embodiments, fewer, additional, or different coroutines may be created based on the blockchain transaction and the operations included in the blockchain transaction.

[0083] In some embodiments, blockchain transactions and their coroutines (e.g., based on I / O operations) can be scheduled to execute in parallel and asynchronously based on a conflict detection algorithm. For example, a conflict detection algorithm can be used to determine that the execution of I / O operation d2 depends on the execution of I / O operation d1, allowing I / O operation d2 to be executed after I / O operation d1 has been completed. On the other hand, a conflict detection algorithm can be used to determine that I / O operation e1 does not depend on I / O operations d1 and d2. Thus, I / O operation e1 can be executed asynchronously with I / O operations d1 and d2. In some embodiments, operation d1 can be executed first to access blockchain data stored in database 514. In some embodiments, a coroutine is created for each blockchain transaction. In this case, the coroutine created for transaction d can be used to execute I / O operations d1 and d2 for transaction d, and another coroutine created for transaction e can be used to execute I / O operation e1. In some embodiments, when an I / O operation has been executed to the point where it needs to access disk storage, a coroutine switch can be performed for that I / O operation. In some embodiments, coroutine switching may include saving the operation context of a first coroutine for performing a first operation, and switching to a second coroutine for performing a second operation.

[0084] Continuing the example above, when I / O operation d1 accesses database 514 to retrieve blockchain data, the operation context of the coroutine used for transaction d can be saved. In some embodiments, saving the operation context of the coroutine used to perform the operation may include saving register data, a stack pointer, and / or a program counter or the environment associated with the coroutine. After saving the operation context of the coroutine used for I / O operation d1, computing resources (e.g., threads 508-N) can then be released to execute, for example, I / O operation e1. This allows for asynchronous execution of I / O operations d1 and e1, so that the execution of I / O operation e1 does not wait for the completion of I / O operation d1. In some embodiments, I / O operations d1 and e1 can use one or more threads different from threads 508-N (e.g., threads dedicated to the storage kernel 512) to further improve processing efficiency, for example, according to reference... Figure 6 The described technique. In some embodiments, I / O operations d1 and e1 can be processed in parallel using two corresponding threads.

[0085] In the example above, I / O operation d1 can return its execution result before completing I / O operation e1. In some embodiments, a coroutine switch can be performed to switch from the coroutine used to execute I / O operation e1 back to the coroutine used to execute I / O operation d1. I / O operation d1 can then continue execution. Immediately after receiving the execution result and following the completion of I / O operation d1, I / O operation d2 can be executed (e.g., using the same coroutine used to execute I / O operation d1).

[0086] exist Figure 5 In the example shown, after I / O operation d2 returns its execution result, the execution results of I / O operations d1 and d2 can be returned to execute blockchain transaction d. In some embodiments, after the execution of I / O operation d2 is completed, a coroutine switch can be performed to switch from the coroutine used to execute I / O operation d2 to the coroutine used to execute I / O operation e1. I / O operation e1 can then continue to be executed. After I / O operation e1 returns its execution result, the execution result of I / O operation e1 can be returned to execute blockchain transaction e. In this example, although blockchain transactions d and e are scheduled to be processed by the same thread 508-N, they are processed asynchronously by using coroutines. The execution of blockchain transaction e does not need to wait for blockchain transaction d to complete before starting, thereby reducing the total execution time of blockchain transactions d and e and making more efficient use of thread 508-N.

[0087] Figure 6 An example of a process 600 for accessing blockchain data stored in a storage system, which may be performed according to embodiments herein, is shown. For convenience, this process will be described as being performed by a system of one or more computers located in one or more locations and suitably programmed according to this document. For example, a suitably programmed blockchain-based storage system (e.g., Figure 4 The storage kernel 400 can execute process 600. Process 600 can be used to access the storage stored in... Figure 5 An exemplary process for storing blockchain data in database 514.

[0088] In the illustrated example, storage kernel 604 receives I / O operations d1, d2, and e1 from storage plug-in 602. I / O operations d1, d2, and e1 can be I / O operations included in one or more blockchain transactions. Note that this is for illustrative purposes only. Figure 6 It is shown as including I / O operations d1, d2 and e1. Figure 6 The I / O operations d1, d2, and e1 in the code can be considered as... Figure 5 The I / O operations d1, d2, and e1 may be the same or different.

[0089] In this example, each of I / O operations d1, d2, and e1 may include a request to retrieve a value corresponding to blockchain data (e.g., block data 404, state data 406, index data 408, or stream data 410) from database 614 based on a key associated with the value. Dispatcher 610 may determine the data type of the value requested in the I / O operation and schedule I / O operations d1, d2, and e1 for threads 612-1 to 612-N. Threads 612-1 to 612-N may be the same as or different from one or more threads (e.g., threads 508-1 to 508-N) scheduled to process blockchain transactions including I / O operations d1, d2, and e1. In this example, threads 612-1 to 612-N may be a thread pool dedicated to storage kernel 604, different from threads (e.g., threads 508-1 to 508-N) scheduled to process blockchain transactions. As shown in the figure, I / O operations d1, d2, and e1 are assigned to threads 612-1, 612-N, and 612-2, respectively. In some embodiments, multiple I / O operations can be scheduled for multiple threads, allowing multiple I / O requests to be executed in parallel using multiple threads. In this example, I / O operations d1, d2, and e1 can be executed in parallel using threads 612-1, 612-N, and 612-2, respectively.

[0090] Figure 7 This is a flowchart illustrating an example of a process 700 that can be performed according to embodiments herein. The flowchart represents process 700 for processing blockchain transactions. For convenience, this process will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, a appropriately programmed blockchain-based system (e.g., Figure 3 The blockchain system 300 can perform this process. In some embodiments, the blockchain-based system can be implemented at blockchain network nodes (e.g., Figure 2 Implemented on blockchain network node 214.

[0091] In step 702, the blockchain network nodes receive M blockchain transactions to be executed by the blockchain network nodes. In some embodiments, the blockchain network nodes are connected to a storage system that stores blockchain data in the blockchain (e.g., Figure 3 Storage kernel 308 or Figure 4The storage kernel (400) is associated with M, and M is an integer greater than 1. A blockchain network node can maintain a blockchain comprising a series of blocks used to store blockchain data. A blockchain network node can receive multiple blockchain transactions, perform consensus on the multiple blockchain transactions, and, if consensus is reached on the multiple blockchain transactions, can generate a block containing the multiple blockchain transactions. The generated block can be appended to the blockchain maintained by the blockchain node. In some embodiments, the M blockchain transactions can be blockchain transactions received by the blockchain node during the block generation interval, executed by the blockchain network node, and included in blocks on the blockchain for storage or publication.

[0092] In step 704, the blockchain network node executes M blockchain transactions. In some embodiments, in response to determining that all consensus nodes in the blockchain network have reached a consensus on multiple blockchain transactions, the blockchain network node executes M blockchain transactions. In some embodiments, some or all of the M blockchain transactions can be executed concurrently to improve execution efficiency and reduce the processing latency of block generation by the network node. In some embodiments, step 704 includes substeps 706-710.

[0093] In step 706, the blockchain network node identifies N blockchain transactions from M blockchain transactions, where N is less than or equal to M. In some embodiments, the N blockchain transactions can be selected based on conflict detection of the M blockchain transactions, for example, based on information regarding... Figures 3 to 5 The described exemplary technique. For example, N blockchain transactions are candidate blockchain transactions for parallel processing, which can be executed independently without depending on or altering each other's execution effects.

[0094] In step 708, the blockchain network node allocates N blockchain transactions into a first thread pool of K threads (e.g., Figure 3 The first thread pool 310) executes in parallel. In some embodiments, after identifying N blockchain transactions as candidate blockchain transactions eligible for parallel processing, the blockchain network node assigns the N blockchain transactions to be executed by the first thread pool. In some embodiments, the corresponding N of the N blockchain transactions are... K Each blockchain transaction is assigned to a corresponding Kth thread. For example, N1 blockchain transactions out of N transactions can be assigned to the first thread, N2 blockchain transactions out of N transactions can be assigned to the second thread, N3 blockchain transactions out of N transactions can be assigned to the third thread, and so on. In this way, executing N1 blockchain transactions using the first thread can be performed in parallel with executing N2 blockchain transactions using the second thread and executing other blockchain transactions using other threads (e.g., executing N3 blockchain transactions using the third thread in the first thread pool).

[0095] In step 710, N blockchain transactions are executed in parallel using K threads. In some embodiments, in addition to parallel processing using multiple threads in a first thread pool, blockchain transactions assigned to the same thread in the first thread pool can be executed asynchronously. Asynchronous execution allows blockchain transactions to be executed before the execution results of previous blockchain transactions are received. In other words, blockchain transactions can begin execution without waiting after previous blockchain transactions have been fully executed. In some embodiments, for example, by invoking a coroutine to execute a previous blockchain transaction (or some operation of a previous blockchain transaction) to begin executing blockchain transactions, coroutines are created to allow blockchain transactions to be executed asynchronously.

[0096] Continuing the example above, the execution of N1 blockchain transactions can be performed in parallel with the execution of N2 blockchain transactions. In some embodiments, for N1 blockchain transactions allocated to a first thread in a first thread pool, in step 721, P1 coroutines to be executed asynchronously can be identified based on the N1 blockchain transactions, where P1 is greater than or equal to N1. For example, one or more coroutines can be generated for each of the N1 blockchain transactions. In step 731, the N1 blockchain transactions can then be executed by asynchronously executing the P1 coroutines. Similarly, for N2 blockchain transactions allocated to a second thread in a first thread pool, in step 722, P2 coroutines to be executed asynchronously can be identified based on the N2 blockchain transactions. In step 732, the N2 blockchain transactions can then be executed by asynchronously executing the P2 coroutines.

[0097] In some embodiments, coroutines can be generated for blockchain transactions based on the type of the blockchain transaction or the tasks or operations of the blockchain transaction (e.g., whether they are I / O-bound or CPU-bound). In some embodiments, coroutines can be generated for I / O-bound blockchain transactions or tasks of I / O-bound blockchain transactions (e.g., blockchain transactions involving one or more I / O operations accessing the blockchain storage system). In some embodiments, coroutines can be generated for one or more tasks or operations that allow the processor to wait or idle to await the result of a previous task or operation within the same blockchain transaction. For example, coroutines can be generated for operations that wait for interruptions or user input, such that once the coroutine is invoked and a coroutine switch is performed, subsequent operations can be executed. When the waiting operation information is received, the blockchain transaction can return and complete the operation.

[0098] In some embodiments, identifying P1 coroutines to be executed asynchronously based on N1 blockchain transactions includes identifying one or more coroutines to be executed asynchronously for each of the N1 blockchain transactions. In some embodiments, asynchronously executing the P1 coroutines includes using a second thread pool (e.g., Figure 3 Thread pool 312 or Figure 4 A second thread pool (414) accesses blockchain data stored in a storage system, wherein the second thread pool is different from the first thread pool. In some embodiments, the second thread pool is dedicated to the storage system. In some embodiments, accessing blockchain data stored in the storage system includes one or more of the following: reading data stored in the blockchain stored in the storage system, or writing new data to the blockchain. In some embodiments, blockchain data includes one or more of block data, state data, index data, or streaming data.

[0099] In some embodiments, different types of blockchain data can be stored separately in their respective storage devices, or mixed in one or more shared storage devices. In one example, the storage system may include a first storage device for storing block data, a second storage device for storing state data, a third storage device for storing index data, and a fourth storage device for storing streaming data. Block data, state data, index data, and streaming data can be stored in their respective databases on the storage devices of the storage system.

[0100] In some embodiments, threads in the second thread pool can be configured to access one or more storage devices of the storage system in parallel. As an example, a first thread in the second thread pool can be configured to access a first storage device for storing block data, a second thread can be configured to access a second storage device for storing state data, a third thread can be configured to access a third storage device for storing index data, and a fourth thread can be configured to access a fourth storage device for storing streaming data. As another example, multiple threads can be used to access the same or a single storage device to leverage the multi-access capabilities supported by the storage device, thereby increasing the throughput of the storage system and the efficiency of I / O operations on the storage system.

[0101] In some embodiments, N1 blockchain transactions comprise a series of operations, wherein the series of operations may include a first operation and a second operation following the first operation. In some embodiments, the first operation may be an I / O operation to access the storage system. In some embodiments, the I / O operation includes at least one of an asynchronous GET request or an asynchronous PUT request.

[0102] In some embodiments, the P1 coroutines include a first coroutine and a second coroutine. In some embodiments, executing N1 blockchain transactions by asynchronously executing the P1 coroutines includes: performing a first operation using the first coroutine, and performing a second operation asynchronously with the first operation. In some embodiments, performing the second operation asynchronously with the first operation includes performing the second operation using the second coroutine before receiving the execution result of the first operation. For example, performing the second operation using the second coroutine does not require waiting for the first operation to complete, thereby reducing the total execution time of the first and second operations and making more efficient use of threads 508-N.

[0103] In some embodiments, executing a second operation using a second coroutine before receiving the execution result of a first operation includes: saving the first operation context of the first operation; and performing a context switch from the first operation context of the first operation to the second operation context of the second operation. In some embodiments, the first operation context includes at least one of the register data of the first operation, a stack pointer, or a program counter.

[0104] In some embodiments, the first coroutine includes a callback identifier corresponding to the callback function of the first operation. In some embodiments, executing the second operation asynchronously with the first operation further includes: receiving a value returned by the callback function of the first operation; saving the second operation context of the second operation; restoring the first operation context of the first operation; and resuming the execution of the first operation based on the value returned by the callback function of the first operation.

[0105] In step 712, after executing M blockchain transactions, the blockchain network node generates a blockchain block containing the M blockchain transactions. In some embodiments, one or more of the M blockchain transactions are executed after N blockchain transactions are executed. For example, one or more of the M blockchain transactions can be executed in series with or synchronously with the N blockchain transactions.

[0106] In step 714, the blockchain network node adds or appends a blockchain block to the blockchain of the storage system associated with that blockchain network node.

[0107] Figure 8 This is a diagram illustrating an example of modules of apparatus 800 according to embodiments of this document. Apparatus 800 may be an example of an embodiment of a blockchain node configured to process blockchain transactions. Apparatus 800 may correspond to the embodiments described above, and apparatus 800 includes: a receiving module 802 for receiving M blockchain transactions to be executed, where M is an integer greater than 1; an execution module 804 for executing the M blockchain transactions; a generation module 806 for generating a blockchain block including the M blockchain transactions; and an adding module 808 for adding the blockchain block to the blockchain in a storage system associated with the blockchain node.

[0108] In some embodiments, the apparatus 800 further includes: an identification submodule for identifying N blockchain transactions from M blockchain transactions, where N is less than or equal to M; and an allocation submodule for allocating the N blockchain transactions to be executed in parallel by K threads of the first thread pool, wherein the corresponding N of the N blockchain transactions are allocated to the appropriate threads for further execution. K Each blockchain transaction is assigned to the corresponding Kth thread; and an execution submodule is used to execute N blockchain transactions in parallel through K threads.

[0109] In some embodiments, executing N blockchain transactions in parallel using K threads includes: for N1 blockchain transactions allocated to a first thread in a first thread pool out of the N blockchain transactions, identifying P1 coroutines to be executed asynchronously based on the N1 blockchain transactions, where P1 is greater than or equal to N1; and executing the N1 blockchain transactions by asynchronously executing the P1 coroutines.

[0110] In some embodiments, asynchronously executing P1 coroutines includes using a second thread pool to access blockchain data stored in the storage subsystem. The second thread pool is different from the first thread pool.

[0111] In some embodiments, the second thread pool is dedicated to the storage system.

[0112] In some embodiments, accessing blockchain data stored in a storage system includes one or more of the following: reading data stored in the blockchain stored in the storage system; or writing new data to the blockchain. Blockchain data includes one or more of block data, state data, index data, or streaming data.

[0113] In some embodiments, one or more of the M blockchain transactions are executed after the N blockchain transactions are executed.

[0114] In some embodiments, identifying P1 coroutines to be executed asynchronously based on N1 blockchain transactions includes: for each of the N1 blockchain transactions, identifying one or more coroutines to be executed asynchronously.

[0115] In some embodiments, N1 blockchain transactions comprise a series of operations. This series of operations includes a first operation and a second operation following the first operation. The first operation includes an input / output (I / O) operation to access the storage system.

[0116] In some embodiments, the I / O operation includes at least one of an asynchronous GET request or an asynchronous PUT request.

[0117] In some embodiments, the P1 coroutines include a first coroutine and a second coroutine. Executing N1 blockchain transactions by asynchronously executing the P1 coroutines includes: performing a first operation using the first coroutine; and performing a second operation asynchronously with respect to the first operation. Performing the second operation asynchronously with respect to the first operation includes performing the second operation using the second coroutine before receiving the execution result of the first operation.

[0118] In some embodiments, executing a second operation using a second coroutine before receiving the execution result of a first operation includes: saving a first operation context of the first operation, wherein the first operation context includes at least one of register data, a stack pointer, or a program counter of the first operation; and performing a context switch from the first operation context of the first operation to the second operation context of the second operation.

[0119] In some embodiments, the first coroutine includes a callback identifier corresponding to a callback function of the first operation. Executing the second operation asynchronously with the first operation further includes: receiving a value returned by the callback function of the first operation; saving the second operation context of the second operation; restoring the first operation context of the first operation; and resuming execution of the first operation based on the value returned by the callback function of the first operation.

[0120] The systems, devices, modules, or units shown in the foregoing embodiments can be implemented using computer chips or entities, or can be implemented using products with specific functions. Typical embodiment devices are computers (which may be personal computers), laptop computers, cellular phones, camera phones, smartphones, personal digital assistants, media players, navigation devices, email receiving and sending devices, game consoles, tablet computers, wearable devices, or any combination of these devices.

[0121] For the implementation process of the function and role of each module in the device, please refer to the implementation process of the corresponding steps in the aforementioned method. For simplicity, details are omitted here.

[0122] Since the apparatus embodiments largely correspond to the method embodiments, the relevant descriptions in the method embodiments can be referred to for related components. The apparatus implementation described above is merely an example. Modules described as individual components may or may not be physically separate, and components shown as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all modules can be selected based on actual needs to achieve the objectives of the present invention. Those skilled in the art can understand and implement the embodiments of this application without inventive effort.

[0123] Refer again Figure 8This can be interpreted as illustrating the internal functional modules and structure of a blockchain transaction processing apparatus. A blockchain transaction processing apparatus can be an example of a computer server associated with a blockchain network node. Essentially, the executing entity can be an electronic device comprising: one or more processors; and one or more computer-readable storage media configured to store executable instructions for the one or more processors. In some embodiments, the one or more computer-readable storage media are coupled to and have programming instructions stored thereon, which can be executed by the one or more processors to perform the algorithms, methods, functions, processes, flows, and programs described herein. This document also provides one or more non-transitory computer-readable storage media coupled to and having instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform operations according to embodiments of the methods provided herein.

[0124] This document also provides a system for implementing the methods provided herein. The system includes one or more processors and a computer-readable storage medium coupled to and having instructions stored thereon on the one or more processors, the instructions, when executed by the one or more processors, causing the one or more processors to perform the operations described in the embodiments of the methods provided herein.

[0125] Embodiments of the subject matter, actions, and operations described herein can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, or combinations thereof, including the structures disclosed herein and their structural equivalents. Embodiments of the subject matter described herein can be implemented as one or more computer programs, such as one or more computer program instruction modules encoded on a computer program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. For example, the computer program carrier may include one or more computer-readable storage media on which instructions are encoded or stored. The carrier may be a tangible, non-transitory computer-readable medium, such as a magnetic disk, magneto-optical disk or optical disk, a solid-state drive, random access memory (RAM), read-only memory (ROM), or other media types. Optionally or additionally, the carrier may be an artificially generated propagation signal, such as a machine-generated electrical signal, optical signal, or electromagnetic signal, generated to encode information for transmission to a suitable receiver device for execution by a data processing apparatus. The computer storage medium may be, or in part, a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination thereof. The computer storage medium is not a propagation signal.

[0126] A computer program may also be called or described as a program, software, software application, app, module, software module, engine, script, or code, and may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; it may be deployed in any form, including as a standalone program or as a module, component, engine, subroutine, or other unit suitable for execution in a computing environment, which may include one or more computers interconnected by a data communication network in one or more locations.

[0127] A computer program may, but is not required to, correspond to a file in a file system. A computer program may be stored as: a portion of a file that holds other programs or data, for example, one or more scripts stored in a markup language document; a single file dedicated to the program in question; or multiple coordination files, for example, multiple files storing one or more modules, subroutines, or code sections.

[0128] Processors used to execute computer programs include, for example, general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives data and instructions for the computer program to be executed from a non-transitory computer-readable medium coupled to the processor.

[0129] The term "data processing apparatus" encompasses all types of devices, apparatuses, and machines used for processing data, including programmable processors, computers, or multiple processors or computers. Data processing apparatuses may include specialized logic circuitry such as FPGAs (Field-Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), or GPUs (Graphics Processing Units). In addition to hardware, the apparatus may also include code that creates an execution environment for computer programs, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, or combinations thereof.

[0130] The processes and logical flows described herein can be executed by one or more computers or processors executing one or more computer programs to perform operations by manipulating input data and generating outputs. These processes and logical flows can also be executed by dedicated logic circuitry, such as FPGAs, ASICs, or GPUs, or by a combination of dedicated logic circuitry and one or more programmed computers.

[0131] A computer suitable for executing computer programs can be based on a general-purpose and / or special-purpose microprocessor, or any other type of central processing unit (CPU). Typically, the CPU receives instructions and data from read-only memory and / or random access memory. The components of a computer may include a CPU for executing instructions and one or more storage devices for storing instructions and data. The CPU and memory may be supplemented with or integrated into special-purpose logic circuitry.

[0132] Typically, a computer also includes, or is operatively coupled to, one or more storage devices to receive data or transfer data to one or more storage devices. Storage devices can be, for example, disks, magneto-optical or optical disks, solid-state drives, or any other type of non-transitory computer-readable media. However, a computer does not necessarily have to have such devices. Thus, a computer can be coupled to one or more storage devices, such as one or more memories located locally and / or remotely. For example, a computer may include one or more local memories as an integrated component of the computer, or the computer may be coupled to one or more remote memories located in a cloud network. Furthermore, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name just a few.

[0133] Components can be "coupled" to each other by communicating directly or via one or more intermediate components, such as electrical or optical connections. These components can also be "coupled" to each other if one component is integrated into another. For example, a storage component integrated into a processor, such as an L2 cache component, can be "coupled" to the processor.

[0134] To interact with a user, embodiments of the subject matter described herein can be implemented on or configured to communicate with a computer having a display device and input devices, such as an LCD (liquid crystal display) monitor for displaying information to the user, and input devices such as a keyboard and positioning devices through which the user can provide input to the computer, and positioning devices such as a mouse, trackball, or touchpad. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and any form of input from the user can be received, including sound, speech, or tactile input. Furthermore, a computer can interact with a user by sending and receiving documents from the device used by the user; for example, by sending a web page to a web browser on the user's device in response to a request received from the web browser, or by interacting with an application (app) running on the user's device, such as a smartphone or tablet. A computer can also interact with a user by sending text messages or other forms of messages to a personal device, such as a smartphone running a messaging program, and receiving response messages from the user.

[0135] This document uses the term "configured as" in relation to systems, devices, and computer program components. For a system of one or more computers configured to perform a specific operation or action, this means that the system has software, firmware, hardware, or a combination thereof installed thereon that causes the system to perform said operation or action during operation. For one or more computer programs configured to perform a specific operation or action, this means that the one or more programs include instructions that, when executed by a data processing device, cause that device to perform said operation or action. For a dedicated logic circuit configured to perform a specific operation or action, this means that the circuit has electronic logic for performing said operation or action.

[0136] While this document contains many specific implementation details, these should not be construed as limiting the scope of the claims, but rather as descriptions of features specific to particular embodiments, the scope of which is defined by the claims themselves. Some features described herein in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Moreover, although the features described above may function in certain combinations, and even were initially claimed, in some cases one or more features may be removed from the claimed combination, and the claims may also be directed to sub-combinations or variations thereof.

[0137] Similarly, although the operations are depicted in the accompanying drawings in a specific order and are described in the claims, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or requiring the execution of all shown operations, in order to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0138] Specific embodiments of this subject matter have been described. Other embodiments also fall within the scope of the following claims. For example, the actions recited in the claims can be performed in different orders and still achieve the desired result. As an example, the processes depicted in the drawings do not require a specific order or sequence to achieve the desired result. In some cases, multitasking in parallel may be advantageous.

Claims

1. A system for processing blockchain transactions, the system comprising: The storage subsystem includes one or more storage devices for storing blockchain data; One or more processors are configured to support a first thread pool and a second thread pool, wherein the second thread pool is dedicated to the storage subsystem; and One or more computer-readable storage devices coupled to the one or more processors and storing instructions thereon, wherein the instructions are executable by the one or more processors to perform operations including: Receive M blockchain transactions to be executed, where M is an integer greater than 1; Executing the M blockchain transactions, wherein executing the M blockchain transactions includes: Identify N blockchain transactions from the M blockchain transactions, where N is less than or equal to M; The N blockchain transactions are allocated to be executed in parallel by K threads from the first thread pool, wherein the corresponding N of the N blockchain transactions are... K Each blockchain transaction is assigned to the corresponding Kth thread; and The N blockchain transactions are executed in parallel using the K threads, wherein the parallel execution of the N blockchain transactions using the K threads includes: For the N1 blockchain transactions allocated to the first thread in the first thread pool out of the N blockchain transactions Based on the N1 blockchain transactions, P1 coroutines to be executed asynchronously are identified, where P1 is greater than or equal to N1; and The N1 blockchain transactions are executed by asynchronously executing the P1 coroutines; wherein, asynchronously executing the P1 coroutines includes using the second thread pool to access the blockchain data stored in the storage subsystem; After executing the M blockchain transactions, a blockchain block containing the M blockchain transactions is generated; and The blockchain block is added to the blockchain of the storage subsystem.

2. The system according to claim 1, wherein, Accessing blockchain data stored in the storage subsystem includes one or more of the following: Read data stored in the blockchain within the storage subsystem; or Write the new data into the blockchain, and The blockchain data includes one or more of block data, state data, index data, or stream data.

3. The system according to any one of the preceding claims, wherein, One or more of the M blockchain transactions are executed after the N blockchain transactions are executed.

4. The system according to any one of the preceding claims, wherein, Based on the N1 blockchain transactions, P1 coroutines to be executed asynchronously include: For each of the N1 blockchain transactions, identify one or more coroutines to be executed asynchronously.

5. The system according to any one of the preceding claims, wherein, The N1 blockchain transactions include a series of operations. The series of operations includes a first operation and a second operation following the first operation. The first operation includes accessing the input / output I / O operations of the storage subsystem.

6. The system according to claim 5, wherein, The I / O operation includes at least one of an asynchronous GET request or an asynchronous PUT request; The storage subsystem provides an I / O application programming interface (API) to support the asynchronous GET and asynchronous PUT requests.

7. The system according to claim 5, wherein, The P1 coroutines include a first coroutine and a second coroutine, and the N1 blockchain transactions are executed asynchronously by executing the P1 coroutines, including: The first operation is performed using the first coroutine; and The second operation is performed asynchronously with the first operation, wherein performing the second operation asynchronously with the first operation includes performing the second operation using the second coroutine before receiving the execution result of the first operation.

8. The system according to claim 7, wherein, Executing the second operation using the second coroutine before receiving the execution result of the first operation includes: Save the first operation context of the first operation, the first operation context including at least one of the register data of the first operation, the stack pointer, or the program counter; and Perform a context switch from the first operation context of the first operation to the second operation context of the second operation.

9. The system according to claim 8, wherein, The first coroutine includes a callback identifier corresponding to the callback function of the first operation, and executing the second operation asynchronously with the first operation further includes: Receive the value returned by the callback function of the first operation; Save the second operation context of the second operation; Restore the first operation context of the first operation; and Execution of the first operation is resumed based on the value returned by the callback function of the first operation.

10. The system according to any one of the preceding claims, wherein, The one or more storage devices storing the blockchain data include: The primary storage device for storing block data; A second storage device for storing state data; A third storage device for storing index data; A fourth storage device for storing streaming data.

11. The system according to any one of the preceding claims, wherein, The second thread pool includes two or more threads configured to access the one or more storage devices in parallel.

12. The system according to claim 11, wherein, The storage subsystem includes a dispatcher. The dispatcher is configured to schedule the two or more threads in the second thread pool based on either round-robin or random hash scheduling.

Images