Blockchain transaction processing method, apparatus, medium, and electronic device

Abstract

The application belongs to the technical field of blockchains, and particularly relates to a blockchain transaction processing method, a blockchain transaction processing device, a computer readable medium, an electronic device and a computer program product. The method comprises the following steps: writing a transaction request broadcast on a blockchain network into an outer transaction pool maintained by a blockchain node, the outer transaction pool being a cache space for saving transaction requests before execution; running an intelligent contract according to the transaction request saved in the outer transaction pool to obtain transaction data corresponding to the transaction request; writing the transaction data into an inner transaction pool maintained by the blockchain node, the inner transaction pool being a cache space for saving transaction requests after execution; and performing on-chain storage on the transaction data saved in the inner transaction pool. The application can improve the data processing efficiency in the blockchain transaction processing process.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, specifically relating to a blockchain transaction processing method, a blockchain transaction processing device, a computer-readable medium, an electronic device, and a computer program product. Background Technology

[0002] Blockchain is a shared digital ledger with a chained-block data structure, built on transparent and trusted rules in a peer-to-peer network environment. It is designed to be tamper-proof, tamper-proof, and traceable. The chained-block data structure stores transactions occurring over a period of time in units of blocks, and uses cryptographic algorithms to link these blocks chronologically.

[0003] In traditional blockchain consensus models, the execution and packaging of transactions onto the blockchain are carried out synchronously on blockchain nodes, resulting in low data processing efficiency. Summary of the Invention

[0004] This application provides a blockchain transaction processing method, a blockchain transaction processing device, a computer-readable medium, an electronic device, and a computer program product, with the aim of improving data processing efficiency in the blockchain transaction processing process.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of the embodiments of this application, a blockchain transaction processing method is provided, the method comprising:

[0007] Transaction requests broadcast on the blockchain network are written into the outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0008] The smart contract is executed according to the transaction requests stored in the outer transaction pool to obtain the transaction data corresponding to the transaction requests;

[0009] The transaction data is written into the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store the executed transaction requests.

[0010] The transaction data stored in the inner transaction pool is stored on the blockchain.

[0011] According to one aspect of the embodiments of this application, a blockchain transaction processing apparatus is provided, characterized in that it includes:

[0012] The request writing module is configured to write transaction requests broadcast on the blockchain network into an outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0013] The contract execution module is configured to run smart contracts based on transaction requests stored in the outer transaction pool, and obtain transaction data corresponding to the transaction requests;

[0014] The data writing module is configured to write the transaction data into the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store the executed transaction requests.

[0015] The data upload module is configured to upload and store the transaction data stored in the inner transaction pool onto the blockchain.

[0016] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the blockchain transaction processing method as described in the above technical solutions.

[0017] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the executable instructions to implement the blockchain transaction processing method as described in the above technical solution.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the blockchain transaction processing method as described in the above technical solutions.

[0019] In some embodiments of this application, the computer program product or computer program includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the blockchain transaction processing method as described in the above technical solutions.

[0020] In the technical solution provided in this application embodiment, by configuring two cache spaces, an outer transaction pool and an inner transaction pool, on the blockchain node, transaction requests before execution and transaction requests after execution can be stored in the outer transaction pool and the inner transaction pool, respectively. Transaction requests stored in the outer transaction pool can be continuously executed, while transaction requests after execution stored in the memory transaction pool can be continuously packaged into blocks and uploaded to the chain. The asynchronous operation of transaction execution and block packaging and uploading to the chain improves the data processing efficiency in the transaction processing process.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 A schematic diagram of the composition of the blockchain system in an embodiment of this application is shown.

[0024] Figure 2 The structure of a blockchain maintained on a blockchain network is shown.

[0025] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is illustrated schematically.

[0026] Figure 4 A flowchart illustrating the steps of a blockchain transaction processing method in one embodiment of this application is shown.

[0027] Figure 5 The data structure of a transaction request prior to transaction execution is shown in one embodiment of this application.

[0028] Figure 6 The data structure of transaction data after transaction execution is shown in one embodiment of this application.

[0029] Figure 7 This application illustrates a blockchain transaction processing method based on consistency verification for filtering and processing transaction requests, as shown in one embodiment.

[0030] Figure 8 This application illustrates a blockchain transaction processing method for storing transactions on-chain based on read-write set conflict verification, according to one embodiment of the present application.

[0031] Figure 9 The flowchart illustrates the steps of a blockchain transaction processing method executed by a block packing node in an application scenario according to an embodiment of this application.

[0032] Figure 10 The flowchart illustrates the steps of a blockchain transaction processing method executed by a non-block packing node in an application scenario according to an embodiment of this application.

[0033] Figure 11 A schematic block diagram of the blockchain transaction processing apparatus provided in the embodiments of this application is shown.

[0034] Figure 12 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0035] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0036] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0037] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0038] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0039] In the specific implementation of this application, requests, responses and other related data generated when users apply blockchain products are involved. When the various embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0040] The specific embodiments of this application involve blockchain-related technical terms, which are explained below.

[0041] Blockchain: A shared, chained-block data structure built on transparent and trusted rules in a peer-to-peer network environment. It is designed to be tamper-proof, tamper-proof, and traceable. The chained-block data structure stores transactions occurring over a period of time in blocks, which are then linked chronologically using cryptographic algorithms. The ledger is distributed to all member nodes in the network, permanently recording the history of asset transactions between peer nodes in the sequential chain of blocks linked by hash cryptographic algorithms. All confirmed and verified transactions are linked from the beginning of the chain to the latest block, hence the name blockchain. A blockchain can serve as a single source of truth, and members of a blockchain network can only view transactions relevant to them.

[0042] Smart contracts, simply put, are a set of promises defined in digital form, including protocols that allow contract participants to execute these promises. Programs running on the blockchain are typically called smart contracts. Smart contracts are generally divided into system contracts and user contracts. System contracts are embedded in the blockchain's underlying code, have specific operating modes and permissions, and cannot be modified by users, only invoked. User contracts are written by users and published on the blockchain, executed by a virtual machine, and have strict access control.

[0043] A transaction is the basic unit for adding, deleting, and modifying data in a blockchain ledger. Multiple transactions are packaged into a block. A transaction must include at least the transaction initiator, the operation, and the initiator's signature. For blockchains that support smart contracts, the operation is generally a call to a contract method.

[0044] Read-write set: The collection of state data read and written when a method of a smart contract is executed.

[0045] Transaction pool: A cache space on blockchain nodes that stores a list of unpackaged transactions. When a node receives a transaction sent on the network, it first verifies the transaction's validity and whether it already exists. If it is valid and does not exist locally, the transaction is added to the transaction pool. When a node receives a new block, it verifies the block's validity. After verification, it not only updates its local ledger but also removes the transactions contained in this new block from the transaction pool.

[0046] Figure 1The diagram illustrates the composition of a blockchain system according to an embodiment of this application. The blockchain system 100 may include at least one client 110 and a blockchain network 120. The blockchain network 120 includes at least one blockchain node 121. The client 110 may be various electronic devices such as smartphones, tablets, laptops, desktop computers, smart wearable devices, smart in-vehicle devices, smart payment terminals, and facial recognition terminals. By installing a corresponding client application on the client 110, blockchain data services can be provided to users. The blockchain node 121 may be a terminal device or a server. For example, the blockchain node 121 may be an independent physical server, a server cluster consisting of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0047] In blockchain network 120, each blockchain node 121 receives input information during normal operation and maintains shared data within the blockchain network based on the received input information. To ensure information interoperability, information connections can exist between the various blockchain nodes 121, allowing them to transmit information to each other. For example, when any blockchain node 121 in blockchain network 120 receives input information and broadcasts it within the blockchain network 120, other node devices in blockchain network 120 can obtain the input information according to a consensus algorithm and store it as shared data.

[0048] Each blockchain node 121 in the blockchain network 120 has a corresponding node identifier. Each blockchain node 121 can also store the node identifiers of other blockchain nodes in the same blockchain network, so that the generated block can be broadcast to other nodes in the blockchain network 120 based on their node identifiers. Each blockchain node 121 can maintain a node identifier list as shown in Table 1, storing the node name and node identifier in this list. The node identifier can be an IP (Internet Protocol) address or any other information that can be used to identify the node. Table 1 shows a node identifier list using IP addresses as an example.

[0049] Table 1

[0050] Node 1 XXX.XXX.XXX.XXX Node 2 XXX.XXX.XXX.XXX … … Node N XXX.XXX.XXX.XXX

[0051] Figure 2 This illustrates the structural composition of a blockchain maintained on a blockchain network. For example... Figure 2As shown, a blockchain consists of multiple sequentially linked blocks. Whenever new data needs to be written to the blockchain, this data is aggregated into a newly generated block. This newly generated block is then linked to the end of the blockchain. A consensus algorithm ensures that the blocks added on each node device 121 are identical. The block body of each block records the data of the current block, while its block header stores the hash value of the preceding block. If the transaction data in the preceding block changes, the hash value of the current block will also change accordingly. Therefore, data uploaded to the blockchain network is difficult to tamper with, improving the reliability of shared data.

[0052] Figure 3 The network architecture of a blockchain network applying the technical solution of this application is illustrated schematically. For example... Figure 3 As shown, in application scenarios that realize online transactions and online payments, the transaction entity node 310, the transaction platform node 320, and the resource allocation node 330 located in the blockchain network jointly maintain one or more blockchains 340.

[0053] Transaction entity node 310 is a blockchain node that provides transaction services to users. For example, it can be a merchant or individual seller who conducts online transactions with users.

[0054] Transaction platform node 320 is a blockchain node that provides transaction scenarios for online transactions. For example, it can be an e-commerce website, an online mall, or various business platforms that provide online transaction services.

[0055] Resource allocation node 330 is a blockchain node that provides fund management and allocation services for network transactions, such as a third-party payment institution.

[0056] When a user conducts a network transaction with the transaction entity node 310, they can pay transaction funds to the transaction entity node 310 through an account opened on the resource allocation node 330. The transaction platform node 320, as the provider of the transaction scenario, needs to deduct a certain amount of funds from these transaction funds as a platform service fee. To achieve reliable fund allocation between the transaction entity node 310 and the transaction platform node 320, a corresponding smart contract (such as a revenue-sharing contract) can be established based on the blockchain network for fund allocation. When a network transaction occurs, the resource allocation node 330 can allocate funds to various objects in the transaction scenario according to the smart contract. Transaction data generated by network transactions on each blockchain node can be stored on the blockchain 340. Decentralized data storage can effectively avoid trust crises.

[0057] In some related technologies of this application, the execution of smart contracts is included in the consensus phase, and the consensus process is as follows:

[0058] (1) The transaction request initiated by the client is broadcast into the transaction pool of the block-producing node; the block-producing node obtains a certain number of transactions from the transaction pool according to the specified sorting method (usually sorted by transaction fee).

[0059] (2) These transactions are executed sequentially, the results of the smart contract execution are temporarily stored in memory, and the Merkle root used in the block header is constructed from these transactions and their structure.

[0060] (3) Continuously change the Nonce value in the block header until a block header that meets the POW requirements appears or a new block produced by other nodes is received, and the consensus of this block is considered to be completed.

[0061] This approach executes smart contracts during the consensus process, which inevitably leads to a slow consensus process and prevents a significant performance improvement. Furthermore, this approach requires strict control over the complexity of smart contract logic; overly complex and time-consuming smart contract execution will severely hinder the performance of the entire blockchain.

[0062] In some other related technologies of this application, a three-phase consensus model of "endorsement, ordering, and submission" can be adopted. The specific consensus process is as follows:

[0063] (1) The client initiates a transaction request to the “endorsing node”. The endorsing node is responsible for the execution of the smart contract. After the smart contract is executed, a read-write set is generated, and the contract execution result (including the read-write set) is attached to the transaction request and signed to form a complete transaction.

[0064] (2) The client sends the complete transaction, along with the contract execution result and endorsement signature, to the "sorting node". After receiving a certain number of complete transactions or after a certain time interval, the sorting node sorts and packages the received complete transactions and broadcasts the packaged blocks.

[0065] (3) After receiving a new block broadcast, the "commit node" verifies the legality of the block and performs conflict detection on the read-write set of transactions in the block. If there are read-write conflicting transactions in a block, only one transaction will be retained, and the other conflicting transactions will be marked as invalid. The commit node then updates its local ledger according to the marking. Although invalid transactions are packaged into the block, the state database will not be updated by the node.

[0066] In this scheme, smart contracts are executed on endorsing nodes, the consensus process is only responsible for sorting, and then the submitting nodes detect conflicts and mark invalid transactions. This scheme can cause transactions to fail due to conflicts, requiring clients to resend requests until the transaction succeeds, and also wastes a lot of disk space storing transactions marked as invalid.

[0067] To address the aforementioned technical problems in related technologies, this application provides a scheme for asynchronous processing of smart contract execution and consensus packaging based on a two-layer transaction pool. This scheme delegates the execution of smart contracts to the outer transaction pool asynchronously. Completed transactions, along with their results and read / write sets, are passed to the inner transaction pool. Block production only retrieves unpackaged transactions from the inner transaction pool. In this scheme, contract execution does not affect blockchain block production, thus supporting complex and time-consuming smart contracts and significantly improving blockchain performance. Furthermore, since only valid transactions are packaged during consensus accounting, there is no issue of marking invalid transactions. Therefore, clients do not need to submit multiple times to ensure correct on-chain execution of transactions; a single submission is sufficient. Moreover, because there are no invalid transactions in the block, disk utilization is higher, further improving performance.

[0068] The following detailed description of the technical solutions provided in this application, including the blockchain transaction processing method, blockchain transaction processing device, computer-readable medium, electronic device, and computer program product, is based on specific embodiments.

[0069] Figure 4 This application illustrates a flowchart of the steps of a blockchain transaction processing method in one embodiment. This blockchain transaction processing method can be performed by… Figure 1 The method executed by the client or blockchain node shown in this application embodiment is illustrated using a blockchain transaction processing method executed on a blockchain node as an example. Figure 4 As shown, the blockchain transaction processing method in this application embodiment includes the following steps S410 to S440.

[0070] S410: Write the transaction requests broadcast on the blockchain network into the outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0071] The blockchain network in this application embodiment can include any one of a public blockchain, a private blockchain, or a consortium blockchain. Among these, the public blockchain offers the highest degree of decentralization. Nodes / participants joining a public blockchain can read data on the chain, publish transactions, and compete for the right to record new blocks; moreover, nodes / participants can freely join and leave the public blockchain. Conversely, in a private blockchain, the recording rights and data reading rights are controlled by a specific organization or institution. There are fewer participants, and joining a private blockchain requires approval from the organization or institution. A consortium blockchain, also known as a community blockchain, refers to a blockchain whose consensus process is controlled by pre-selected nodes. It is a hybrid of public and private blockchains, achieving "partial decentralization." Each node on the chain typically has a corresponding entity or organization; participants join the network through authorization and form a consortium of interested parties to jointly maintain the blockchain's operation. Through a consortium blockchain, new participants can join an existing blockchain and share data without having to build it from scratch.

[0072] A transaction is initiated by a user through a client application. A user-initiated transaction includes the requested contract name, method name, parameters, transaction initiator, signature, and other additional information. It does not include the result of contract execution or the read / write set, so it is called a transaction request. Figure 5 This illustration shows the data structure of a transaction request prior to transaction execution in one embodiment of this application. For example... Figure 5 As shown, before the transaction is executed, the data structure of the transaction request includes multiple request data items 501, a parameter list 502, and an initiator signature 503.

[0073] Request data 501 contains various attribute data associated with a transaction request, such as transaction ID, initiator, invoked contract, invoked method, or other data.

[0074] Parameter list 502 is used to store transaction parameters involving data retrieval or modification when executing a transaction request. Parameter list 502 can be based on... Figure 5 The parameters are stored in key-value pairs as shown.

[0075] The originator signature 503 is a digital signature used to verify the reliability of the source and authenticity of the content of a transaction request.

[0076] The initiator can hold the public and private keys that make up the asymmetric key pair. When digitally signing a transaction request, the initiator can first extract a digest of the data content of the request using a digest extraction algorithm, and then use the private key to encrypt the digest to form a digital signature. This digital signature can be verified using the public key.

[0077] A content digest is a fixed-length string that uniquely corresponds to a piece of data content. It is generated by applying a one-way hash encryption function to the data content. If the data content is tampered with during network transmission, the alteration of the data content can be determined by comparing the content digests before and after transmission. Therefore, the integrity of data content can be verified based on the content digest. The content digest uses a one-way hash function to map the plaintext data content to be transmitted into a string of ciphertext, also known as a digital fingerprint. The content digest has a fixed length, and different plaintexts will always result in different ciphertexts, while the same plaintext will always have the same digest. The digest extraction algorithm in the embodiments of this application may include, for example, MD (Message Digest), SHA (Secure Hash Algorithm), MAC (Message Authentication Code), and other algorithms.

[0078] A digital signature is a message digest algorithm with a key, consisting of a public key and a private key, used to verify data integrity, authenticate data origin, and prevent repudiation. It follows the OSI reference model, using private key signing and public key verification. Digital signatures are also a combination of asymmetric encryption algorithms and message digest algorithms; available digital signature algorithms include RSA, DSA, or ECDSA.

[0079] Based on the RSA algorithm, a pair of RSA keys can be generated first. One is a secret key, which is kept by the business entity; the other is a public key, which can be made public and even registered on a web server. To improve security, RSA keys should be at least 500 bits long, with 1024 bits generally recommended. This makes the encryption computationally intensive. To reduce computation, when transmitting information, a combination of traditional encryption methods and public-key encryption methods is often used. That is, the information is encrypted using an improved DES or IDEA session key, and then the session key and message digest are encrypted using the RSA key. After receiving the information, the recipient decrypts it using different keys and can verify the message digest.

[0080] A key feature of DSA (Digital Signature Algorithm) is that two prime numbers are publicly disclosed. This allows any entity using p and q to verify whether they were randomly generated or forged / modified, even without knowing the private key.

[0081] ECDSA (Elliptic Curve Digital Signature Algorithm) is a combination of ECC (Elliptic Curve Cryptography) and DSA. The entire signing process is similar to DSA, but the difference is that the algorithm used in the signature is ECC, and the final signed value is also divided into two parameters, r and s.

[0082] S420: Runs a smart contract based on the transaction requests stored in the outer transaction pool to obtain the transaction data corresponding to the transaction requests.

[0083] Smart contracts, also known as chaincode or application code, are computer protocols designed to disseminate, verify, or execute contracts in an informational manner. Deployed on nodes within a blockchain network, they carry the business logic for executing transactions and run in an isolated environment (such as a container or virtual machine). Each node in the blockchain system automatically executes the contract program based on specific conditions, allowing manipulation of data stored on the chain. They are a crucial means for business entities to interact with the blockchain and utilize it to implement business logic. The purpose of smart contracts is to provide a more secure method than traditional contracts and reduce other transaction costs associated with contracts. They allow for trusted transactions without a third party, and these transactions are traceable and irreversible.

[0084] Transaction data generated based on smart contracts can be authenticated through consensus algorithms across different blockchain nodes, thereby ensuring that consistent transaction data is stored on each blockchain node. In one embodiment of this application, after a user conducts a network transaction and generates transaction data through a client running the blockchain system, the client can send a consensus request to the blockchain node it is communicating with. The blockchain node receiving the consensus request can broadcast it on the blockchain network, enabling the consensus request to be transmitted to all blockchain nodes in the blockchain network.

[0085] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as master nodes to handle consensus requests, and the other blockchain nodes in the blockchain network besides the master node serve as slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, which then distributes the consensus request to each slave node. The master node can be generated through voting, round-robin assignment, or random selection.

[0086] In one embodiment of this application, a smart contract can be run locally on a blockchain node. The process involves obtaining the blockchain ledger maintained by the blockchain node; running the smart contract based on the transaction request stored in the outer transaction pool and the blockchain ledger to obtain the contract execution result and read / write set corresponding to the transaction request. The read / write set is a collection of data for reading or writing data from the blockchain ledger; and associating the contract execution result, the read / write set, and the transaction request to obtain the transaction data corresponding to the transaction request.

[0087] In one embodiment of this application, after associating the contract execution result, read / write set, and transaction request, the current block height of the blockchain ledger can also be obtained; the current block height is then associated with the transaction request so that the transaction data carries the current block height.

[0088] In one embodiment of this application, the current blockchain node can send the transaction request stored in the outer transaction pool to the endorsement node in the blockchain network; obtain the transaction data corresponding to the transaction request returned by the endorsement node after running the smart contract, and the transaction data carries the endorsement signature of the endorsement node.

[0089] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as endorsement nodes to process transaction requests. Endorsement nodes can be generated through voting, rotating designation, or random selection. When a transaction request is generated on the blockchain network, the request can be sent to the endorsement node. The endorsement node then runs a smart contract to obtain the transaction data corresponding to the transaction request, and further broadcasts the transaction data to other blockchain nodes in the blockchain network.

[0090] Transaction data is the complete post-execution transaction formed by attaching the contract execution result and read / write set to the transaction request. Figure 6 This illustration shows the data structure of transaction data after transaction execution in one embodiment of this application. For example... Figure 6 As shown, after the transaction is executed, the data structure of the transaction data includes the transaction request 601, the contract execution result 602 appended to the transaction request 601, the read / write set 603, and the current block height 604.

[0091] Transaction request 601 can have the following characteristics: Figure 5 The data structure shown will not be described in detail here.

[0092] Contract execution result 602 may include a return value and an event log. The return value represents the response data that needs to be returned to the initiator after the transaction is completed; the event log consists of a subject and a log, used to record the transaction execution event.

[0093] The Read Set (603) comprises a Read Set and a Write Set. The Read Set contains a list of keys with unique keys, along with committed key-value pairs read during transaction execution. The Write Set also contains a list of keys with unique keys, along with key-value pairs written during transaction execution. If a key is deleted during a transaction, a deletion marker is recorded in the Write Set. If the same key is updated multiple times within a transaction, the last updated key-value pair is used. The Read Set contains versions of keys, while the Write Set only contains the latest value for each key.

[0094] The current block height of 604 indicates the location index of the transaction data on the blockchain. The current block height can be a tuple Height(blockNumber, txNumber), where blockNumber is the block number and txNumber is the transaction sequence number within the block.

[0095] In one embodiment of this application, all transaction requests stored in the outer transaction pool are unexecuted transactions. When a smart contract is invoked to execute any transaction request in the outer transaction pool and obtain the corresponding transaction data, the transaction request can be removed from the outer transaction pool.

[0096] S430: Write transaction data to the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store executed transaction requests.

[0097] In one embodiment of this application, the outer transaction pool has a background task for executing smart contracts. When a new transaction request is added to the outer transaction pool after verification that it does not exist in the blockchain ledger and the existing transaction pool, the background task is responsible for running the smart contract based on the latest blockchain ledger and generating read / write sets, events, results, etc., as well as the current block height. This information is attached to the transaction request to form complete transaction data. Subsequently, the outer transaction pool deletes the transaction request and adds the corresponding transaction data to the inner transaction pool.

[0098] In one embodiment of this application, after a blockchain node completes the execution of a transaction request and obtains the corresponding transaction data, the transaction data corresponding to the transaction request can be directly written into the inner transaction pool maintained by the blockchain node, awaiting packaging and on-chain processing. The advantage of directly transferring transaction data to the inner transaction pool is that it can reduce the number of data consensus steps on the blockchain network, and simultaneously complete the consensus authentication of transaction data and newly generated blocks during the packaging and on-chain process.

[0099] In one embodiment of this application, after a blockchain node completes the execution of a transaction request and obtains the corresponding transaction data, the transaction data can first undergo consensus authentication on the blockchain network. The authenticated transaction data is then transferred to the inner transaction pool maintained by the blockchain node, awaiting packaging and on-chain processing. Performing consensus authentication on the transaction data first, and then transferring the authenticated transaction data to the inner transaction pool, allows the execution process of the transaction request to be synchronized with the consensus process of the transaction data, further improving data processing efficiency and increasing the consensus authentication speed and on-chain processing speed of newly generated blocks.

[0100] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as master nodes to handle consensus requests, and the other blockchain nodes in the blockchain network besides the master node serve as slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, which then distributes the consensus request to each slave node. The master node can be generated through voting, round-robin assignment, or random selection.

[0101] S440: Store transaction data stored in the inner transaction pool on the blockchain.

[0102] Each block in a blockchain comprises two data storage areas: a block header and a block body. The block body stores all the data recorded in the current block. The block header stores the link information between the current block and the previous block. Using the data stored in the block header, all blocks can be linked one by one to form a complete blockchain. When the block generation conditions are met, the transaction data stored in the inner transaction pool can be packaged and written into the block body of the current block to be added to the chain. Simultaneously, the block header data of the previous block (i.e., the most recently generated block) in the blockchain ledger can be obtained. Based on this block header data, the parent block characteristic value of the current block can be calculated. For example, the SHA256 algorithm can be used to hash the block header data of the previous block to obtain a hash value, which can then be used as the parent block characteristic value of the current block. The block generation conditions can be a specified time threshold since the previous block was generated, a specified data volume threshold for the transaction data stored in the inner transaction pool, or other preset conditions that trigger the generation of a new block. This application embodiment does not specifically limit these conditions.

[0103] Based on the data stored in the block body, a hash value can be obtained as the block body characteristic value of the current block. Taking hash encoding as an example, all data in the block body can be stored in the form of a Merkle Tree. Specifically, the data can be stored in the leaf nodes of the Merkle Tree. The data stored in every two adjacent leaf nodes is combined and hashed again to obtain the hash value stored in a child node. By using this method of combining the hash values ​​stored in child nodes and performing hash operations layer by layer upwards, a root node hash value can be obtained. This root node hash value can be used as the block body characteristic value of the current block.

[0104] After calculating the parent block feature value and the block body feature value, a timestamp can be generated based on the current time. This timestamp records the generation time of the current block. Then, the parent block feature value, the block body feature value, and the timestamp are stored together in the block header of the current block. The current block, consisting of the block header and block body, is broadcast to the blockchain network for consensus authentication. After successful consensus authentication, all or some of the blockchain nodes in the blockchain network save the current block, thus completing the process of adding the current block to the blockchain ledger.

[0105] This application embodiment, by configuring an outer transaction pool and an inner transaction pool, can control the asynchronous execution of the transaction request execution process and the packaging and on-chain process. Furthermore, to avoid the problem of duplicate execution of transaction requests, this application embodiment can perform consistency verification on transaction requests written to the outer transaction pool. Figure 7 This application illustrates a blockchain transaction processing method based on consistency verification for filtering and processing transaction requests, as shown in one embodiment. Figure 7 As shown, the method may include the following steps S710 to S760.

[0106] S710: Retrieves transaction requests broadcast on the blockchain network.

[0107] In one embodiment of this application, the transaction request can be initiated by a client or by a blockchain node. When a client initiates a transaction request, it can send the request to one or more blockchain nodes that have a direct communication connection with the client. Upon receiving the transaction request, the blockchain node can broadcast it on the blockchain network, ensuring that all blockchain nodes in the network store the same transaction request.

[0108] The data structure of a transaction request is as follows: Figure 5 As shown, it will not be elaborated further here.

[0109] S720: Perform consistency verification on the transaction request to determine whether there is data consistent with the transaction request in the data space of the blockchain node. The data space includes at least one of the outer transaction pool, inner transaction pool, or blockchain ledger maintained by the blockchain node.

[0110] When a blockchain node receives a transaction request for the first time, it can save the request to its own maintained outer transaction pool. If the node completes the execution of the request, it can write the transaction data carrying the request to its own maintained inner transaction pool, awaiting packaging and on-chain processing. Once the node completes the packaging and on-chain processing of the transaction data, it can connect the blockchain containing the transaction request to the blockchain ledger. Thus, transaction requests can be transferred between different data spaces at different stages of transaction processing. Furthermore, when a blockchain node receives a transaction request broadcast from another blockchain node, it can perform consistency verification to determine if identical data exists in its data space. If identical data exists in any data space, the transaction request has already been processed and does not require reprocessing.

[0111] S730: If there is no data in the data space that matches the transaction request, the transaction request will be written to the outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0112] If no data matching the transaction request exists in any of the data spaces, such as the outer transaction pool, the inner transaction pool, or the blockchain ledger, it means that the blockchain node has received the transaction request for the first time. At this time, the transaction request can be written to the outer transaction pool maintained by the blockchain node, waiting for the corresponding smart contract to be called to execute the specific transaction operation.

[0113] The outer transaction pool only stores transaction requests that have not yet been executed. Once a transaction request has been executed, it can be removed from the outer transaction pool.

[0114] S740: Runs smart contracts based on transaction requests stored in the outer transaction pool to obtain transaction data corresponding to the transaction requests.

[0115] In one embodiment of this application, a smart contract can be run locally on a blockchain node. The process involves obtaining the blockchain ledger maintained by the blockchain node; running the smart contract based on the transaction request stored in the outer transaction pool and the blockchain ledger to obtain the contract execution result and read / write set corresponding to the transaction request. The read / write set is a collection of data for reading or writing data from the blockchain ledger; and associating the contract execution result, the read / write set, and the transaction request to obtain the transaction data corresponding to the transaction request.

[0116] In one embodiment of this application, after associating the contract execution result, read / write set, and transaction request, the current block height of the blockchain ledger can also be obtained; the current block height is then associated with the transaction request so that the transaction data carries the current block height.

[0117] In one embodiment of this application, the current blockchain node can send the transaction request stored in the outer transaction pool to the endorsement node in the blockchain network; obtain the transaction data corresponding to the transaction request returned by the endorsement node after running the smart contract, and the transaction data carries the endorsement signature of the endorsement node.

[0118] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as endorsement nodes to process transaction requests. Endorsement nodes can be generated through voting, rotating designation, or random selection. When a transaction request is generated on the blockchain network, the request can be sent to the endorsement node. The endorsement node then runs a smart contract to obtain the transaction data corresponding to the transaction request, and further broadcasts the transaction data to other blockchain nodes in the blockchain network.

[0119] Transaction data is the complete executed transaction formed by attaching the contract execution result and read / write set to the transaction request. Its data structure is as follows: Figure 6 As shown, it will not be elaborated further here.

[0120] Transaction data generated based on smart contracts can be authenticated through consensus algorithms across different blockchain nodes, thereby ensuring that consistent transaction data is stored on each blockchain node. In one embodiment of this application, after a user conducts a network transaction and generates transaction data through a client running the blockchain system, the client can send a consensus request to the blockchain node it is communicating with. The blockchain node receiving the consensus request can broadcast it on the blockchain network, enabling the consensus request to be transmitted to all blockchain nodes in the blockchain network.

[0121] In one embodiment of this application, one or more blockchain nodes can be selected from the blockchain network as master nodes to handle consensus requests, and the other blockchain nodes in the blockchain network besides the master node serve as slave nodes. When a client generates a consensus request, it can first send the consensus request to the master node, which then distributes the consensus request to each slave node. The master node can be generated through voting, round-robin assignment, or random selection.

[0122] In one embodiment of this application, all transaction requests stored in the outer transaction pool are unexecuted transactions. When a smart contract is invoked to execute any transaction request in the outer transaction pool and obtain the corresponding transaction data, the transaction request can be removed from the outer transaction pool.

[0123] S750: Writes transaction data to the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store executed transaction requests.

[0124] In one embodiment of this application, the outer transaction pool has a background task for executing smart contracts. When a new transaction request is added to the outer transaction pool after verification that it does not exist in the blockchain ledger and the existing transaction pool, the background task is responsible for running the smart contract based on the latest blockchain ledger and generating read / write sets, events, results, etc., as well as the current block height. This information is attached to the transaction request to form complete transaction data. Subsequently, the outer transaction pool deletes the transaction request and adds the corresponding transaction data to the inner transaction pool.

[0125] In one embodiment of this application, after a blockchain node completes the execution of a transaction request and obtains the corresponding transaction data, the transaction data corresponding to the transaction request can be directly written into the inner transaction pool maintained by the blockchain node, awaiting packaging and on-chain processing. The advantage of directly transferring transaction data to the inner transaction pool is that it can reduce the number of data consensus steps on the blockchain network, and simultaneously complete the consensus authentication of transaction data and newly generated blocks during the packaging and on-chain process.

[0126] In one embodiment of this application, after a blockchain node completes the execution of a transaction request and obtains the corresponding transaction data, the transaction data can first undergo consensus authentication on the blockchain network. The authenticated transaction data is then transferred to the inner transaction pool maintained by the blockchain node, awaiting packaging and on-chain processing. Performing consensus authentication on the transaction data first, and then transferring the authenticated transaction data to the inner transaction pool, allows the execution process of the transaction request to be synchronized with the consensus process of the transaction data, further improving data processing efficiency and increasing the consensus authentication speed and on-chain processing speed of newly generated blocks.

[0127] S760: Stores transaction data stored in the inner transaction pool on the blockchain.

[0128] In one embodiment of this application, when the block generation conditions are met, the transaction data stored in the inner transaction pool can be packaged and written into the block body of the current block to be uploaded to the blockchain. Simultaneously, the block header data of the previous block (i.e., the most recently generated block) in the blockchain ledger can be obtained, and the parent block characteristic value of the current block can be calculated based on this block header data. For example, the SHA256 algorithm can be used to perform a hash operation on the block header data of the previous block to obtain a hash value, which can then be used as the parent block characteristic value of the current block. The block generation conditions can be a specified time threshold since the previous block was generated, or a specified data volume threshold for the transaction data stored in the inner transaction pool, or other preset conditions used to trigger the generation of a new block. This embodiment of the application does not specifically limit these conditions.

[0129] Based on the data stored in the block body, a hash value can be obtained as the block body characteristic value of the current block. Taking hash encoding as an example, all data in the block body can be stored in the form of a Merkle Tree. Specifically, the data can be stored in the leaf nodes of the Merkle Tree. The data stored in every two adjacent leaf nodes is combined and hashed again to obtain the hash value stored in a child node. By using this method of combining the hash values ​​stored in child nodes and performing hash operations layer by layer upwards, a root node hash value can be obtained. This root node hash value can be used as the block body characteristic value of the current block.

[0130] After calculating the parent block feature value and the block body feature value, a timestamp can be generated based on the current time. This timestamp records the generation time of the current block. Then, the parent block feature value, the block body feature value, and the timestamp are stored together in the block header of the current block. The current block, consisting of the block header and block body, is broadcast to the blockchain network for consensus authentication. After successful consensus authentication, all or some of the blockchain nodes in the blockchain network save the current block, thus completing the process of adding the current block to the blockchain ledger.

[0131] Figure 8 This paper illustrates a blockchain transaction processing method based on read-write set conflict verification for on-chain transaction storage, as shown in one embodiment of this application. Figure 8 As shown, the method includes the following steps S810 to S860.

[0132] S810: Writes the transaction requests broadcast on the blockchain network into the outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0133] In one embodiment of this application, the transaction request can be initiated by a client or by a blockchain node. When a client initiates a transaction request, it can send the request to one or more blockchain nodes that have a direct communication connection with the client. Upon receiving the transaction request, the blockchain node can broadcast it on the blockchain network, ensuring that all blockchain nodes in the network store the same transaction request.

[0134] When a blockchain node receives a transaction request for the first time, it can save the request to its own maintained outer transaction pool. If the node completes the execution of the request, it can write the transaction data carrying the request to its own maintained inner transaction pool, awaiting packaging and on-chain processing. Once the node completes the packaging and on-chain processing of the transaction data, it can connect the blockchain containing the transaction request to the blockchain ledger. Thus, transaction requests can be transferred between different data spaces at different stages of transaction processing. Furthermore, when a blockchain node receives a transaction request broadcast from another blockchain node, it can perform consistency verification to determine if identical data exists in its data space. If identical data exists in any data space, the transaction request has already been processed and does not require reprocessing.

[0135] If no data matching the transaction request exists in any of the data spaces, such as the outer transaction pool, the inner transaction pool, or the blockchain ledger, it means that the blockchain node has received the transaction request for the first time. At this time, the transaction request can be written to the outer transaction pool maintained by the blockchain node, waiting for the corresponding smart contract to be called to execute the specific transaction operation.

[0136] The outer transaction pool only stores transaction requests that have not yet been executed. Once a transaction request has been executed, it can be removed from the outer transaction pool.

[0137] S820: Runs smart contracts based on transaction requests stored in the outer transaction pool to obtain transaction data corresponding to the transaction requests.

[0138] Transaction data generated based on smart contracts can be authenticated through consensus algorithms across different blockchain nodes, thereby ensuring that consistent transaction data is stored on each blockchain node. In one embodiment of this application, after a user conducts a network transaction and generates transaction data through a client running the blockchain system, the client can send a consensus request to the blockchain node it is communicating with. The blockchain node receiving the consensus request can broadcast it on the blockchain network, enabling the consensus request to be transmitted to all blockchain nodes in the blockchain network.

[0139] In one embodiment of this application, a smart contract can be run locally on a blockchain node. The process involves obtaining the blockchain ledger maintained by the blockchain node; running the smart contract based on transaction requests stored in the outer transaction pool and the blockchain ledger to obtain the contract execution result and read / write set corresponding to the transaction request. The read / write set is a collection of data that has been read from or written to the blockchain ledger; and associating the contract execution result, read / write set, and transaction request to obtain transaction data corresponding to the transaction request. After associating the contract execution result, read / write set, and transaction request, the current block height of the blockchain ledger can also be obtained; and the current block height can be associated with the transaction request so that the transaction data carries the current block height.

[0140] In one embodiment of this application, the current blockchain node can send transaction requests stored in the outer transaction pool to the endorsing node in the blockchain network; obtain the transaction data corresponding to the transaction request returned by the endorsing node after running the smart contract, the transaction data carrying the endorsement signature of the endorsing node. One or more blockchain nodes can be selected from the blockchain network as endorsing nodes to process transaction requests, and endorsing nodes can be generated through voting, round-robin designation, or random selection. When a transaction request is generated on the blockchain network, the transaction request can be sent to the endorsing node, which will then run the smart contract to obtain the transaction data corresponding to the transaction request, and further broadcast the transaction data to other blockchain nodes in the blockchain network.

[0141] In one embodiment of this application, all transaction requests stored in the outer transaction pool are unexecuted transactions. When a smart contract is invoked to execute any transaction request in the outer transaction pool and obtain the corresponding transaction data, the transaction request can be removed from the outer transaction pool.

[0142] S830: Writes transaction data to the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store executed transaction requests.

[0143] The outer transaction pool has a background task for executing smart contracts. When a new transaction request is added to the outer transaction pool after verification that it does not exist in the blockchain ledger or the existing transaction pool, the background task is responsible for running the smart contract based on the latest blockchain ledger and generating read / write sets, events, results, and the current block height. This information is attached to the transaction request to form complete transaction data. Subsequently, the outer transaction pool deletes the transaction request and adds the corresponding transaction data to the inner transaction pool. After a blockchain node completes the execution process of a transaction request and obtains the corresponding transaction data, this embodiment can directly write the transaction data corresponding to the transaction request into the inner transaction pool maintained by the blockchain node, waiting for packaging and on-chain. The advantage of directly transferring transaction data to the inner transaction pool is that it can reduce the number of data consensus steps on the blockchain network, and simultaneously complete the consensus authentication of the transaction data and the newly generated block during the packaging and on-chain process.

[0144] In some alternative implementations, after a blockchain node completes the execution of a transaction request and obtains the corresponding transaction data, the transaction data can first undergo consensus authentication on the blockchain network. The authenticated transaction data is then transferred to the inner transaction pool maintained by the blockchain node, awaiting packaging and on-chain processing. Performing consensus authentication on the transaction data first, and then transferring the authenticated transaction data to the inner transaction pool, allows the execution of the transaction request and the consensus process of the transaction data to be synchronized, further improving data processing efficiency and increasing the consensus authentication speed and on-chain processing speed of newly generated blocks.

[0145] S840: Perform read-write set conflict verification on the transaction data stored in the inner transaction pool to determine whether there are data conflicts between the read-write sets of each transaction data.

[0146] Because transactions are executed asynchronously, data conflicts may occur between the read and write sets of various transactions. Read-write set conflict verification can determine whether such conflicts exist. For example, the first transaction executes a write operation on key K, updating it from the first version's value V1 to the second version's value V2. The second transaction executes a read operation on key K, but since the first transaction's data has not yet been stored on the blockchain, the current blockchain node reads key K as the first version's value V1. This results in a data conflict between the read and write sets of the first and second transactions.

[0147] S850: Mark transaction data with data conflicts as conflicting transactions, and mark other transactions in the inner transaction pool that are not conflicting transactions as conflict-free transactions.

[0148] For conflicting transactions stored in the inner transaction pool, the transaction requests for these conflicting transactions can be rewritten to the outer transaction pool. The latest block height transmitted from the inner transaction pool to the outer transaction pool is obtained; this latest block height is the block height of the block to be added to the blockchain. If the blockchain ledger has been updated to the latest block height, the transaction requests for the conflicting transactions stored in the outer transaction pool are re-executed based on the updated blockchain ledger. If the blockchain ledger has not yet been updated to the latest block height, the execution of transaction requests for the conflicting transactions is suspended to avoid recurring read-write set conflicts.

[0149] S860: Store conflict-free transactions on the blockchain.

[0150] Blockchain nodes can first package the conflict-free transactions stored in the inner transaction pool into blocks to be uploaded to the blockchain, and then broadcast the blocks to be uploaded to the blockchain network; if the blockchain network completes the consensus authentication of the blocks to be uploaded to the blockchain, then the blockchain to be uploaded to the blockchain ledger will be connected.

[0151] The above embodiments provide a scheme for any blockchain node to act as a block packaging node for storing transaction data on the blockchain. In some embodiments of this application, one or more designated block packaging nodes in the blockchain network can package and upload blocks to the blockchain, while other blockchain nodes can synchronize the block upload results through consensus authentication.

[0152] In one embodiment of this application, the method for non-block packing nodes to store transaction data stored in the inner transaction pool on the blockchain may include: obtaining blocks to be uploaded to the blockchain broadcast on the blockchain network; sending the identification information of the transaction requests carried in the blocks to be uploaded to the inner transaction pool; performing consistency verification between the blocks to be uploaded and the transaction data stored in the inner transaction pool according to the identification information; and connecting the blockchain to be uploaded to the blockchain ledger when all transaction data in the blocks to be uploaded passes the consistency verification.

[0153] In one embodiment of this application, a method for verifying the consistency between the block to be added to the blockchain and the transaction data stored in the inner transaction pool based on the identification information may include: if there is a transaction request in the inner transaction pool that matches the identification information, then obtain the transaction data corresponding to the transaction request stored in the inner transaction pool; compare the content of the transaction data corresponding to the transaction request stored in the inner transaction pool with the transaction data carried in the block to be added to the blockchain to determine whether the content comparison of the transaction data is consistent; if the content comparison of the transaction data is inconsistent or there is no transaction request in the inner transaction pool that matches the identification information, then send the transaction request corresponding to the identification information to the outer transaction pool; execute the transaction request corresponding to the identification information on the outer transaction pool to obtain updated transaction data, and perform a consistency verification between the updated transaction data and the transaction data stored in the block to be added to the blockchain.

[0154] In one embodiment of this application, after connecting the blockchain to be added to the blockchain ledger, the transaction requests corresponding to the blocks to be added to the blockchain stored in the outer transaction pool can be removed, and the transaction data corresponding to the blocks to be added to the blockchain stored in the inner transaction pool can be removed.

[0155] Figure 9 This diagram illustrates a flowchart of the blockchain transaction processing method executed by a block packaging node in an application scenario according to an embodiment of this application. The blockchain node contains an outer transaction pool and an inner transaction pool. Both pools cache unpackaged transactions; however, the outer transaction pool contains only transaction requests, while the inner transaction pool contains complete transactions including contract execution results and read / write sets. Figure 9 As shown, after the client initiates a transaction request to the block packaging node, the blockchain transaction processing method executed by the block packaging node includes the following steps.

[0156] S901: The outer transaction pool of the block packaging node runs smart contracts and attaches execution results and read / write sets to transaction requests to form complete transaction data.

[0157] The outer transaction pool has a background task for executing contracts. When a new transaction request is added to the outer transaction pool after verification that it does not exist in the blockchain ledger and the existing transaction pool, the background task is responsible for running the contract based on the latest ledger and generating read / write sets, events, results, etc., as well as the current block height. All this information is attached to the transaction request to form a complete transaction.

[0158] S902: The outer transaction pool transfers the complete transaction data to the inner transaction pool and deletes the transaction request from the outer transaction pool.

[0159] S903: The inner transaction pool writes transaction data into the unpacked transaction set, waiting to be packaged and uploaded to the chain.

[0160] S904: When a block packaging node triggers a block production operation, it obtains a batch of complete transaction data from the inner transaction pool through the block packaging core engine.

[0161] S905: The block packaging core engine performs read / write set conflict detection on the acquired transaction data, packages conflict-free transactions into new blocks, and updates the blockchain ledger.

[0162] S906: The block packaging core engine returns transaction requests with read-write set conflicts to the outer transaction pool.

[0163] S907: After receiving the transaction request returned by the block packaging core engine, the outer transaction pool re-runs the smart contract based on the ledger of the new block, generating a new contract result, read / write set and block height, forming a new complete transaction.

[0164] S908: The outer trading pool sends the complete transaction to the inner trading pool again.

[0165] S909: The inner transaction pool writes the transaction data back into the unpacked transaction set, waiting for the next packaging and on-chain process.

[0166] Upon receiving transaction requests from the block packaging core engine, the outer transaction pool also obtains the latest block height from the core engine and waits for a block at that height to be written to the ledger. If the blockchain ledger has not been written to the specified height, the transaction request will not be re-executed. After block consensus is achieved, the blockchain ledger is updated to the latest block height, and the outer transaction pool begins to re-execute these new transaction requests, appending the results to form a complete transaction, which is then entered into the inner transaction pool. This process is repeated.

[0167] Figure 10 This document illustrates a flowchart of the steps involved in a blockchain transaction processing method executed by a non-block packing node in an application scenario, according to an embodiment of this application. Figure 10 As shown, the method includes the following steps.

[0168] S1001: After receiving a new block broadcast and synchronized on the blockchain network, the blockchain core engine verifies the legality of the block and the correctness of the transaction results in the block.

[0169] S1002: After successful verification, the blockchain core engine sends the transaction ID contained in the new block to the inner transaction pool.

[0170] S1003: The inner transaction pool query retrieves a transaction dataset consisting of transaction data corresponding to the transaction ID.

[0171] S1004: The inner transaction pool returns the transaction dataset to the blockchain core engine.

[0172] S1005: The blockchain core engine checks whether the transaction data corresponding to the transaction ID has been found, or checks whether the transaction data is consistent with the newly generated block.

[0173] S1006: If the transaction returned by the inner transaction pool is inconsistent with the transaction result of the new block, or if no corresponding complete transaction is found, the blockchain core engine will send the transaction request that needs to be re-executed to the outer transaction pool.

[0174] S1007: The outer transaction pool re-executes the smart contract of the transaction request based on the updated blockchain ledger, attaching the contract execution result and read / write set to the transaction request to form complete transaction data.

[0175] S1008: The outer transaction pool will return the transaction data obtained after re-execution to the blockchain core engine.

[0176] S1009: After obtaining all transaction results, the blockchain core engine compares them with the transactions in the newly generated block. If the comparison matches, the local blockchain ledger is updated according to the newly generated block. If the comparison does not match, the update of the block is abandoned.

[0177] S1010: The blockchain core engine sends a notification to the outer and inner transaction pools to delete the packaged transactions.

[0178] The technical solution provided in this application allows for asynchronous execution of smart contracts and the generation of new blocks. This eliminates the need for consensus nodes to execute smart contracts sequentially according to transaction order during block production, significantly improving blockchain performance. Unlike blockchains using endorsement nodes, this solution performs read / write conflict detection during consensus block production and removes conflicting transactions from the transaction list, sending them to an outer transaction pool. This avoids clients repeatedly re-initiating the same transaction request due to failed transaction marking. Furthermore, because there are no invalid transactions in the blockchain, it also reduces the disk space required for the blockchain network.

[0179] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0180] The following describes an apparatus embodiment of this application, which can be used to execute the blockchain consensus method in the above embodiments of this application. Figure 11 A schematic block diagram of a blockchain transaction processing apparatus provided in an embodiment of this application is shown. Figure 11 As shown, the blockchain transaction processing device 1100 includes:

[0181] The request writing module 1110 is configured to write transaction requests broadcast on the blockchain network into an outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution.

[0182] The contract execution module 1120 is configured to run smart contracts based on transaction requests stored in the outer transaction pool, and obtain transaction data corresponding to the transaction requests;

[0183] The data writing module 1130 is configured to write the transaction data into the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store the executed transaction requests.

[0184] The data upload module 1140 is configured to upload and store the transaction data stored in the inner transaction pool onto the blockchain.

[0185] In some embodiments of this application, the request write module 1110 may further include:

[0186] The request acquisition module is configured to acquire transaction requests broadcast on the blockchain network;

[0187] The request verification module is configured to perform consistency verification on the transaction request to determine whether there is data consistent with the transaction request in the data space of the blockchain node. The data space includes at least one of the outer transaction pool, inner transaction pool, or blockchain ledger maintained by the blockchain node.

[0188] The data writing module is configured to write the transaction request into the outer transaction pool maintained by the blockchain node if there is no data in the data space that matches the transaction request.

[0189] In some embodiments of this application, the contract execution module 1120 may further include:

[0190] The ledger acquisition module is configured to acquire the blockchain ledger maintained by the blockchain node;

[0191] The ledger execution module is configured to obtain the contract execution result and read / write set corresponding to the transaction request based on the transaction request stored in the outer transaction pool and the blockchain ledger execution smart contract. The read / write set is a data set for reading or writing data to the blockchain ledger.

[0192] The request association module is configured to associate the contract execution result, the read / write set, and the transaction request to obtain transaction data corresponding to the transaction request.

[0193] In some embodiments of this application, the contract execution module 1120 may further include:

[0194] The height acquisition module is configured to acquire the current block height of the blockchain ledger;

[0195] The high-association module is configured to associate the current block height with the transaction request so that the transaction data carries the current block height.

[0196] In some embodiments of this application, the contract execution module 1120 may further include:

[0197] The request sending module is configured to send transaction requests stored in the outer transaction pool to the endorsement nodes in the blockchain network;

[0198] The data acquisition module is configured to acquire transaction data corresponding to the transaction request returned by the endorsing node after running the smart contract, wherein the transaction data carries the endorsement signature of the endorsing node.

[0199] In some embodiments of this application, the transaction data includes a read-write set, which is a collection of data for reading or writing data to the blockchain ledger; the data on-chain module 1140 may further include:

[0200] The conflict verification module is configured to perform read-write set conflict verification on the transaction data stored in the inner transaction pool to determine whether there is a data conflict between the read-write sets of each transaction data item.

[0201] The transaction marking module is configured to mark transaction data with data conflicts as conflicting transactions, and mark other transactions in the inner transaction pool other than the conflicting transactions as conflict-free transactions;

[0202] The transaction on-chain module is configured to store the conflict-free transactions on the blockchain.

[0203] In some embodiments of this application, the transaction on-chain module may be further configured to: package the conflict-free transactions into blocks to be on-chain; broadcast the blocks to be on-chain to the blockchain network; and if the blockchain network completes consensus authentication of the blocks to be on-chain, connect the blockchain to the blockchain ledger.

[0204] In some embodiments of this application, the data uplink module 1140 may further include:

[0205] The request rewrite module is configured to rewrite the transaction request of the conflicting transaction into the outer transaction pool;

[0206] The height acquisition module is configured to acquire the latest block height transmitted from the inner transaction pool to the outer transaction pool, wherein the latest block height is the block height of the block to be added to the chain;

[0207] The re-execution module is configured to re-execute the transaction requests of the conflicting transactions stored in the outer transaction pool according to the updated blockchain ledger if the blockchain ledger is updated to the latest block height.

[0208] In some embodiments of this application, the data uplink module 1140 may further include:

[0209] The block retrieval module is configured to retrieve blocks broadcast on the blockchain network that are yet to be added to the chain.

[0210] The information sending module is configured to send the identification information of the transaction request carried in the block to be added to the chain to the inner transaction pool;

[0211] The consistency verification module is configured to perform consistency verification between the area to be added to the chain and the transaction data stored in the inner transaction pool based on the identification information.

[0212] The block-to-chain module is configured to connect the blockchain to the blockchain ledger when all transaction data in the block to be added to the chain passes the consistency check.

[0213] In some embodiments of this application, the consistency verification module may be further configured as follows:

[0214] If a transaction request that matches the identification information exists in the inner transaction pool, then the transaction data corresponding to the transaction request stored in the inner transaction pool is obtained;

[0215] The transaction data corresponding to the transaction request stored in the inner transaction pool is compared with the transaction data carried in the block to be uploaded to the chain to determine whether the content comparison of the transaction data is consistent.

[0216] If the content of the transaction data does not match or there is no transaction request in the inner transaction pool that matches the identification information, then the transaction request corresponding to the identification information is sent to the outer transaction pool.

[0217] The transaction request corresponding to the identification information is executed on the outer transaction pool to obtain updated transaction data, and the updated transaction data is then checked for consistency with the transaction data stored in the block to be uploaded to the blockchain.

[0218] In some embodiments of this application, the blockchain transaction processing apparatus may further include:

[0219] The outer transaction pool removal module is configured to remove transaction requests corresponding to the block to be added to the chain that are stored in the outer transaction pool;

[0220] The inner transaction pool removal module is configured to remove transaction data corresponding to the block to be added to the blockchain that is stored in the inner transaction pool.

[0221] The specific details of the blockchain consensus device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0222] Figure 12 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0223] It should be noted that, Figure 12 The computer system 1200 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0224] like Figure 12 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1202 or programs loaded from storage section 1208 into random access memory (RAM). The RAM 1203 also stores various programs and data required for system operation. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output interface 1205 (I / O interface) is also connected to the bus 1204.

[0225] The following components are connected to the input / output interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a local area network card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the input / output interface 1205 as needed. A removable medium 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1210 as needed so that computer programs read from it can be installed into the storage section 1208 as needed.

[0226] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit 1201, it performs various functions defined in the system of this application.

[0227] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0228] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0229] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0230] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0231] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0232] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A blockchain transaction processing method, characterized in that, The method includes: Transaction requests broadcast on the blockchain network are written into the outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution. The smart contract is executed according to the transaction request stored in the outer transaction pool to obtain transaction data corresponding to the transaction request. The transaction data is a complete transaction formed by attaching the contract execution result to the transaction request. The transaction data is written into the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store transaction data carrying the transaction request. When a block packaging node triggers a block production operation, it packages the transaction data in the first inner transaction pool into a block to be uploaded to the blockchain and broadcasts the block to be uploaded to the blockchain network. The first inner transaction pool is an inner transaction pool maintained by the block packaging node. The non-block packing node performs consistency verification between the received block to be added to the blockchain and the transaction data stored in the second inner transaction pool. After the verification is successful, the blockchain to be added to the blockchain ledger is connected. The second inner transaction pool is an inner transaction pool maintained by the non-block packing node.

2. The blockchain transaction processing method according to claim 1, characterized in that, Write the transaction requests broadcast on the blockchain network into the outer transaction pool maintained by the blockchain nodes, including: Retrieve transaction requests broadcast on the blockchain network; The transaction request is verified for consistency to determine whether there is data consistent with the transaction request in the data space of the blockchain node. The data space includes at least one of the outer transaction pool, inner transaction pool, or blockchain ledger maintained by the blockchain node. If no data matching the transaction request exists in the data space, the transaction request is written into the outer transaction pool maintained by the blockchain node.

3. The blockchain transaction processing method according to claim 1, characterized in that, Executing smart contracts based on transaction requests stored in the outer transaction pool includes: Obtain the blockchain ledger maintained by the blockchain node; Based on the transaction requests stored in the outer transaction pool and the smart contracts executed by the blockchain ledger, the contract execution results and read / write sets corresponding to the transaction requests are obtained. The read / write set is a data set for reading or writing data to the blockchain ledger. The contract execution result, the read / write set, and the transaction request are correlated to obtain transaction data corresponding to the transaction request.

4. The blockchain transaction processing method according to claim 3, characterized in that, After associating the contract execution result, the read / write set, and the transaction request, the method further includes: Obtain the current block height of the blockchain ledger; The current block height is associated with the transaction request so that the transaction data carries the current block height.

5. The blockchain transaction processing method according to claim 1, characterized in that, Executing smart contracts based on transaction requests stored in the outer transaction pool includes: The transaction requests stored in the outer transaction pool are sent to the endorsing nodes in the blockchain network; Obtain the transaction data corresponding to the transaction request returned by the endorsing node after running the smart contract, and the transaction data carries the endorsement signature of the endorsing node.

6. The blockchain transaction processing method according to claim 1, characterized in that, The transaction data includes a read-write set, which is a collection of data that is read from or written to the blockchain ledger. Package the transaction data in the first inner transaction pool into blocks to be uploaded to the blockchain, including: The transaction data stored in the first inner transaction pool is subjected to read-write set conflict verification to determine whether there is a data conflict between the read-write sets of each transaction data item; Transaction data with data conflicts are marked as conflicting transactions, and other transactions in the first inner transaction pool, excluding the conflicting transactions, are marked as non-conflicting transactions; The conflict-free transactions are packaged into blocks to be uploaded to the blockchain.

7. The blockchain transaction processing method according to claim 1, characterized in that, Connecting the blockchain to be added to the blockchain ledger includes: If the blockchain network completes consensus authentication of the block to be added to the chain, then the blockchain to be added to the chain will be connected to the blockchain ledger.

8. The blockchain transaction processing method according to claim 7, characterized in that, After marking conflicting transaction data as conflicting transactions, the method further includes: The transaction requests for the conflicting transactions are rewritten into the outer transaction pool; Obtain the latest block height transmitted from the first inner transaction pool to the outer transaction pool, where the latest block height is the block height of the block to be added to the chain; If the blockchain ledger is updated to the latest block height, the transaction requests of the conflicting transactions stored in the outer transaction pool are re-executed according to the updated blockchain ledger.

9. The blockchain transaction processing method according to claim 1, characterized in that, Non-block packing nodes perform consistency checks between the received blocks to be added to the blockchain and the transaction data stored in the second inner transaction pool, including: The identification information of the transaction request carried in the block to be uploaded to the chain is sent to the second inner transaction pool; The consistency of the block to be added to the blockchain and the transaction data stored in the second inner transaction pool is verified based on the identification information.

10. The blockchain transaction processing method according to claim 9, characterized in that, Based on the identification information, a consistency check is performed between the block to be uploaded to the blockchain and the transaction data stored in the second inner transaction pool, including: If a transaction request that matches the identification information exists in the second inner transaction pool, then the transaction data corresponding to the transaction request stored in the second inner transaction pool is obtained; The transaction data corresponding to the transaction request stored in the second inner transaction pool is compared with the transaction data carried in the block to be uploaded to the chain to determine whether the content comparison of the transaction data is consistent. If the content of the transaction data does not match or there is no transaction request in the second inner transaction pool that matches the identification information, then the transaction request corresponding to the identification information is sent to the outer transaction pool. The transaction request corresponding to the identification information is executed on the outer transaction pool to obtain updated transaction data, and the updated transaction data is then checked for consistency with the transaction data stored in the block to be uploaded to the blockchain.

11. The blockchain transaction processing method according to claim 1, characterized in that, After connecting the blockchain to be added to the blockchain ledger, the method further includes: Remove the transaction requests corresponding to the block to be added to the blockchain that are stored in the outer transaction pool; Remove the transaction data corresponding to the block to be added to the blockchain that is stored in the inner transaction pool.

12. A blockchain transaction processing device, characterized in that, include: The request writing module is configured to write transaction requests broadcast on the blockchain network into an outer transaction pool maintained by the blockchain node. The outer transaction pool is a cache space used to store transaction requests before execution. The contract execution module is configured to run smart contracts based on transaction requests stored in the outer transaction pool, and obtain transaction data corresponding to the transaction requests. The transaction data is a complete transaction formed by attaching the contract execution results to the transaction requests. The data writing module is configured to write the transaction data into the inner transaction pool maintained by the blockchain node. The inner transaction pool is a cache space used to store transaction data carrying the transaction request. The data upload module is configured so that when a block packaging node triggers a block production operation, it packages the transaction data in the first inner transaction pool into a block to be uploaded to the blockchain and broadcasts the block to be uploaded to the blockchain network. The first inner transaction pool is an inner transaction pool maintained by the block packaging node. Non-block packaging nodes perform consistency verification between the received block to be uploaded to the blockchain and the transaction data stored in the second inner transaction pool. After the verification is passed, the block to be uploaded to the blockchain ledger is connected. The second inner transaction pool is an inner transaction pool maintained by the non-block packaging node.

13. A computer-readable medium, characterized in that, The computer-readable medium stores a computer program that, when executed by a processor, implements the blockchain transaction processing method according to any one of claims 1 to 11.

14. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to cause the electronic device to perform the blockchain transaction processing method according to any one of claims 1 to 11 by executing the executable instructions.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain transaction processing method according to any one of claims 1 to 11.

Images