Block chain transaction processing method and device, medium and electronic equipment

Abstract

The invention belongs to the technical field of block chains, and particularly relates to a block chain transaction processing method, a block chain transaction processing device, a computer readable medium, electronic equipment and a computer program product. The block chain transaction processing method comprises the steps that in response to a block packaging request, a to-be-processed target block chain transaction is taken out from a pre-selected transaction queue, the target block chain transaction is added to a to-be-chained block, and the block chain transactions in the pre-selected transaction queue correspond to different smart contracts; and extracting a candidate block chain transaction corresponding to the same smart contract as the target block chain transaction from a transaction pool, and adding the candidate block chain transaction to the pre-selected transaction queue. The processing efficiency of the block chain transaction can be improved.

Description

Technical Field

[0001] This application belongs to the technical field of blockchain, and particularly relates to a method for processing blockchain transactions, a device for processing blockchain transactions, a computer-readable medium, an electronic device, and a computer program product. Background Art

[0002] In traditional blockchain solutions, blockchain transactions to be processed are uniformly stored in a transaction pool, and each blockchain transaction is executed in the order of entry into the transaction pool. Since a large number of blockchain transactions stored in the transaction pool generally involve multiple different smart contracts, transaction conflicts may occur, resulting in low processing efficiency of blockchain transactions. Summary of the Invention

[0003] This application provides a method for processing blockchain transactions, a device for processing blockchain transactions, a computer-readable medium, an electronic device, and a computer program product, aiming to improve the processing efficiency of blockchain transactions.

[0004] According to one aspect of the embodiments of this application, a method for processing blockchain transactions is provided. The method includes: in response to a block packaging request, taking out a target blockchain transaction to be processed from a preselected transaction queue, and adding the target blockchain transaction to a block to be chained; taking out candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and adding the candidate blockchain transactions to the preselected transaction queue. The blockchain transactions in the preselected transaction queue correspond to different smart contracts.

[0005] According to one aspect of the embodiments of this application, a device for processing blockchain transactions is provided. The device includes: a first transaction transfer module configured to, in response to a block packaging request, take out a target blockchain transaction to be processed from a preselected transaction queue, and add the target blockchain transaction to a block to be chained; a second transaction transfer module configured to take out candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue. The blockchain transactions in the preselected transaction queue correspond to different smart contracts.

[0006] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it implements the method for processing blockchain transactions in the above technical solutions.

[0007] According to one aspect of the embodiments of the present application, an electronic device is provided. The electronic device includes: 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 method for processing blockchain transactions in the above technical solutions.

[0008] According to one aspect of the embodiments of the present application, a computer program product is provided, including a computer program which, when executed by a processor, implements the method for processing blockchain transactions in the above technical solutions.

[0009] In the technical solution provided by the embodiments of the present application, in response to a block packaging request, a target blockchain transaction to be processed is taken out from a preselected transaction queue, and the target blockchain transaction is added to a block to be chained. Each blockchain transaction in the preselected transaction queue corresponds to a different smart contract. Then, candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction are taken out from the transaction pool, and the candidate blockchain transactions are added to the preselected transaction queue. By storing blockchain transactions corresponding to different smart contracts in the preselected transaction queue, blockchain transactions corresponding to different smart contracts can be preferentially processed, avoiding excessive execution of multiple blockchain transactions corresponding to the same smart contract in the same block, and thus the probability of transaction conflicts can be reduced and the processing efficiency of blockchain transactions can be improved. Description of the Drawings

[0010] The drawings here are incorporated into the description and constitute a part of this description, showing embodiments consistent with the present application, and are used together with the description to explain the principles of the present application. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0011] Figure 1 It shows a schematic diagram of the system architecture of a blockchain system implemented by using the technical solution in the embodiments of the present application.

[0012] Figure 2 It shows the composition structure of a blockchain maintained on a blockchain network.

[0013] Figure 3 It shows a block diagram of the composition structure of a blockchain node in an embodiment of the present application.

[0014] Figure 4 It shows a flowchart of the method for processing blockchain transactions in an embodiment of the present application.

[0015] Figure 5 It shows a flowchart of the method for obtaining a transaction score according to the waiting duration and priority weight in an embodiment of the present application.

[0016] Figure 6 Shows a schematic diagram of a scenario for determining the priority weight of a smart contract based on a transaction sliding window in an embodiment of the present application.

[0017] Figure 7 Shows a schematic diagram of a scenario for calculating a transaction score according to the waiting duration and the priority weight in an application scenario of an embodiment of the present application.

[0018] Figure 8 Shows a flowchart of a method for obtaining a transaction score according to the waiting duration, the priority weight, and the transaction conflict coefficient in an embodiment of the present application.

[0019] Figure 9 Shows a schematic diagram of a scenario for calculating a transaction score according to the waiting duration, the priority weight, and the transaction conflict coefficient in an application scenario of an embodiment of the present application.

[0020] Figure 10 Shows a flowchart for obtaining the transaction conflict coefficient of a smart contract in an application scenario of an embodiment of the present application.

[0021] Figure 11 Shows a schematic diagram of the structure of a double-layer transaction queue in a transaction pool in an application scenario of an embodiment of the present application.

[0022] Figure 12 Shows a flowchart for executing transaction transfer in an application scenario of an embodiment of the present application.

[0023] Figure 13 Schematically shows a block diagram of the structure of a processing device for blockchain transactions provided by an embodiment of the present application.

[0024] Figure 14 Schematically shows a block diagram of the computer system structure of an electronic device suitable for implementing an embodiment of the present application. Detailed implementation manners

[0025] Now, example embodiments will be described more fully with reference to the accompanying drawings. However, the example embodiments can be implemented in various forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this application will be more complete and comprehensive, and will fully convey the concept of the example embodiments to those skilled in the art.

[0026] In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of the embodiments of the present application. However, those skilled in the art will realize that the technical solutions of the present application may be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. may be employed. In other cases, well-known methods, devices, implementations, or operations are not shown or described in detail to avoid obscuring aspects of the present application.

[0027] In the embodiments of the present application, the term "module" or "unit" refers to a computer program with a predetermined function or a part of a computer program, which works together with other relevant parts to achieve a predetermined goal, and can be fully or partially implemented by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an overall module or unit that includes the function of that module or unit.

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

[0029] The flowcharts shown in the drawings are only illustrative and do not necessarily include all the contents and operations / steps, nor do they have to be executed in the described order. For example, some operations / steps can be decomposed, while some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0030] In the specific implementation of the present application, it involves relevant data such as the public key, private key, subject identifier used by the user to register and use in the blockchain system, and the transaction information recorded through the blockchain system. When the various embodiments of the present application are applied to specific products or technologies, user permission or consent needs to be obtained, and the collection, use, and processing of the relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0031] The following explains the technical terms in the related technologies of the present application.

[0032] Blockchain is a digital ledger with a block-chain data structure that is shared, anti-counterfeiting, anti-tampering, and traceable, constructed through transparent and trusted rules in a peer-to-peer network environment. The block-chain data structure stores transaction processing that occurs over a period of time in units of blocks, and uses cryptographic algorithms to connect the blocks in chronological order into a chain. The ledger is distributed to all member nodes in the network, and in the sequential chain of blocks linked by hash cryptographic algorithms, it permanently records the historical records of asset transactions that occur between peer nodes in the network. All confirmed and authenticated transactions are linked from the beginning of the chain to the latest block, hence the name blockchain. Blockchain can serve as a single source of truth, and members in the blockchain network can only view transactions relevant to them.

[0033] Blockchains are generally divided into three types: public blockchains, private blockchains, and consortium blockchains. Among them, the public blockchain has 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, etc.; moreover, each node / participant can freely join and exit the public blockchain. In contrast, for private blockchains, the right to record accounts is controlled by a certain organization or institution, and the data reading right is also controlled by that organization or institution. There are few participants and they cannot join the private blockchain at will and need to be reviewed by the organization or institution. Consortium blockchains, also known as community blockchains, refer to blockchains whose consensus process is controlled by preselected nodes. They are a mixture of public blockchains and private blockchains and can achieve "partial decentralization". Each node on the chain usually has a corresponding entity organization or institution; participants join the network through authorization and form an interest-related alliance to jointly maintain the operation of the blockchain. Through the consortium blockchain, new participants can join the existing blockchain and share data without having to build it from scratch. Whether it is a public blockchain, a private blockchain, or a consortium blockchain, they may all provide the function of smart contracts.

[0034] A smart contract is a computer protocol designed to spread, verify, or execute a contract in an information-based manner. It is a program deployed in the nodes of a blockchain network, carrying the business logic for executing transactions and running in an isolated operating environment (such as a container or virtual machine). Each node in the blockchain system automatically executes the smart contract according to specific conditions, can operate on the data stored on the chain, and is an important way for business entities to interact with the blockchain and utilize the blockchain to implement business logic. The purpose of a smart contract is to provide a security method superior to traditional contracts and reduce other transaction costs related to contracts. It allows for trusted transactions without a third party, and these transactions are traceable and irreversible.

[0035] Block Ledger: The block ledger is the core data structure in a blockchain system, used to store and manage all confirmed blocks. The block ledger is organized in a chain structure, where each block contains a set of transactions, a block header (including metadata such as the hash value of the previous block, timestamp, etc.), and other information. The block ledger provides a public and immutable transaction history for the blockchain system, ensuring the transparency and consistency of the system.

[0036] State Data: State data is the data structure used to represent the current state of a blockchain system. State data includes the balances of all accounts, the states of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a certain point in time. In a blockchain system, state data is usually stored in the form of a Merkle tree or other cryptographic data structures to ensure its integrity and security.

[0037] Transaction Pool: The transaction pool (also known as the memory pool or mempool) is a data structure in a blockchain network, used to store unprocessed transactions that have not yet been packed into blocks. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When a blockchain node is preparing to generate a new block, it will select a certain number of transactions from the transaction pool for packing. The transaction pool helps to improve the processing capacity of the blockchain network. At the same time, it can also be used as a strategy to let miners preferentially select transactions with higher transaction fees for packing, thereby increasing the miners' income.

[0038] Sliding Window: The sliding window is a commonly used data processing technique, usually used to process time-series data. The sliding window can be regarded as a subsequence of a fixed size, which slides on a larger data sequence at a certain step length. At each sliding position, various calculations and analyses can be performed on the data within the window, such as calculating the average value, maximum value, minimum value, etc. The sliding window has a wide range of applications in many fields, such as flow control in computer networks, time series analysis, and blockchain transaction processing.

[0039] Priority Queue: The priority queue is a special queue data structure, where the elements are sorted according to a certain priority. The element with the highest priority is at the front of the queue, and the element with the lowest priority is at the end. The priority queue supports insertion operations and the operation of deleting the element with the highest priority. Different from a normal queue (first in, first out), the dequeue order of elements in a priority queue depends not only on the order in which they enter the queue but also on their priorities. The priority queue has a wide range of applications in many fields, such as task scheduling in operating systems, the shortest path problem in graph algorithms, and blockchain transaction processing.

[0040] Figure 1 The figure shows a schematic diagram of the system architecture of a blockchain system implemented by the technical solution in the embodiments of the present application.

[0041] As Figure 1 shown, the blockchain system includes a client 101, a server 102, a smart contract engine 103, and a blockchain network 104.

[0042] The client 101 can be various electronic devices such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart wearable device, a smart vehicle-mounted device, a smart payment terminal, etc., and can provide a user interface for blockchain application management to the user. Specifically, functions such as user registration / cancellation, organization management, fee management, historical query, notification, etc. can be provided. The user interface provided by the client can be a web page, a hosted program running on a host program, an independently installed and running application program, etc.

[0043] The server 102 can be an independent physical server, or a server cluster composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server 102 is used to provide background services for the client 101, and integrally invokes basic smart contracts to complete business functions based on blockchain transactions such as payment, application for account transfer, distributed approval, account transfer, auditing, reporting, etc.

[0044] The smart contract engine 103 provides the ability to orchestrate various smart contracts, and completes function orchestration by being triggered by external authorization or automatically triggered by associating smart contracts. The smart contract engine 103 can provide a smart contract template library related to business applications such as on-chain storage, consensus authentication, and transaction query of blockchain transactions for the blockchain system; multiple participating parties can select smart contract templates to form an integrated application.

[0045] The blockchain network 104 includes multiple blockchain nodes, and the blockchain nodes can be terminal devices or servers participating in blockchain transactions. Each blockchain node can receive input information during normal operation, and maintain shared data within the blockchain network based on the received input information. To ensure information intercommunication, there can be information connections between each blockchain node, and each blockchain node can transmit information through the information connection. For example, when any blockchain node in the blockchain network receives input information and broadcasts the input information in the blockchain network, other node devices in the blockchain network can obtain the input information according to the consensus algorithm and store the input information as shared data.

[0046] For each blockchain node in a blockchain network, there is a corresponding node identifier, and each blockchain node in the blockchain network can store the node identifiers of other nodes in the same blockchain network, so that the generated blocks can be broadcast to other nodes in the blockchain network according to the node identifiers of other blockchain nodes. A node identifier list can be maintained in the blockchain node, and the node name and the node identifier are correspondingly stored in the node identifier list. Among them, the node identifier can be an IP (Internet Protocol) address and any other information that can be used to identify the node.

[0047] Figure 2 shows the composition structure of the blockchain maintained on the blockchain network. As Figure 2 shown, the blockchain consists of multiple sequentially connected blocks. Whenever new data needs to be written into the blockchain, these data will be aggregated into a newly generated block, and the newly generated block will be linked to the end of the blockchain. Through the consensus algorithm, it can be ensured that the newly added blocks on each node device are exactly the same. The data of the current block is recorded in the block body of each block, and at the same time, the hash value of the previous block connected to it is saved in its block header. If the transaction data in the previous block changes, then the hash value of the current block will also change accordingly. Therefore, the data uploaded to the blockchain network is difficult to be tampered with, which can improve the reliability of shared data.

[0048] In the related technology of this application, traditional blockchain solutions usually have the following several defects:

[0049] (1) The transaction management efficiency is relatively low.

[0050] Traditional blockchain solutions are relatively simple in transaction pool management and cannot effectively distinguish transactions of different contracts, which easily leads to transaction conflicts. This processing method may result in a large number of invalid transactions and reduce the processing efficiency of the system.

[0051] (2) Unable to intelligently adjust the transaction execution order.

[0052] When traditional blockchain solutions handle transaction conflicts, they often adopt a fixed processing strategy and cannot flexibly adjust the transaction execution order according to the transaction conflict situation. This may lead to a relatively high transaction conflict rate, resulting in waste of computing power and time.

[0053] (3) Poor adaptability and scalability.

[0054] When traditional blockchain solutions handle transaction conflicts, for different types of contracts and application scenarios, the optimal processing effect may not be achieved. Therefore, traditional solutions have certain limitations in terms of adaptability and scalability.

[0055] In view of the problems existing in the above related technologies, in some embodiments of the present application, a transaction pool scheme with a low transaction conflict rate based on a preselected queue is proposed, and the main features of some alternative schemes are as follows.

[0056] (1) Implementing the transaction pool and the sliding window through a two-layer queue.

[0057] The transaction pool is implemented by introducing a two-layer queue. The first layer consists of multiple queues grouped by contract, and each queue stores all the transactions of that contract (sorted by arrival time); the second layer is the preselected queue, which stores the head transactions of each contract transaction queue. In addition, a sliding window is introduced to maintain the transactions popped from the past preselected queue and the corresponding contracts, and calculate the proportion and weight of each contract. This design can manage the transactions in the transaction pool more effectively, distribute the contract transaction quantities as evenly as possible, reduce the probability of transaction conflicts, and thus improve the overall performance of the blockchain.

[0058] (2) Adjusting the sorting rule of the preselected queue by combining the transaction conflict coefficient and the sliding window.

[0059] In the embodiments of the present application, the transaction conflict coefficient of each contract is statistically calculated, and combined with the weight calculated by the sliding window, and these factors are incorporated into the transaction sorting rule of the preselected queue. Specifically, the scores are calculated according to factors such as the transaction conflict coefficient, the weight coefficient, the weight, and the waiting time, so as to adjust the transaction sorting in the preselected queue. This method can adjust the transaction execution order more intelligently, enable each contract to execute an average number of transactions, reduce the conflict rate, reduce the repeated execution and invalid transactions caused by transaction conflicts, and improve the utilization efficiency of computing power and time.

[0060] Figure 3 The block diagram of the composition structure of a blockchain node in an embodiment of the present application is shown. The blockchain node is a basic component in the entire blockchain system, responsible for functions such as processing transactions, storing blockchain data, and participating in consensus. As Figure 3 shown, the blockchain node consists of the following multiple modules.

[0061] Network module 301: Responsible for communication between nodes, processing functions such as network connection, message transmission, and broadcasting, including receiving and sending information such as transactions and blocks. The network module enables the blockchain nodes to work together in a distributed network.

[0062] Verification module 302: Responsible for verifying transactions to ensure the legality and validity of transactions. The verification module can include two sub-modules: certificate verification and permission verification.

[0063] Certificate verification: Verifying the identity of the transaction initiator to ensure that it has the permission to initiate the transaction, such as a legal certificate and signature.

[0064] Permission verification: Check whether the transaction initiator has the permissions required to execute the transaction, such as access control permissions for smart contracts.

[0065] Transaction pool module 303: Responsible for storing and managing transactions to be processed. It can include multiple sub-modules such as contract transaction queue groups, pre-selection queues, and contract transaction sliding windows.

[0066] Contract transaction queue group: Multiple queues grouped by contract. Each queue stores all transactions of that contract and can be sorted by arrival time.

[0067] Pre-selection transaction queue: Stores the head transactions of each contract transaction queue and can be sorted by time and the number of times a transaction appears within the sliding window.

[0068] Transaction sliding window: Maintains the transactions popped from the pre-selection queue in the past and the corresponding contracts, used to calculate the ratio of contract occurrences and weights.

[0069] Scheduling execution and verification module 304: Responsible for scheduling, executing, and verifying transactions. It can include multiple sub-modules such as block transaction packers, virtual machine engines, block generators, contract repositories, and contract conflict feedback records.

[0070] Block transaction packer: Selects transactions from the pre-selection queue for packaging to generate new blocks.

[0071] Virtual machine engine: Executes the contract code in the transaction and updates the blockchain state.

[0072] Block generator: Generates new blocks based on the packaged transactions.

[0073] Contract repository: Stores the deployed contract code.

[0074] Contract conflict record: Records the conflict situations during the execution of contracts, used to adjust the transaction sorting rules in the pre-selection queue.

[0075] Consensus module 305: Responsible for reaching consensus in the blockchain network to ensure that all nodes synchronize and maintain the same blockchain state, that is, to ensure the consistency and security of the blockchain.

[0076] Storage module 306: Responsible for storing blockchain-related data. It can include multiple sub-modules such as block ledgers and state data.

[0077] Block ledger: Stores the confirmed block data and records the transaction history.

[0078] State data: Stores the current state of the blockchain, such as information about account balances and smart contract states.

[0079] Figure 4The flowchart of the method for processing blockchain transactions in an embodiment of the present application is shown. The method for processing blockchain transactions can be executed by the Figure 3 blockchain node shown. As Figure 4 shown, the method for processing blockchain transactions may include the following steps S410 to S420.

[0080] S410: In response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be chained. Each blockchain transaction in the preselected transaction queue corresponds to a different smart contract.

[0081] S420: Take out the candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue.

[0082] In the method for processing blockchain transactions provided in the embodiment of the present application, in response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be chained. Then, take out the candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue. By storing blockchain transactions corresponding to different smart contracts in the preselected transaction queue, blockchain transactions corresponding to different smart contracts can be preferentially processed, avoiding excessive execution of multiple blockchain transactions corresponding to the same smart contract in the same block, and thus the probability of transaction conflicts can be reduced and the processing efficiency of blockchain transactions can be improved.

[0083] The following makes a detailed description of each method step of the method for processing blockchain transactions in the embodiment of the present application in combination with specific application scenarios.

[0084] In step S410, in response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be chained. Each blockchain transaction in the preselected transaction queue corresponds to a different smart contract.

[0085] In an embodiment of the present application, when the block packaging condition is met, a block packaging request for packaging blockchain transactions into a block can be triggered. The block packaging condition may include at least one of a time condition or a quantity condition; the time condition is that the duration since the previous block was successfully packaged reaches a preset duration threshold, and the quantity condition is that the number of blockchain transactions stored in the transaction pool reaches a preset quantity threshold.

[0086] If the block packaging condition is a time condition, the blockchain node can detect the time difference from the generation time of the nearest block. When the time difference reaches the preset duration threshold, it can be determined that the block packaging condition is met, and then start packaging a new block; taking the time condition as the block packaging condition, blocks can be generated at fixed time intervals.

[0087] If the block packaging condition is a quantity condition, the blockchain node can detect the quantity of blockchain transactions stored in the transaction pool. When the quantity reaches the preset quantity threshold, it can be determined that the block packaging condition is met, and then start packaging a new block; taking the quantity condition as the block generation condition, the generation time of each block is not fixed, but it can be ensured that the data volume of each block linked to the blockchain is basically the same.

[0088] In an embodiment of the present application, the blockchain node can detect both the time condition and the quantity condition at the same time. When any one of the two conditions is met, it can be determined that the block packaging condition is met, and then start packaging a new block. This can improve the efficiency of block packaging while maintaining the stability of block packaging.

[0089] In an embodiment of the present application, the method of taking out the target blockchain transaction to be processed from the preselected transaction queue may further include: obtaining the transaction scores of each blockchain transaction in the preselected transaction queue, where the transaction score is used to represent the execution priority of the blockchain transaction; according to the transaction score, taking out the blockchain transaction with the highest execution priority from the preselected transaction queue as the target blockchain transaction to be processed.

[0090] The preselected transaction queue in the present application is a priority queue, that is, each blockchain transaction in the preselected transaction queue is sorted according to the transaction score for evaluating the execution priority. Among them, the blockchain transaction with the highest transaction score has the highest execution priority and is ranked at the head of the preselected transaction queue; the blockchain transaction with the lowest transaction score has the lowest execution priority and is ranked at the end of the preselected transaction queue.

[0091] In an embodiment of the present application, the number of blockchain transactions in the preselected transaction queue is the same as the number of types of smart contracts of the blockchain transactions stored in the transaction pool. For example, if multiple blockchain transactions stored in the transaction pool respectively correspond to three different smart contracts, then three blockchain transactions waiting to be executed are also stored in the preselected transaction queue, and each blockchain transaction corresponds to one smart contract.

[0092] Figure 5 The flowchart of the method for obtaining the transaction score according to the waiting duration and the priority weight in an embodiment of the present application is shown. As Figure 5As shown, based on the above embodiments, obtaining the transaction scores of each blockchain transaction in the preselected transaction queue may include the following steps S510 to S530.

[0093] S510: Obtain the waiting duration of each blockchain transaction in the preselected transaction queue. The waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment.

[0094] Whenever a new blockchain transaction enters the transaction pool, the waiting duration of the blockchain transaction in the transaction pool can be started to be recorded. Under the condition that other conditions are similar, the greater the waiting duration of the blockchain transaction, the higher the probability that it should be taken out for execution, so as to package it into a block as soon as possible, thereby completing the on-chain storage of the blockchain transaction.

[0095] S520: Obtain the priority weight of the smart contract corresponding to the blockchain transaction. The priority weight is used to represent the execution priority of the smart contract.

[0096] In an embodiment of the present application, the priority weight of the smart contract corresponding to the blockchain transaction is negatively correlated with the execution frequency of the smart contract within a historical time interval. For example, a relatively low priority weight can be assigned to a smart contract with a high execution frequency; while a relatively high priority weight can be assigned to a smart contract with a low execution frequency. By adjusting the priority weight of the smart contract according to the execution frequency, the execution priority of the smart contract can be controlled, so that multiple smart contracts can basically maintain a relatively average execution frequency within a period of time, and the problem of transaction conflicts caused by the frequent execution of the same smart contract can be reduced.

[0097] In an embodiment of the present application, the method for obtaining the priority weight of the smart contract corresponding to the blockchain transaction may further include: obtaining the contract information of multiple historical blockchain transactions taken out before the current moment. The contract information is used to represent the smart contracts corresponding to the respective historical blockchain transactions; counting the proportion of the contract quantity of the smart contract corresponding to the blockchain transaction in the multiple historical blockchain transactions according to the contract information; determining the priority weight of the smart contract corresponding to the blockchain transaction according to the proportion of the contract quantity. The priority weight is negatively correlated with the proportion of the contract quantity.

[0098] Whenever a blockchain transaction is taken out from the preselected transaction queue, the taken-out blockchain transaction can be recorded as a historical blockchain transaction. By counting the contract information of multiple historical blockchain transactions taken out within a period of time before the current moment, the proportion of the number of contracts of the smart contract corresponding to the blockchain transaction among the multiple historical blockchain transactions can be determined, and this proportion of the number of contracts is used to represent the execution frequency of the smart contract. According to the proportion of the number of contracts, the priority weight of the smart contract corresponding to the blockchain transaction can be determined. The higher the proportion of the number of contracts of a smart contract, the lower its priority weight, indicating that the execution frequency of this smart contract was relatively high in the past period of time. To avoid transaction conflicts of the same smart contract, the execution frequency of this smart contract can be reduced by configuring a lower priority weight for this smart contract.

[0099] In an embodiment of the present application, obtaining the contract information of multiple historical blockchain transactions taken out before the current moment may further include: obtaining a transaction sliding window with a specified window size, where the specified window size is used to represent the number of blockchain transactions that the transaction sliding window can cover; moving the transaction sliding window on the historical transaction queue to obtain multiple historical blockchain transactions executed before the current moment, and obtaining the contract information of the historical blockchain transactions; the historical transaction queue is a queue formed by sorting historical blockchain transactions according to the transaction taking-out order of the preselected transaction queue.

[0100] The embodiment of the present application can, by maintaining a historical transaction queue and a transaction sliding window sliding on the historical transaction queue, statistically update in real time the contract information of multiple historical blockchain transactions closest to the current moment, so as to be able to dynamically update the priority weights of each smart contract.

[0101] In an embodiment of the present application, whenever a blockchain transaction is taken out from the preselected transaction queue, the priority weight of the smart contract is updated once. In some other alternative implementation manners, the priority weight of the smart contract can also be updated when a weight update condition is met. The weight update condition can be, for example, taking out a specified number of blockchain transactions, an interval of a specified time period, or an interval of a specified number of blocks, and so on.

[0102] Figure 6 A scenario schematic diagram for determining the priority weight of a smart contract based on a transaction sliding window in an embodiment of the present application is shown.

[0103] The transaction sliding window maintains the blockchain transactions taken out from the preselected transaction queue. By using the transaction sliding window to count the transaction proportion of each smart contract within the window, the weight is then calculated to ensure that the probability of a contract with a relatively high proportion being selected is low.

[0104] Such as Figure 6As shown, the window size of the transaction sliding window is 10, indicating that each slide of the transaction sliding window can cover 10 blockchain transactions.

[0105] At the first moment, 10 historical blockchain transactions are covered in the transaction sliding window, namely transaction 1, transaction 2, transaction 3... transaction 10. According to the contract information of the smart contracts corresponding to each historical blockchain transaction, the proportion of the number of contracts of various smart contracts can be statistically obtained. That is, the proportion of the number of contracts of contract a is 70%, the proportion of the number of contracts of contract b is 20%, and the proportion of the number of contracts of contract c is 10%.

[0106] The priority weight of each smart contract can be determined according to the proportion of the number of contracts. In the embodiment of the present application, the priority weight can be determined according to the difference between the specified value and the proportion of the number of contracts. For example, when the specified value is 1, the priority weight of contract a can be determined as 1 - 70% = 0.3, the priority weight of contract a can be determined as 1 - 20% = 0.8, and the priority weight of contract a can be determined as 1 - 10% = 0.9.

[0107] At the second moment, a new blockchain transaction, namely transaction 11 corresponding to smart contract c, is taken out from the preselected transaction queue. At this time, after the transaction sliding window slides forward, it covers 10 new historical blockchain transactions, namely transaction 2, transaction 3, transaction 4... transaction 11. According to the contract information of the smart contracts corresponding to each historical blockchain transaction, the proportion of the number of contracts of various smart contracts can be statistically updated. That is, the proportion of the number of contracts of contract a is 60%, the proportion of the number of contracts of contract b is 20%, and the proportion of the number of contracts of contract c is 20%.

[0108] The priority weight of each smart contract can be updated according to the proportion of the number of contracts. In the embodiment of the present application, the priority weight can be determined according to the difference between the specified value and the proportion of the number of contracts. For example, when the specified value is 1, the priority weight of contract a can be determined as 1 - 60% = 0.4, the priority weight of contract b can be determined as 1 - 20% = 0.8, and the priority weight of contract c can be determined as 1 - 20% = 0.8.

[0109] S530: Determine the transaction score of the blockchain transaction according to the waiting duration and the priority weight. The transaction score is positively correlated with the waiting duration and the priority weight.

[0110] In an embodiment of the present application, the waiting duration and the priority weight can be weighted and summed according to a preset weight coefficient to obtain the transaction score of each blockchain transaction in the preselected transaction queue.

[0111] Figure 7 Shows a schematic diagram of the scenario for calculating the transaction score according to the waiting duration and the priority weight in an application scenario of the embodiment of the present application.

[0112] As Figure 7 shown, there are three blockchain transactions in the preselected transaction queue at the current moment, namely transaction 1 corresponding to contract a, transaction 2 corresponding to contract c, and transaction 3 corresponding to contract b. Continuing with the Figure 6 priority weights shown as an example, the priority weight of contract a is 0.4, the priority weight of contract b is 0.8, and the priority weight of contract c is 0.8. Combining the Figure 7 waiting durations of each blockchain transaction shown, the transaction score S of the blockchain transaction can be calculated according to the following formula:

[0113] S = t + p·w

[0114] where t represents the waiting duration, p represents the preset weight coefficient, and w represents the priority weight of the smart contract.

[0115] Taking the weight coefficient as 3 as an example, based on this formula, the transaction score of transaction 1 can be calculated as 9.2, the transaction score of transaction 2 can be calculated as 10.4, and the transaction score of transaction 3 can be calculated as 9.4.

[0116] Since transaction 2 corresponding to contract c has the highest transaction score, transaction 2 can be taken out from the preselected transaction queue at the next moment, and a new blockchain transaction corresponding to contract c can be further taken out from the transaction pool and supplemented to the preselected transaction queue.

[0117] Figure 8 shows a flowchart of a method for obtaining a transaction score according to the waiting duration, priority weight, and transaction conflict coefficient in an embodiment of the present application. As Figure 8 shown, on the basis of the above embodiment, obtaining the transaction scores of each blockchain transaction in the preselected transaction queue may include the following steps S810 to S840.

[0118] S810: Obtain the waiting duration of each blockchain transaction in the preselected transaction queue, where the waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment.

[0119] S820: Obtain the priority weight of the smart contract corresponding to the blockchain transaction, where the priority weight is used to represent the execution priority of the smart contract.

[0120] The specific implementation manners of steps S810 to S820 may refer to steps S510 to S520 in the above embodiment, and will not be elaborated here.

[0121] S830: Obtain the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction, where the transaction conflict coefficient is used to represent the probability of transaction conflict between the blockchain transaction executing the smart contract and other transactions.

[0122] In one embodiment of the present application, obtaining the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction may further include: obtaining one or more historical blocks corresponding to the current moment; obtaining the conflict information of each blockchain transaction in the historical block, where the conflict information is used to indicate whether a blockchain transaction has a transaction conflict with other blockchain transactions; and statistically calculating the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the conflict information of the blockchain transaction.

[0123] If two concurrently executed blockchain transactions access the same shared data object and at least one of them performs a write operation, then these two blockchain transactions will conflict. In this case, the latter blockchain transaction must wait for the former blockchain transaction to complete before it can be executed.

[0124] In one embodiment of the present application, statistically calculating the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the conflict information of the blockchain transaction may include: statistically calculating the number of conflict transactions and the total number of transactions of the smart contract corresponding to the blockchain transaction in the historical block according to the conflict information of the blockchain transaction; and determining the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the number of conflict transactions and the total number of transactions.

[0125] For example, the embodiment of the present application may use the ratio of the number of conflict transactions to the total number of transactions as the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction.

[0126] S840: Determine the transaction score of the blockchain transaction according to the waiting duration, priority weight, and transaction conflict coefficient, and the transaction score has a negative correlation with the transaction conflict coefficient.

[0127] Different smart contracts may have different conflict rates. For example, some smart contracts have only 10 transactions, but all of them conflict with each other, while some contracts have 100 transactions but do not conflict with each other. The embodiment of the present application combines the actual conflict rate feedback during execution to adjust the actual sorting rule.

[0128] In one embodiment of the present application, the influence degree of the transaction conflict coefficient on the transaction score is greater than that of the waiting duration and the priority weight. By controlling the influence degree of the transaction conflict coefficient on the transaction score, the embodiment of the present application can reduce the conflict probability of blockchain transactions and improve the processing efficiency of blockchain transactions.

[0129] Figure 9 The figure shows a schematic diagram of the scenario for calculating the transaction score according to the waiting duration, priority weight, and transaction conflict coefficient in an application scenario of the embodiment of the present application.

[0130] Such as Figure 9As shown, there are three blockchain transactions in the preselected transaction queue at the current moment, namely Transaction 1 corresponding to Contract a, Transaction 2 corresponding to Contract c, and Transaction 3 corresponding to Contract b. Continuing with Figure 6 the priority weights shown in

[0131] as an example, the priority weight of Contract a is 0.4, the priority weight of Contract b is 0.8, and the priority weight of Contract a is 0.8. Assume that the transaction conflict coefficient of Contract a is 0.6, the transaction conflict coefficient of Contract b is 0.7, and the transaction conflict coefficient of Contract c is 0.8. Figure 9 Combined with

[0132] the waiting durations of each blockchain transaction shown in

[0133] the transaction score S of the blockchain transaction can be calculated according to the following formula:

[0134] S = (t + p·w)·(1 - q)

[0133] where t represents the waiting duration, p represents the preset weight coefficient, w represents the priority weight of the smart contract, and q represents the transaction conflict coefficient of the smart contract.

[0134] Taking the weight coefficient as 3 as an example, based on this formula, the transaction score of Transaction 1 can be calculated as 3.68, the transaction score of Transaction 2 is 2.08, and the transaction score of Transaction 3 is 2.82.

[0135] Since Transaction 1 corresponding to Contract a has the highest transaction score, Transaction 1 can be taken out from the preselected transaction queue at the next moment, and a new blockchain transaction corresponding to Contract a can be further taken out from the transaction pool and supplemented to the preselected transaction queue.

[0136] Figure 10 shows a flowchart for obtaining the transaction conflict coefficient of a smart contract in an application scenario of an embodiment of the present application.

[0137] As Figure 10 shown, in this application scenario, obtaining the transaction conflict coefficient of the smart contract according to the feedback adjustment process of the transaction conflict situation may include the following steps S1001 to S1007.

[0138] S1001: Schedule the execution of the virtual machine engine of the execution and verification module to sequentially execute the blockchain transactions in the current block.

[0139] S1002: Determine whether there is a transaction conflict in the current blockchain transaction. If so, execute step S1003; otherwise, execute step S1004.

[0140] S1003: Mark the contract conflict count corresponding to this blockchain transaction as incremented by 1.

[0141] S1004: Determine whether all blockchain transactions in the current block have been executed. If so, execute step S1005; if not, return to step S1001.

[0142] S1005: Check the total number of transactions and the number of conflicting transactions of each smart contract in the current block.

[0143] S1006: Calculate the transaction conflict coefficient for each smart contract. Specifically, it can be calculated by multiplying the ratio of the number of conflicting transactions to the total number of transactions by a certain coefficient, or the error can be reduced by taking a moving average of multiple blocks.

[0144] S1007: Regularly or at a specified number of blocks, update the calculation rules for the transaction scores of blockchain transactions in the preselected transaction queue.

[0145] In an embodiment of the present application, when the score update condition is met, update the calculation rules for the transaction scores of each blockchain transaction in the preselected transaction queue. The calculation rules may include, for example, updating the transaction conflict coefficient of the smart contract. The score update conditions in the embodiments of the present application may be, for example, taking out a specified number of blockchain transactions, at an interval of a specified time period, or at an interval of a specified number of blocks, etc.

[0146] In step S420, take out the candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue.

[0147] Whenever a target blockchain transaction is taken out from the preselected transaction queue, a candidate blockchain transaction can be taken out from the transaction pool and added to the preselected transaction queue.

[0148] In an embodiment of the present application, the transaction pool includes multiple contract transaction queues, and each contract transaction queue is used to store blockchain transactions corresponding to the same smart contract; the method of taking out the candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool may include: selecting the contract transaction queue corresponding to the same smart contract as the target blockchain transaction in the transaction pool, and taking out the candidate blockchain transactions from the contract transaction queue.

[0149] In an embodiment of the present application, the method of taking out the candidate blockchain transactions from the contract transaction queue may include: obtaining the waiting duration of each blockchain transaction in the contract transaction queue, where the waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment; taking out the blockchain transaction with the maximum waiting duration from the contract transaction queue as the candidate blockchain transaction.

[0150] Figure 11The figure shows a schematic structural diagram of a double-layer transaction queue in a transaction pool in an application scenario of this application embodiment. The transaction pool includes a double-layer queue. The first layer is a transaction queue grouped by each contract, sorted according to the transaction waiting time. The second layer is a preselection queue, which always obtains the head transactions in the transaction queues of each contract and sorts them according to specified rules.

[0151] As Figure 11 shown, there are three contract transaction queues in the transaction pool, which are respectively used to store each blockchain transaction of contract a, contract b, and contract c. The blockchain transactions in each contract transaction queue are sorted in sequence according to the waiting duration, and the blockchain transaction at the head of each contract transaction queue will be taken out and added to the preselected transaction queue. For example, at the current moment, the preselected transaction queue includes transaction 1 corresponding to contract a, transaction 3 corresponding to contract b, and transaction 2 corresponding to contract c.

[0152] Figure 12 The figure shows a flowchart for executing transaction transfer in an application scenario of this application embodiment. As Figure 12 shown, in this application scenario, the process of blockchain transaction transfer, sorting, and screening in the double-layer queue may include the following steps S1201 to S1220.

[0153] S1201: The user packs the name, method, and parameters of the smart contract to be called.

[0154] S1202: The user signs the above-packed content.

[0155] S1203: The user sends the above-packed content and signature to the blockchain node together.

[0156] S1204: The blockchain node network module receives the above request.

[0157] S1205: The blockchain node authentication module verifies the certificate and signature of the above request and determines whether the verification passes. If so, execute step S1207; otherwise, execute step S1206.

[0158] S1206: Return the result that the signature verification fails.

[0159] S1207: The authentication module verifies the permissions of the above request and determines whether the verification passes. If so, execute step S1209; otherwise, execute step S1208.

[0160] S1208: Return the result that the permission verification fails.

[0161] S1209: The trading pool module receives the above-mentioned transaction and places it into the corresponding contract trading queue according to its contract name.

[0162] S1210: The scheduling execution and verification module prepares to generate a new block, and the block transaction packer sends a request to the trading pool module to obtain transactions.

[0163] S1211: Determine whether there are still transactions in the current preselected transaction queue. If so, execute step S1212; otherwise, execute step S1220.

[0164] S1212: Obtain the transaction at the head of the queue from the preselected transaction queue and send it to the block transaction packer.

[0165] S1213: The contract trading sliding window pops out the oldest transaction.

[0166] S1214: The contract trading sliding window pushes the just-sent transaction into the sliding window.

[0167] S1215: The contract trading sliding window updates the proportion of occurrences and weights of each smart contract.

[0168] S1216: Determine whether the contract trading calculation rules in the preselected queue need to be updated currently. If so, execute step S1217; otherwise, execute step S1218. For example, if a specified number of transactions have been popped out, or a specified time period has passed, then update the trading calculation rules in the preselected transaction queue.

[0169] S1217: Update the contract trading calculation rules in the preselected transaction queue and reorder them.

[0170] S1218: Pop out the transaction at the head of the queue from the contract trading queue corresponding to the just-sent transaction and place it in the preselected transaction queue.

[0171] S1219: Determine whether a sufficient number of transactions have been obtained. If so, execute step S1220; otherwise, return to step S1211.

[0172] S1220: The scheduling execution and verification module starts to execute all transactions in the above-mentioned block and conduct consensus.

[0173] Based on the introduction of the above application scenarios, it can be seen that the embodiments of the present application realize more efficient transaction management and intelligent adjustment of the transaction execution order by introducing a double-layer queue trading pool and a sliding window mechanism, thereby reducing the transaction conflict rate and improving the utilization efficiency of computing power and time. At the same time, the embodiments of the present application have strong adaptability and scalability and can handle different types of contracts and application scenarios. In the fields of finance, the Internet of Things, supply chain management, etc., the embodiments of the present application will help improve the performance and efficiency of the blockchain system and bring a better service experience to users.

[0174] The advantages of the embodiments of the present application are as follows.

[0175] (1) More efficient transaction management.

[0176] By introducing a double-layer queue to implement the transaction pool and sliding window mechanism, the embodiments of the present application can manage the transactions in the transaction pool more effectively. This design helps to distribute the transaction quantities of each contract as evenly as possible, reduce the probability of transaction conflicts, and thus improve the overall performance of the blockchain.

[0177] (2) Intelligent adjustment of transaction execution order.

[0178] The embodiments of the present application intelligently adjust the transaction sorting rules in the preselected queue by combining the weights calculated from the transaction conflict coefficient and the sliding window. This method can enable each contract to execute an average number of transactions, reduce the conflict rate, reduce the repeated execution and invalid transactions caused by transaction conflicts, and improve the utilization efficiency of computing power and time.

[0179] (3) Stronger adaptability and scalability.

[0180] Parameters such as the sliding window, weight coefficient, and transaction conflict coefficient in the embodiments of the present application can be adjusted according to the actual situation, making the solution highly adaptable. In addition, by combining the conflict probabilities of different contracts to execute transactions, the embodiments of the present application have strong scalability and can adapt to different types of contracts and application scenarios.

[0181] The application scenarios of the embodiments of the present application on the product side mainly include the following aspects.

[0182] (1) Financial industry: In various application scenarios in the financial industry, such as cross-border payments, supply chain finance, securities trading, etc., the processing efficiency and accuracy of transactions are crucial. The solution proposed by the embodiments of the present application can effectively reduce transaction conflicts in financial scenarios, improve the transaction processing speed, and thus enhance the quality and efficiency of financial services.

[0183] (2) Internet of Things: With the popularization of Internet of Things devices, a large number of devices need to perform real-time data exchange and processing. The solution proposed by the embodiments of the present application can be applied to data exchange and contract execution between Internet of Things devices, reduce transaction conflicts, and improve the performance of the entire Internet of Things system.

[0184] (3) Supply chain management: In supply chain management, multiple participants need to collaboratively process various transactions in real time, such as orders, shipments, payments, etc. The solution proposed by the embodiments of the present application can improve the transaction processing efficiency in the supply chain management system, reduce transaction conflicts, and thus improve the operating efficiency of the entire supply chain.

[0185] (4) Sharing economy: In the field of sharing economy, such as shared bicycles and shared accommodation, a large number of users need to perform real-time transaction processing. The solution proposed in the embodiments of this application can be applied to transaction processing in the sharing economy field, reduce transaction conflicts, and improve the processing speed and performance of the system.

[0186] (5) Digital identity authentication: In the field of digital identity authentication, multiple participating parties need to perform identity verification and authorization, which involves a large amount of transaction processing. The solution proposed in the embodiments of this application can improve the processing efficiency of transactions in the digital identity authentication system, reduce transaction conflicts, and thus improve the performance of the entire authentication system.

[0187] In summary, the solution proposed in the embodiments of this application has strong applicability and scalability, can be applied to products and services in multiple fields, and improve the performance and efficiency of the blockchain system.

[0188] It should be noted that although the steps of the method in this application are described in a specific order in the drawings, this does not require or imply that these steps must be executed in that specific order, or that all the steps shown must be executed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution, etc.

[0189] The following introduces the device embodiments of this application, which can be used to execute the blockchain transaction processing method in the above embodiments of this application. Figure 13 Schematically shows the structural block diagram of the blockchain transaction processing device provided by the embodiments of this application. As Figure 13 shown, the blockchain transaction processing device 1300 includes:

[0190] A first transaction transfer module 1310, configured to, in response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be chained, and each blockchain transaction in the preselected transaction queue corresponds to a different smart contract;

[0191] A second transaction transfer module 1320, configured to take out the candidate blockchain transaction corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transaction to the preselected transaction queue.

[0192] In an embodiment of this application, based on the above embodiments, the first transaction transfer module 1310 may further include:

[0193] A scoring acquisition module, configured to acquire the transaction scores of each blockchain transaction in the preselected transaction queue, and the transaction score is used to represent the execution priority of the blockchain transaction;

[0194] A transaction withdrawal module, configured to withdraw, according to the transaction score, the blockchain transaction with the highest execution priority from the preselected transaction queue as the target blockchain transaction to be processed.

[0195] In an embodiment of the present application, based on the above embodiments, the score acquisition module may further include:

[0196] A waiting duration acquisition module, configured to acquire the waiting duration of each blockchain transaction in the preselected transaction queue, where the waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment;

[0197] A priority weight acquisition module, configured to acquire the priority weight of the smart contract corresponding to the blockchain transaction, where the priority weight is used to represent the execution priority of the smart contract;

[0198] A transaction score determination module, configured to determine the transaction score of the blockchain transaction according to the waiting duration and the priority weight, and the transaction score has a positive correlation with the waiting duration and the priority weight.

[0199] In an embodiment of the present application, based on the above embodiments, the priority weight acquisition module may further be configured to:

[0200] Acquire the contract information of multiple historical blockchain transactions withdrawn before the current moment, where the contract information is used to represent the smart contracts corresponding to the respective historical blockchain transactions;

[0201] According to the contract information, count the proportion of the number of contracts of the smart contract corresponding to the blockchain transaction in the multiple historical blockchain transactions;

[0202] Determine the priority weight of the smart contract corresponding to the blockchain transaction according to the proportion of the number of contracts, and the priority weight has a negative correlation with the proportion of the number of contracts.

[0203] In an embodiment of the present application, based on the above embodiments, the priority weight acquisition module may further be configured to:

[0204] Acquire a transaction sliding window with a specified window size, where the specified window size is used to represent the number of blockchain transactions that the transaction sliding window can cover;

[0205] Move the transaction sliding window on the historical transaction queue to obtain multiple historical blockchain transactions executed before the current moment, and acquire the contract information of the historical blockchain transactions; the historical transaction queue is a queue formed by sorting historical blockchain transactions according to the transaction withdrawal order of the preselected transaction queue.

[0206] In one embodiment of the present application, based on the above embodiments, the transaction score determination module may be further configured to:

[0207] Obtain a transaction conflict coefficient of the smart contract corresponding to the blockchain transaction, where the transaction conflict coefficient is used to represent the probability of a transaction conflict occurring between the blockchain transaction executing the smart contract and other transactions;

[0208] Determine a transaction score of the blockchain transaction according to the waiting duration, the priority weight, and the transaction conflict coefficient, and the transaction score has a negative correlation with the transaction conflict coefficient.

[0209] In one embodiment of the present application, based on the above embodiments, the transaction score determination module may be further configured to:

[0210] Obtain one or more historical blocks corresponding to the current moment;

[0211] Obtain conflict information of each blockchain transaction in the historical block, where the conflict information is used to represent whether a blockchain transaction has a transaction conflict with other blockchain transactions;

[0212] Statistically determine a transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the conflict information of the blockchain transaction.

[0213] In one embodiment of the present application, based on the above embodiments, the transaction score determination module may be further configured to:

[0214] Statistically determine the number of conflict transactions and the total number of transactions of the smart contract corresponding to the blockchain transaction in the historical block according to the conflict information of the blockchain transaction;

[0215] Determine a transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the number of conflict transactions and the total number of transactions.

[0216] In one embodiment of the present application, based on the above embodiments, the influence degree of the transaction conflict coefficient on the transaction score is greater than that of the waiting duration and the priority weight.

[0217] In one embodiment of the present application, based on the above embodiments, the transaction pool includes a plurality of contract transaction queues, and each of the contract transaction queues is used to store blockchain transactions corresponding to the same smart contract; the second transaction transfer module 1320 is further configured to:

[0218] Select, in the transaction pool, a contract transaction queue corresponding to the same smart contract as the target blockchain transaction, and take out candidate blockchain transactions from the contract transaction queue.

[0219] In one embodiment of the present application, based on the above embodiments, the second transaction transfer module 1320 is further configured to:

[0220] Obtain the waiting duration of each blockchain transaction in the contract transaction queue, where the waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment;

[0221] Take out the blockchain transaction with the maximum waiting duration from the contract transaction queue as the candidate blockchain transaction.

[0222] In one embodiment of the present application, based on the above embodiments, the processing device 1300 for blockchain transactions further includes:

[0223] A rule update module, configured to update the calculation rule of the transaction score of each blockchain transaction in the preselected transaction queue when the score update condition is satisfied.

[0224] The specific details of the processing device for blockchain transactions provided in the embodiments of the present application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0225] Figure 14 Schematically shows a block diagram of a computer system of an electronic device for implementing the embodiments of the present application.

[0226] It should be noted that Figure 14 The computer system 1400 of the shown electronic device is only an example, and should not bring any limitations to the functions and usage scopes of the embodiments of the present application.

[0227] As Figure 14 shown, the computer system 1400 includes a central processing unit 1401 (Central Processing Unit, CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1402 (Read-Only Memory, ROM) or the program loaded from the storage part 1408 into the random access memory 1403 (Random Access Memory, RAM). In the random access memory 1403, various programs and data required for system operation are also stored. The central processing unit 1401, the read-only memory 1402, and the random access memory 1403 are connected to each other through a bus 1404. The input / output interface 1405 (Input / Output interface, that is, I / O interface) is also connected to the bus 1404.

[0228] The following components are connected to the input / output interface 1405: an input section 1406 including a keyboard, a mouse, etc.; an output section 1407 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 1408 including a hard disk, etc.; and a communication section 1409 including a network interface card such as a local area network card, a modem, etc. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the input / output interface 1405 as required. A removable medium 1411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 1410 as required so that a computer program read therefrom is installed into the storage section 1408 as required.

[0229] Specifically, according to an embodiment of the present application, the processes described in each method flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from the network through the communication section 1409, and / or installed from the removable medium 1411. When the computer program is executed by the central processing unit 1401, various functions defined in the system of the present application are executed.

[0230] It should be noted that the computer-readable medium shown in the embodiments of the present 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 of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, apparatus, or device. In the present application, a computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0231] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks can occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram or flowchart, and the combination of blocks in the block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0232] It should be noted that although several modules or units of the device for action execution are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present application, the features and functions of the 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.

[0233] Through the description of the above embodiments, those skilled in the art can easily understand that the example embodiments described herein can be implemented by software or by a combination of software and necessary hardware. Therefore, the technical solutions according to the embodiments of the present 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, a USB flash drive, a mobile hard disk, etc.) or on a network, including several instructions to enable a computing device (such as a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

[0234] After considering the specification and practicing the invention disclosed herein, those skilled in the art will readily conceive of other embodiments of the present application. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include known common knowledge or conventional technical means in the technical field not disclosed in the present application.

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

Claims

1. A method for processing blockchain transactions, characterized in that, Including: In response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be chained. Each blockchain transaction in the preselected transaction queue corresponds to a different smart contract; Take out the candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue.

2. The method for processing blockchain transactions according to claim 1, wherein Taking out the target blockchain transaction to be processed from the preselected transaction queue includes: Obtain the transaction scores of each blockchain transaction in the preselected transaction queue. The transaction scores are used to represent the execution priorities of the blockchain transactions; According to the transaction scores, take out the blockchain transaction with the highest execution priority from the preselected transaction queue as the target blockchain transaction to be processed.

3. The processing method of blockchain transactions according to claim 2, wherein Obtaining the transaction scores of each blockchain transaction in the preselected transaction queue includes: Obtain the waiting duration of each blockchain transaction in the preselected transaction queue. The waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment; Obtain the priority weight of the smart contract corresponding to the blockchain transaction. The priority weight is used to represent the execution priority of the smart contract; Determine the transaction score of the blockchain transaction according to the waiting duration and the priority weight. The transaction score is positively correlated with the waiting duration and the priority weight.

4. The method for processing blockchain transactions according to claim 3, wherein Obtaining the priority weight of the smart contract corresponding to the blockchain transaction includes: Obtain the contract information of multiple historical blockchain transactions taken out before the current moment. The contract information is used to represent the smart contracts corresponding to each of the historical blockchain transactions; According to the contract information, count the proportion of the number of contracts of the smart contract corresponding to the blockchain transaction in the multiple historical blockchain transactions; Determine the priority weight of the smart contract corresponding to the blockchain transaction according to the proportion of the number of contracts. The priority weight is negatively correlated with the proportion of the number of contracts.

5. The processing method of blockchain transactions according to claim 4, wherein, Obtaining the contract information of multiple historical blockchain transactions taken out before the current moment includes: Obtain a transaction sliding window with a specified window size. The specified window size is used to represent the number of blockchain transactions that the transaction sliding window can cover; Move the transaction sliding window on the historical transaction queue to obtain multiple historical blockchain transactions executed before the current moment, and obtain the contract information of the historical blockchain transactions; the historical transaction queue is a queue formed by sorting historical blockchain transactions according to the transaction extraction order of the preselected transaction queue.

6. The method for processing blockchain transactions according to claim 3, wherein, Determining the transaction score of the blockchain transaction according to the waiting duration and the priority weight includes: Obtain the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction. The transaction conflict coefficient is used to represent the probability of transaction conflict between the blockchain transaction executing the smart contract and other transactions; Determine the transaction score of the blockchain transaction according to the waiting duration, the priority weight, and the transaction conflict coefficient. The transaction score is negatively correlated with the transaction conflict coefficient.

7. The processing method of blockchain transactions according to claim 6, characterized in that, Obtaining the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction includes: Obtaining one or more historical blocks corresponding to the current moment; Obtaining the conflict information of each blockchain transaction in the historical block, where the conflict information is used to indicate whether a blockchain transaction has a transaction conflict with other blockchain transactions; Statistically calculating the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the conflict information of the blockchain transaction.

8. The method for processing blockchain transactions according to claim 7, wherein Statistically calculating the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the conflict information of the blockchain transaction includes: Statistically calculating the number of conflict transactions and the total number of transactions of the smart contract corresponding to the blockchain transaction in the historical block according to the conflict information of the blockchain transaction; Determining the transaction conflict coefficient of the smart contract corresponding to the blockchain transaction according to the number of conflict transactions and the total number of transactions.

9. The processing method of blockchain transactions according to claim 6, wherein The influence degree of the transaction conflict coefficient on the transaction score is greater than that of the waiting duration and the priority weight.

10. The method for processing blockchain transactions according to any one of claims 1 to 9, characterized in that, The transaction pool includes multiple contract transaction queues, and each contract transaction queue is used to store blockchain transactions corresponding to the same smart contract; taking out candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool includes: Selecting a contract transaction queue corresponding to the same smart contract as the target blockchain transaction in the transaction pool, and taking out candidate blockchain transactions from the contract transaction queue.

11. The method for processing blockchain transactions according to claim 10, wherein, Taking out candidate blockchain transactions from the contract transaction queue includes: Obtaining the waiting duration of each blockchain transaction in the contract transaction queue, where the waiting duration is the time difference between the moment when the blockchain transaction enters the transaction pool and the current moment; Taking out the blockchain transaction with the maximum waiting duration from the contract transaction queue as the candidate blockchain transaction.

12. The method for processing blockchain transactions according to any one of claims 1 to 9, characterized in that, After adding the candidate blockchain transaction to the preselected transaction queue, the method further includes: When the score update condition is satisfied, updating the calculation rule of the transaction score of each blockchain transaction in the preselected transaction queue.

13. A processing device for blockchain transactions, characterized in that, Including: A first transaction transfer module, configured to, in response to a block packaging request, take out the target blockchain transaction to be processed from the preselected transaction queue, and add the target blockchain transaction to the block to be put on the chain, where each blockchain transaction in the preselected transaction queue corresponds to a different smart contract; A second transaction transfer module, configured to take out candidate blockchain transactions corresponding to the same smart contract as the target blockchain transaction from the transaction pool, and add the candidate blockchain transactions to the preselected transaction queue.

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

15. An electronic device, characterized in that, Including: 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 processing method of the blockchain transaction according to any one of claims 1 to 12.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method for processing blockchain transactions described in any one of claims 1 to 12.

Images