Block chain transaction processing method and device, computer equipment and storage medium

Abstract

The invention relates to a block chain transaction processing method, system and device, computer equipment, a computer readable storage medium and a computer program product, which can be applied to various scenes such as cloud technology, artificial intelligence, intelligent traffic, auxiliary driving and the like. The method comprises the following steps: for each block chain transaction in a transaction pool, determining the transaction independence of the block chain transaction based on the contract independence of a smart contract called by the block chain transaction, and determining candidate transactions of which the transaction independence meets an independence condition from the block chain transactions, a target transaction selected from the candidate transactions is added to a temporary block, a block proposal is formed and broadcasted under the condition that the target transaction is executed, transaction information of the target transaction is written into the block chain under the condition that consensus of the block proposal is passed, the transaction independence represents expected execution duration of the block chain transaction, and the transaction independence represents the expected execution duration of the block chain transaction. By adopting the method, the performance of the block chain system can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a blockchain transaction processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Art

[0002] Blockchain is a decentralized multi-node network that has been widely used in scenarios such as information sharing, data storage, and multi-party collaboration. Blockchain consists of multiple sequentially arranged blocks, and each block includes multiple sequentially arranged blockchain transactions.

[0003] In traditional technology, blockchain nodes take out some blockchain transactions from the transaction pool and pack them into blocks, set transaction timeout conditions, and then execute each blockchain transaction in the block, and put blockchain transactions whose execution time meets the transaction timeout conditions back into the transaction pool, waiting for the next packaging and consensus. The use of traditional technology can easily cause blockchain transactions with long execution times to remain in the transaction pool for a long time and cannot be processed, which has an adverse impact on the performance of the blockchain system. Summary of the invention

[0004] Based on this, it is necessary to provide a blockchain transaction processing method, device, computer equipment, computer-readable storage medium and computer program product that can improve the performance of the blockchain system in response to the above-mentioned technical problems.

[0005] In a first aspect, the present application provides a blockchain transaction processing method. The method comprises:

[0006] For each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0007] Determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0008] Adding the target transaction selected from the candidate transactions to the temporary block, and forming a block proposal and broadcasting it when the target transaction is executed;

[0009] When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0010] In a second aspect, the present application provides a blockchain transaction processing device. The device comprises:

[0011] A transaction independence determination module is used to determine the transaction independence of each blockchain transaction in the transaction pool based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0012] A candidate transaction determination module, used to determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0013] A block proposal generation module, used to add a target transaction selected from each of the candidate transactions to a temporary block, and to form and broadcast a block proposal when the target transaction is executed;

[0014] The on-chain module is used to write the transaction information of the target transaction into the blockchain when the block proposal consensus is passed.

[0015] In a third aspect, the present application provides a computer device. The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the following steps when executing the computer program:

[0016] For each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0017] Determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0018] Adding the target transaction selected from the candidate transactions to the temporary block, and forming a block proposal and broadcasting it when the target transaction is executed;

[0019] When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0020] In a fourth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0021] For each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0022] Determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0023] Adding the target transaction selected from the candidate transactions to the temporary block, and forming a block proposal and broadcasting it when the target transaction is executed;

[0024] When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0025] In a fifth aspect, the present application provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the following steps are implemented:

[0026] For each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0027] Determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0028] Adding the target transaction selected from the candidate transactions to the temporary block, and forming a block proposal and broadcasting it when the target transaction is executed;

[0029] When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0030] The above-mentioned blockchain transaction processing method, device, computer equipment, computer-readable storage medium and computer program product, for each blockchain transaction in the transaction pool, determine the transaction independence of the blockchain transaction based on the contract independence of the blockchain exchange calling the smart contract, and determine the candidate transactions whose transaction independence meets the independence condition from each blockchain transaction. Since the contract independence is obtained by counting the execution time of the smart contract, and the statistical information of the execution time of the exchange calling the contract can characterize the expected execution time of the transaction to a certain extent, before the transaction is executed, the independence attribute can be given to the blockchain transaction calling the contract, and the candidate transactions that meet the independence condition, that is, the expected execution time is relatively long, can be screened from each blockchain transaction. The target transaction selected from each candidate transaction is added to the temporary block, and the restriction on the target transaction by the transaction timeout condition is removed. When the target transaction is executed, a block proposal is formed and broadcasted. When the consensus of the block proposal is passed, the transaction information of the target transaction is written into the blockchain, thereby ensuring that the blockchain transaction with a longer expected execution time can also smoothly achieve packaging consensus and chain, which is conducive to improving the performance of the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 Schematic diagram of a process of generating a new block in one embodiment;

[0032] Figure 2 This is an application environment diagram of a blockchain transaction processing method in one embodiment;

[0033] Figure 3 A flowchart of a blockchain transaction processing method in one embodiment;

[0034] Figure 4 A schematic diagram of a transaction pool including multiple blockchain transactions in one embodiment;

[0035] Figure 5 Schematic diagram of the corresponding relationship between contracts and contract independence in one embodiment;

[0036] Figure 6 A schematic diagram of the contract independence of the same smart contract at different times in one embodiment;

[0037] Figure 7 Schematic diagram of the BlockHash determination process in one embodiment;

[0038] Figure 8 A flowchart of a blockchain transaction processing method in some other embodiments;

[0039] Fig. 9 A schematic diagram of the dependency relationship and execution order between transactions in the same block in one embodiment;

[0040] Fig.10 A schematic diagram of configuration items in a blockchain transaction processing process in one embodiment;

[0041] Fig.11 A schematic diagram of a three-stage model of a consensus algorithm in an embodiment;

[0042] Fig.12 A schematic diagram of a process in which a master node generates a block proposal in one embodiment;

[0043] Fig.13 A schematic diagram of a process of verifying a block proposal from a node in one embodiment;

[0044] Fig.14 It is a structural block diagram of a blockchain transaction processing device in one embodiment;

[0045] Fig.15 is an internal structure diagram of a computer device in one embodiment;

[0046] Fig.16 FIG. 4 is a diagram showing the internal structure of a computer device in another embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] Before going into detail, some terms involved in this application are explained first.

[0049] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of network transaction information, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. Blockchain can include the underlying blockchain platform, platform product service layer, and application service layer.

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

[0051] The platform product service layer provides the basic capabilities and implementation framework of typical applications. Developers can superimpose business features based on these basic capabilities to complete the blockchain implementation of business logic. The application service layer provides application services based on blockchain solutions for business participants to use.

[0052] The blockchain transaction processing method provided in the embodiment of the present application can be applied to a data sharing system. Among them, the data sharing system refers to a system for sharing data between nodes, and the data sharing system may include multiple nodes, and the multiple nodes may refer to each client in the data sharing system. In the embodiment of the present application, the node may specifically include a master node that forms a block proposal and broadcasts it, and a slave node that reaches a consensus on the block proposal. Each node can receive input information when performing normal work, and maintain the shared data in the data sharing system based on the received input information. In order to ensure the information intercommunication within the data sharing system, there may be an information connection between each node in the data sharing system, and the nodes can transmit information through the above information connection. For example, when any node in the data sharing system receives input information, other nodes in the data sharing system obtain the input information according to the consensus algorithm, and store the input information as data in the shared data, so that the data stored on all nodes in the data sharing system are consistent.

[0053] Each node in the data sharing system stores the same blockchain. The blockchain consists of multiple blocks. Figure 1 , when the node where the blockchain is located receives the input information, it verifies the input information. After the verification is completed, the input information is stored in the memory pool, and the hash tree used to record the input information is updated; then, the information in the memory pool is packaged and processed by the chain processing node, specifically updating the update timestamp to the time when the input information is received, and trying different random numbers, performing characteristic value calculations multiple times. When the calculation is completed, the information can be stored accordingly, and the block header and block body are generated to obtain the current block. Subsequently, the node where the blockchain is located sends the newly generated blocks to other nodes in the data sharing system according to the node identifiers of other nodes in the data sharing system, and other nodes verify the newly generated blocks, and add the newly generated blocks to the blockchain stored in them after the verification is completed.

[0054] The blockchain transaction processing method provided in this application can be applied to Figure 2 The application environment shown in the figure. The application environment contains multiple nodes, each of which can communicate with each other over the network and realize the consensus, data recording and chain functions in blockchain technology based on smart contracts. Among them, each node can be used as a master node that forms a block proposal and broadcasts (that is, the data source node that initiates data update), and a slave node that reaches consensus on the block proposal (that is, the node that responds to the master node to update data). It can be understood that Figure 2 As shown, for a consensus, it usually includes a master node 201 and multiple slave nodes 202. In the process of processing blockchain transactions, the master node 201: for each blockchain transaction in the transaction pool, based on the contract independence of the blockchain exchange calling the smart contract, the transaction independence of the blockchain transaction is determined, and from each blockchain transaction; then, the candidate transaction whose transaction independence meets the independence condition is determined, and the target transaction selected from each candidate transaction is added to the temporary block, and when the target transaction is executed, a block proposal is formed and broadcasted; when the broadcast block proposal is passed by the consensus of the slave node 202, the transaction information of the target transaction is written into the blockchain. Among them, the contract independence is obtained by counting the execution time of the smart contract, and the transaction independence is positively correlated with the expected execution time of the blockchain transaction.

[0055] Further, both the master node 201 and the slave node 202 can be implemented through a terminal or a server. Among them, the terminal includes but is not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc., and the server can be an independent physical server, or a server cluster or distributed system 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 embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

[0056] In one embodiment, Figure 3 As shown, a blockchain transaction processing method is provided. This embodiment applies the method to Figure 2 Taking the master node 201 in the example as an example, the following steps are included:

[0057] Step S302: for each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange.

[0058] Among them, the transaction pool is a data storage pool in the blockchain, which is used to store sent and received transaction messages. Generally speaking, each node of the blockchain stores its own transaction pool. The transaction pool stores multiple pending blockchain transactions. For a blockchain transaction in the transaction pool, the blockchain transaction will be deleted from the transaction pool only after the block proposal corresponding to the blockchain transaction completes the consensus accounting. In practical applications, the nodes in the blockchain can select transaction data from the local transaction pool to package into blocks, and then broadcast the block to other nodes for consensus operations, or perform consensus operations on block proposals broadcast by other nodes. In other words, for node A, the blockchain transactions in the local transaction pool of node A can include blockchain transactions initiated locally by node A, as well as transactions broadcast by other nodes of the blockchain to which node A belongs.

[0059] Smart contracts are program codes deployed on the blockchain, corresponding to a piece of logic running on the blockchain node virtual machine. This piece of logic has corresponding input, execution process and output. In practical applications, blockchain nodes can implement the required business by initiating blockchain transactions that call smart contracts. In other words, the processing process of smart contracts can completely replace the business behavior of users, and its execution process occupies a large part of the entire business processing process. Therefore, the performance of the smart contract execution process also largely determines the performance of the entire blockchain system.

[0060] In this application, the attribute of independence is given to smart contracts and blockchain transactions respectively. Among them, the independence of smart contracts or blockchain transactions is used to describe the degree to which the smart contract or blockchain transaction should be processed independently. The higher the independence, the more it should be processed independently. It can be understood that the more complex the logic of the smart contract is, the higher the corresponding contract independence. The logic of the smart contract directly determines the execution time of the smart contract. Therefore, the contract independence of the smart contract can be obtained by counting the execution time of the smart contract. Exemplarily, the pre-execution time of the smart contract can be counted in the contract development stage to determine the contract independence of the smart contract; after the smart contract is deployed, the execution time of the historical transactions that call the smart contract can be counted to determine the contract independence of the smart contract. Further, the transaction independence of the blockchain transaction is used to characterize the degree to which the blockchain transaction should be independently packaged. Independent packaging means that only the blockchain transaction is packaged in a packaging process without adding other transactions. The transaction independence of a blockchain transaction is positively correlated with the expected execution time of the blockchain transaction. That is, the higher the transaction independence, the longer the expected execution time of the blockchain transaction, and the more necessary it is to be independently packaged.

[0061] In actual applications, each blockchain transaction usually calls a smart contract, and the execution time of smart contracts is relatively fixed due to fixed logic. Therefore, the statistical information of the execution time of the blockchain exchange calling the contract can, to a certain extent, characterize the expected execution time of the transaction, that is, it is not necessary to pre-execute the blockchain transaction, but to determine the transaction independence of the blockchain transaction based on the contract independence of the blockchain exchange calling the smart contract, so that the blockchain transaction can be given the attribute of independence before it is executed.

[0062] Specifically, the master node can determine the smart contract called by each blockchain transaction in the transaction pool. Then, based on the contract independence of the smart contract, the transaction independence of the blockchain transaction is determined. Exemplarily, the master node can determine the contract independence of the smart contract called by the blockchain transaction as the transaction independence of the blockchain transaction.

[0063] In a specific embodiment, the master node can superimpose the load impact factor of the blockchain system on the contract independence of the smart contract called by the blockchain exchange to obtain the transaction independence of the blockchain transaction.

[0064] The load impact factor is used to characterize the degree of influence of the blockchain system load on the transaction independence. The load impact factor can be determined based on the difference between the current load and the reference load. The reference load can be a reference load configured based on the hardware conditions of the blockchain system, or it can be a historical load when the smart contract is executed. In the case where the smart contract has been executed multiple times, the historical load can be obtained by statistically calculating the load at each execution time. The specific algorithm of the statistical calculation can include at least one of addition, subtraction, multiplication or division.

[0065] Specifically, the greater the load of the blockchain system, the slower the data processing speed and the longer the data processing time. Based on this, the master node can determine the load impact factor of the blockchain system according to the difference between the current load and the reference load. The difference can be represented by a difference or a ratio, for example. Then, on the basis of the contract independence of the blockchain exchange calling the smart contract, the load impact factor of the blockchain system is superimposed to determine the transaction independence of the blockchain transaction. It can be understood that if the current load is greater than the reference load, the load impact factor is positive, and the transaction independence is greater than the contract independence; if the current load is less than the reference load, the load impact factor is negative, and the transaction independence is less than the contract independence. On the basis of the contract independence of the blockchain exchange calling the smart contract, considering the load impact of the current blockchain system, determining the transaction independence of the blockchain transaction can improve the accuracy of the transaction independence.

[0066] Step S304: Determine, from each blockchain transaction, candidate transactions whose transaction independence satisfies the independence condition.

[0067] The independence condition may refer to the transaction independence being greater than the independence threshold, or may refer to the transaction independence being greater than or equal to the independence threshold. In a specific implementation, the independence threshold may be configured by the parameter ContractThreshold. It can be understood that since the transaction independence is positively correlated with the expected execution time of the transaction, the candidate transaction is the transaction with a relatively long expected execution time among all blockchain transactions. Figure 4 As shown, the transaction pool may include candidate transactions whose independence meets the independence condition (ie, independent transactions), and may also include ordinary transactions whose independence does not meet the independence condition.

[0068] Specifically, the master node can match the independence condition with the transaction independence of each blockchain transaction, and determine the candidate transactions whose transaction independence meets the independence condition from each blockchain transaction. Furthermore, the independence threshold can be a relatively fixed static threshold, or a dynamic threshold that changes dynamically according to the transaction independence of each blockchain transaction in the current transaction pool. In a specific embodiment, the master node can determine the statistical value of the independence of each transaction as the independence threshold. The statistical value can be, for example, a quartile, a percentile, and the like. Taking the case where the quartile is the third quartile as an example, it is equivalent to the independence threshold being equal to the transaction independence ranked in the 75th percentile after the independence of each transaction is arranged from small to large. In the case of dynamic changes in the independence condition, candidate transactions with relatively long expected execution times can always be determined in different scenarios. By distinguishing these candidate transactions, the normal operation of the blockchain system can be ensured and the performance of the blockchain system can be improved.

[0069] Step S306: Add the target transaction selected from the candidate transactions to the temporary block, and when the target transaction is executed, form a block proposal and broadcast it.

[0070] Each block includes a block header and a block body, and the block body contains all the blockchain transactions included in this block. In blockchain technology, for blockchain transactions that need to be put on the chain, they need to rely on blocks to achieve the chain. Specifically, the master node packages the blockchain transactions into temporary blocks, and then forms a block proposal corresponding to the temporary block and broadcasts it in the blockchain system, so that other nodes on the blockchain can obtain the proposal message, and verify and reach consensus on the proposal message. The temporary block refers to a block that is not linked to the blockchain, that is, a block that has not yet completed consensus.

[0071] Specifically, the master node can select a target transaction from each candidate transaction and add the target transaction to a temporary block. Then, the transactions contained in the temporary block are executed, and when the target transaction is executed, a block proposal is formed and broadcast in the blockchain system so that other nodes in the blockchain can vote by consensus. Among them, the target transaction is executed, which means that the target transaction is executed and the transaction result of the target transaction is obtained. The specific strategy for selecting the target transaction from each candidate transaction is not unique. For example, the master node can randomly select the target transaction from each candidate transaction, or determine the priority of each candidate transaction, and select the target transaction from each candidate transaction in order of priority from large to small.

[0072] It should be noted that the temporary block may include only the target transaction, or only the common transactions whose independence does not meet the independence condition, or may include both the target transaction and the common transactions.

[0073] Take the case where only target transactions or ordinary transactions are included in the temporary block as an example. In this case, the master node can configure the maximum number of transactions (MaxFetchCount) of target transactions and ordinary transactions in the temporary block, and select the target transaction from each candidate transaction according to the corresponding maximum number of transactions. It can be understood that for candidate transactions, due to their relatively long expected execution time, a smaller maximum number of transactions can be set relative to ordinary transactions. For example, there are 10 candidate transactions whose independence meets the independence condition and 10 ordinary transactions in the transaction pool. The maximum number of transactions corresponding to candidate transactions in the temporary block is 5, and the maximum number of transactions corresponding to ordinary transactions is 8. The master node can select 5 from the 10 candidate transactions as target transactions and add them to the temporary block, or select 8 from the 10 ordinary transactions to add to the temporary block.

[0074] It can be understood that when the temporary block includes both target transactions and ordinary transactions, for ordinary transactions with relatively short execution time, the execution control can be carried out according to the traditional timeout conditions. For target transactions with relatively long execution time, the timeout condition restriction is cancelled. When the target transaction is executed, a block proposal for the temporary block is formed and broadcast.

[0075] It should be noted that in actual applications, there may be situations where the target transaction is not successfully executed, and the main reason for these situations is that there are problems with the code logic of the transaction itself, rather than the timeout limit. For example, there is a call logic error in the target transaction, or there is an infinite loop code in the target transaction, etc. If the above problems exist, neither the candidate transaction whose independence meets the independence condition nor the ordinary transaction whose independence does not meet the independence condition can be executed normally and cannot be put on the chain. In this case, the problematic transaction will be put back into the transaction pool to form a block proposal containing other transactions without logical problems. For ease of understanding, the situation where the target transaction has code logic problems is not considered in this embodiment, so that the master node forms a block proposal and broadcasts it when the target transaction is executed.

[0076] Furthermore, the master node can also configure the timing of adding candidate transactions to the temporary block, i.e., the fetch policy. The fetch policy can be, for example, to fetch candidate transactions as soon as they are available, i.e., to give priority to transactions with longer expected execution times; or to fetch transactions once every X consensuses to ensure that blockchain transactions with relatively longer and shorter expected execution times have the opportunity to be recognized by consensus.

[0077] In one embodiment, the blockchain transaction processing method further includes: determining the number of consecutive consensuses for a set type of block proposal; when the number of consecutive consensuses meets a number condition, selecting a target transaction from each candidate transaction, and clearing the number of consecutive consensuses to zero.

[0078] Among them, the set type block proposal does not include candidate transactions whose independence meets the independence condition. That is, the set type block proposal only includes ordinary transactions whose independence does not meet the independence condition. Specifically, the master node can determine the proposal type of the block proposal based on the transaction type included in the block proposal passed by consensus, and perform consensus counting on the set type block proposal to determine the number of consecutive consensuses of the set type block proposal. When the number of consecutive consensuses meets the number condition, the target transaction is selected from each candidate transaction and added to the temporary block, and the number of consecutive consensuses is cleared to perform the next round of consensus counting. The number condition can mean that the number is greater than the set number, or it can mean that the number is greater than or equal to the set number.

[0079] In this embodiment, when the number of consecutive consensuses for the set type block proposal that does not include candidate transactions meets the number condition, the target transaction is selected from the candidate transactions, which is equivalent to processing a candidate transaction with a relatively long expected execution time every certain number of consensuses. This can ensure that blockchain transactions with relatively long and relatively short expected execution times have the opportunity to be consensused, which is conducive to further improving the performance of the blockchain system.

[0080] Step S308: When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0081] Among them, the blockchain system is a distributed system, and the consensus mechanism is the basis for ensuring the normal operation of the blockchain system. The so-called consensus means reaching an agreement. Each node in the blockchain system stores a distributed ledger (i.e., blockchain). The consensus process of the blockchain system is the process of keeping the distributed ledgers between each node device consistent. The consensus process of the blockchain system is usually implemented based on a consensus algorithm, which may include but is not limited to: BFT (Byzantine Fault Tolerance) algorithm, PBFT (Practical Byzantine Fault Tolerance) algorithm, etc. The transaction information of the target transaction may include transaction parameters, transaction results, transaction status and other transaction-related data information.

[0082] Specifically, each slave node in the blockchain system can verify the broadcasted block proposal and vote according to the verification results. The block proposal consensus is passed, which means that all slave nodes in the blockchain system vote in favor and complete the consensus process for the block proposal. When the block proposal consensus is passed, the master node links the temporary block on the blockchain, thereby completing the transaction on the temporary block and writing the transaction information of the target transaction into the blockchain.

[0083] The above-mentioned blockchain transaction processing method determines the transaction independence of each blockchain transaction in the transaction pool based on the contract independence of the blockchain exchange calling the smart contract, and determines the candidate transactions whose transaction independence meets the independence condition from each blockchain transaction. Since the contract independence is obtained by counting the execution time of the smart contract, and the statistical information of the execution time of the exchange calling the contract can characterize the expected execution time of the transaction to a certain extent, the independence attribute can be given to the blockchain transaction calling the contract before the transaction is executed, and the candidate transactions that meet the independence condition, that is, the expected execution time is relatively long, can be screened from each blockchain transaction. The target transaction selected from each candidate transaction is added to the temporary block, and the restriction of the transaction timeout condition on the target transaction is removed. When the target transaction is executed, a block proposal is formed and broadcasted. When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain, thereby ensuring that the blockchain transaction with a longer expected execution time can also smoothly achieve packaging consensus and chain, which is conducive to improving the performance of the blockchain system.

[0084] In one embodiment, the process of selecting a target transaction from candidate transactions includes: determining the priority of each candidate transaction; and selecting a target transaction from the candidate transactions in descending order of priority.

[0085] Specifically, the master node determines the priority of each candidate transaction and selects the target transaction from the candidate transactions in ascending order of priority. The priority determination algorithm is not unique. Figure 4 As shown, the master node can determine the priority of each candidate transaction according to the first-in-first-out strategy and the time when each candidate transaction is put into the transaction pool, that is, the priority is positively correlated with the transaction waiting time; the priority can also be determined according to the transaction independence, for example, the priority is positively correlated with the transaction independence; the priority can also be determined by combining the transaction independence and timestamp of each candidate transaction. In a specific implementation, the priority strategy can be configured through the parameter BackPolicy.

[0086] In this embodiment, the target transaction is selected based on priority, and the corresponding priority strategy can be configured according to actual business needs, which is conducive to improving the flexibility of the blockchain transaction processing process and improving the performance of the blockchain system.

[0087] In a specific embodiment, determining the priority of each candidate transaction includes: extracting the time information carried by each candidate transaction; standardizing the independence of each transaction and the time information to obtain the independence factor and time factor corresponding to each candidate transaction; for each candidate transaction, combining the independence factor and time factor of the candidate transaction to determine the priority of the candidate transaction.

[0088] Among them, the time information carried by the candidate transaction may include the transaction initiation time, the time when the transaction is placed in the transaction pool, etc. The independence factor is used to characterize the priority of the transaction independence dimension, and the time factor is used to characterize the priority of the time dimension. Standardization processing is to use certain mathematical transformation methods to convert the original data into a specific unified specification, so that the data is kept within a small range, so as to eliminate the differences in the properties, dimensions, order of magnitude and other attribute characteristics between different variables, and thus convert them into dimensionless standardized values, so as to ensure that the values ​​of each indicator are at the same order of magnitude, and facilitate comprehensive analysis and comparison between indicators. The specific algorithm of standardization processing is not unique, for example, it can be the range standardization method or the standard deviation standardization method.

[0089] Specifically, the master node can extract the time information carried by each candidate transaction, and standardize the independence of each transaction and the time information respectively, to obtain the independence factor and time factor corresponding to each candidate transaction. Exemplarily, the master node can determine the time factor of the candidate transaction based on the transaction initiation time of the candidate transaction or the time when the transaction is placed in the transaction pool, or it can determine the time factor of the candidate transaction in combination with various time information. The specific way of combining various time information can be, for example, weighted summation, averaging, etc. After determining the independence factor and time factor corresponding to each candidate transaction, the master node combines each independence factor and each time factor to determine the priority of each candidate transaction. For example, the master node can perform weighted summation or averaging on the independence factor and time factor of the candidate transaction to determine the priority of the candidate transaction. In a specific implementation, in order to avoid long transaction waiting time, a relatively higher weight can be configured for the time factor in the process of determining the priority.

[0090] In this embodiment, the priority of the candidate transaction is determined by combining the independence factor and the time factor, which can take into account the expected execution time and waiting time of the candidate transaction, which is conducive to improving the scientific nature of the blockchain transaction processing process and further improving the performance of the blockchain system.

[0091] In one embodiment, the blockchain transaction processing method further includes: determining the historical associated transactions of the blockchain transaction according to the smart contract called by the blockchain transaction; and performing execution time statistics on the smart contract according to the transaction time of each historical associated transaction to obtain the contract independence of the smart contract.

[0092] Among them, the smart contracts called by the historical associated transactions and the blockchain transactions are the same. Specifically, the master node can determine the historical associated transactions of the blockchain transaction based on the smart contract called by the blockchain transaction. Then, the transaction time of each historical associated transaction is used as the multiple historical execution time of the smart contract, and the execution time of the smart contract is counted to obtain the time statistics result, and finally the contract independence corresponding to the time statistics is determined. The time statistics result can be, for example, an average value or a median. Exemplarily, the master node can establish a mapping relationship between the contract independence and the time statistics result, and determine the contract independence obtained by mapping the average or median transaction time of each historical associated transaction as the contract independence of the smart contract.

[0093] Furthermore, the master node can also save the corresponding relationship between the smart contract and the contract independence for easy query. Figure 5 As shown, the contract independence of the contract "save" is 100, and the contract independence of the contract "transfer" is 50. In one embodiment, the master node can also update the contract independence of the corresponding exchange calling the smart contract according to the execution time of each transaction in the temporary block, which is used as a reference for the next determination of the candidate transaction whose transaction independence meets the independence condition.

[0094] In this embodiment, the execution time of the smart contract is counted based on the transaction time of the historical associated transactions that are the same as the smart contract called by the blockchain transaction, and the contract independence of the smart contract is obtained. This enables the contract independence to reflect the actual execution status of the contract, which is conducive to improving the accuracy of the contract independence.

[0095] It should be noted that there is no unique way to determine historical associated transactions. For example, the master node can determine the historical transaction that is the same as the smart contract called by the blockchain exchange as the historical associated transaction of the blockchain transaction; it can also determine the N most recently executed historical transactions that are the same as the smart contract called by the blockchain exchange as the historical associated transactions of the blockchain transaction; it can also determine the historical transactions that are executed within a set time period and are the same as the smart contract called by the blockchain as the historical associated transactions of the blockchain transaction. The set time period can be, for example, a time period with a time difference within the set time difference range from the current time, or it can be a time period to which the current time belongs. Exemplarily, the time period to which the current time belongs can be "8:00-9:00" or "10:00-12:00", and so on.

[0096] In a specific embodiment, historical associated transactions of a blockchain transaction are determined according to a smart contract called by a blockchain exchange, including: determining, according to the smart contract called by the blockchain exchange, candidate historical transactions that are the same as the smart contract called by the blockchain transaction; and determining, from each candidate historical transaction, historical associated transactions whose transaction time meets a time condition.

[0097] In actual applications, the execution time of the same smart contract will be affected by the hardware configuration and network status of the blockchain system. The hardware configuration is unlikely to change in a short period of time. Based on this, the transaction time meets the time condition, which means that the time difference between the transaction time and the current time is less than the time difference threshold, or the time difference between the transaction time and the current time is less than or equal to the time difference threshold. Furthermore, the network status is usually associated with the time period. Therefore, the transaction time meets the time condition, which means that the transaction time is the same as the time period to which the current time belongs.

[0098] Specifically, the master node can select candidate historical transactions that are the same as the smart contract called by the blockchain transaction from the executed blockchain transactions according to the smart contract called by the blockchain transaction, and obtain the transaction time of each candidate historical transaction. Then, each transaction time is matched with the time condition respectively, and the historical associated transactions whose transaction time meets the time condition are determined from each candidate historical transaction.

[0099] In this embodiment, the determined historical related transactions are the same as the smart contracts called by the blockchain transactions, and the transaction time meets the time conditions, which is equivalent to considering the influence of time when performing statistics on the contract execution time, which is conducive to improving the accuracy of the contract independence obtained based on the transaction time of each historical related transaction.

[0100] In one embodiment, the execution time of the smart contract is counted according to the transaction time of each historical related transaction to obtain the contract independence of the smart contract, including: determining the independence coefficient of each historical related transaction according to the matching result of the transaction time of each historical related transaction and the time threshold; and determining the contract independence of the smart contract by counting the execution time of the smart contract according to each independence coefficient.

[0101] Among them, the independence coefficient is used to characterize the contribution of historical related transactions to the contract independence of smart contracts. The duration threshold can be set according to the timeout conditions of ordinary transactions in the blockchain system. For example, the maximum duration allowed for a single ordinary transaction can be determined as the duration threshold, or the duration deviation can be added to the maximum duration allowed for a single ordinary transaction to obtain the duration threshold.

[0102] Specifically, the master node can match the transaction time of each historical related transaction with the duration threshold, determine the matching results of each transaction time with the duration threshold, and then determine the independence coefficient corresponding to each matching result. Then, according to each independence coefficient, the execution time of the smart contract is counted to determine the contract independence of the smart contract. Exemplarily, the master node can determine the sum of the products of each independence coefficient and the unit independence as the contract independence of the smart contract.

[0103] In a specific embodiment, the master node may set the independence coefficient of the historical associated transactions whose transaction time is greater than the time threshold to 1, and determine the contract independence of the smart contract according to the number of historical associated transactions whose transaction time is greater than the time threshold. Take the case where the time threshold is 10S and the unit independence is 20 as an example. The master node may determine the independence of the historical associated transactions whose transaction time is greater than 10S to be 1, determine the independence coefficient of the historical associated transactions whose transaction time is less than or equal to 10S to be 0, and determine the product of the number of historical associated transactions whose independence coefficient is 1 and the unit independence as the contract independence of the smart contract. For example, if the historical associated transactions include transactions TxA1, TxA2 and TxA3, and the transaction time of TxA1 is 12S, the transaction time of TxA2 is 9S, and the transaction time of TxA3 is 14S, then the independence coefficients of TxA1 and TxA3 are 1, and the independence coefficient of TxA2 is 0. The contract independence of the smart contracts called by these three exchanges is (1+1+0)*20=40.

[0104] In a specific embodiment, the matching result of the transaction time and the duration threshold can be characterized by at least one of a difference or a ratio. For example, the matching result can be the difference between the transaction time and the duration threshold, or the ratio of the difference between the two and the duration threshold. In this case, the master node can determine the independence coefficient of the historical associated transaction whose transaction time is less than or equal to the duration threshold as 0. In the case where the transaction time of the historical associated transaction is greater than the duration threshold, the master node can determine the independence coefficient corresponding to the difference based on the difference between the transaction time and the duration threshold. It can be understood that the more the transaction time exceeds the duration threshold, the greater the degree to which the smart contract needs to be processed independently, and the greater the corresponding independence coefficient. Based on this, the master node can determine the independence coefficient of the associated historical transaction whose transaction time is greater than the duration threshold by establishing a corresponding relationship between the difference between the transaction time exceeding the duration threshold and the independence coefficient.

[0105] Similarly, take the case where the duration threshold is 10S, the unit independence is 20, and the difference between the transaction time exceeding the duration threshold and the independence coefficient is "independence coefficient = difference / 4". If the historical related transactions include transactions TxA1, TxA2, and TxA3, and the transaction time of TxA1 is 12S, the transaction time of TxA2 is 9S, and the transaction time of TxA3 is 14S, the independence coefficient of TxA2 is 0, and the independence coefficients of TxA1 and TxA3 are 0.5 and 1 respectively. The contract independence of the three exchanges calling smart contracts is (0.5+1)*20=30.

[0106] In the above embodiment, statistical analysis is performed based on the matching results of the transaction duration and the duration threshold to determine the contract independence. Different contribution degrees can be configured for historical related transactions with different transaction durations, which is beneficial to improving the accuracy of contract independence.

[0107] In one embodiment, the execution time of the smart contract is counted according to each independence coefficient to determine the contract independence of the smart contract, including: filling each independence coefficient into a bitmap representing the time difference according to the time difference between the transaction time of each historical related transaction and the current time; based on the independence coefficient filled in each position in the bitmap, the execution time of the smart contract is counted to determine the contract independence of the smart contract.

[0108] Among them, the bitmap is also called a dot map or a grid map, which is composed of multiple blocks. In this embodiment, the time difference can be represented by a bitmap, and each direction of the bitmap corresponds to a different time difference parameter. For example, for a one-dimensional bitmap that only includes one layer of blocks in the height direction, the length of the bitmap can represent the time difference between the transaction time and the current time; for a two-dimensional bitmap that includes multiple layers of blocks in the height direction, the correspondence between each direction in the bitmap and the time difference parameter can be: the height of the bitmap represents the date difference between the transaction time and the current time, and the length of the bitmap represents different times on the same day, or the length of the bitmap represents the date difference between the transaction time and the current time, and the height of the bitmap represents different times on the same day. It can be understood that more dimensional bitmaps can also be set to match the needs of actual scenarios. When the number of blocks in the same direction is constant, the more types of time difference parameters there are, the more independence coefficients that can be filled into the bitmap, the more corresponding historical related transactions, the more accurate the determined contract independence, but the greater the amount of calculation, and the lower the processing efficiency. In a specific embodiment, Figure 6 As shown, a one-dimensional bitmap with a length of 5 is used to represent the time difference, so as to take into account both accuracy and processing efficiency.

[0109] Specifically, the master node can fill each independence coefficient into the bitmap according to the time difference between each transaction time of each historical related transaction and the current time, and the correspondence between different positions and the time difference parameter in the bitmap representing the time difference. Then, based on the independence coefficient filled in each position in the bitmap, the execution time of the smart contract is counted to determine the contract independence of the smart contract. Exemplarily, in the case where the bitmap is a multidimensional bitmap, the master node can sum the independence coefficients corresponding to the same time difference parameter in the bitmap to obtain the coefficient sum corresponding to each time difference parameter, and then perform weighted sum statistics on each coefficient sum according to the weight of each time difference parameter, and multiply the statistical result by the unit independence to obtain the contract independence of the smart contract.

[0110] Furthermore, the blockchain node can fill each independence coefficient into the initial bitmap representing the time difference according to the time difference between the transaction time of each historical related transaction and the current time. Figure 6 As shown in the figure, each position of the initial bitmap is empty (the corresponding value is 0). When there is a new historical related transaction, the blockchain node can also fill the independence coefficient of the new historical related transaction into the current bitmap based on the current bitmap corresponding to the current contract independence of the smart contract to obtain an updated bitmap. For example, Figure 6 As shown, Tx(A1)-Tx(A8) are 8 historical related transactions that call smart contract A and are excluded according to transaction time, and the transaction time of Tx(A1) is the earliest, and the transaction time of Tx(A8) is the latest. After Tx(A1) is executed, the corresponding independence coefficient "1" can be filled into the initial bitmap. For each blockchain transaction after Tx(A1), after moving each independence coefficient in the current bitmap to the left by one block, the independence coefficient corresponding to the new transaction can be filled into the first block on the right of the current bitmap to obtain an updated bitmap. It can be understood that when the 5 independence coefficients with the smallest time difference are filled in the bitmap, after Tx(A6) is executed, since the time difference corresponding to Tx(A1) is ranked 6, the independence coefficient of Tx(A1) no longer appears in the bitmap. For example, when the unit independence is 20 and the position weight is not considered, as Figure 6 As shown in the figure, after Tx(A1) is executed, the contract independence of its smart contract A is 20, and after Tx(A2) and Tx(A3) are executed, the contract independence of smart contract A is 40.

[0111] In the above embodiment, the independence coefficient is first filled into the bitmap representing the time difference, and then the execution time of the smart contract is counted based on the independence coefficient filled in each position in the bitmap to determine the contract independence of the smart contract. The algorithm is simple and is conducive to improving efficiency.

[0112] In a specific embodiment, based on the independence coefficient filled in each position in the bitmap, the execution time of the smart contract is counted to determine the contract independence of the smart contract, including: determining the weight of each independence coefficient according to the respective position of each independence coefficient in the bitmap; and performing weighted statistics on each independence coefficient according to the weight corresponding to each independence coefficient to obtain the contract independence of the smart contract.

[0113] Specifically, the master node can configure corresponding weights for different positions in the bitmap, and determine the weights of each independence coefficient according to their respective positions in the bitmap. Then, according to the weights corresponding to each independence coefficient, weighted statistics are performed on each independence coefficient to obtain the contract independence of the smart contract. Figure 6 For example, the weight can be inversely correlated with the time difference, that is, the closer the transaction time is to the current time, the greater the weight. For example, after Tx(A2) is executed, the contract independence of its smart contract A is greater than the contract independence of smart contract A after Tx(A3) is executed.

[0114] In this embodiment, corresponding weights are configured for different positions in the bitmap, which can match the needs in different scenarios and is conducive to improving the accuracy of contract independence.

[0115] In one embodiment, when the target transaction is executed, a block proposal is formed and broadcasted, including: when the target transaction is executed, the transaction information of the target transaction is encoded to obtain the transaction encoding information of the target transaction; according to the respective positions of multiple target transactions in the Merkle tree, the transaction encoding information of each target transaction is re-encoded to determine the root node information of the Merkle tree; based on the root node information, the block information of the temporary block is determined, and a block proposal carrying the block information is generated and broadcasted.

[0116] In practical applications, each block has block information that can uniquely represent it, so that the block can be retrieved more quickly. In a blockchain system of the Byzantine algorithm, the block information can be a block hash value (BlockHash). Specifically, the block hash value can be obtained by encoding the block height (BlockHeight), the hash value of the previous block (PreBlockHash), the transaction hash tree (Merkle tree) root node information (TxRoot) and the root node transaction result information (TxResultRoot). And TxRoot can be obtained by encoding the transaction information of each transaction in the block.

[0117] like Figure 7As shown, in the process of determining the block information, ordinary transactions in the block and candidate transactions that meet the independence conditions (i.e., independent transactions) are processed differently, wherein ordinary transactions (such as Tx1, Tx2, etc.) are used to calculate TxRoot, and independent transactions (such as LongTimeTxID1, LongTimeTxID2, etc.) are used to calculate LongTimeTxRoot. Specifically, the master node can encode the transaction information of the target transaction when the target transaction is executed to obtain the transaction coding information of the target transaction, and according to the respective positions of multiple target transactions in the Merkle tree, the transaction coding information of each target transaction is re-encoded to determine the root node information of the Merkle tree, and finally hash coding is performed in combination with the root node information, block height, etc. to obtain the block information of the temporary block, generate a block proposal carrying the block information and broadcast it.

[0118] In a specific embodiment, in the process of block proposal consensus, the slave node can encode the block consensus information of the block proposal according to the execution status of each transaction in the block proposal at the current node, and determine that the block information verification is passed when the block consensus information matches the block information, and further determine the candidate transactions to be verified in the block proposal whose independence meets the independence condition. Then, the transaction information of the candidate transactions to be verified is encoded to obtain the transaction consensus information of the candidate transactions to be verified, and according to the respective positions of multiple candidate transactions to be verified in the Merkle tree of the current node, the transaction consensus information of each candidate transaction to be verified is secondary encoded to determine the root node consensus information of the Merkle tree of the current node. Finally, the transaction consensus information is matched with the transaction encoding information, and the root node consensus information is matched with the root node information, and when the transaction consensus information matches the transaction encoding information, and the root node consensus information matches the root node information, it is determined that the block proposal consensus is passed. In the process of consensus verification of the block proposal, BlockHash, LongTimeTxID and LongTimeTxRoot are all verified, which can ensure the accuracy of the verification results, thereby improving security. It should be noted that in an environment with a relatively high degree of trust, the slave node can also verify only the block information without verifying the transaction coding information and root node information to improve processing efficiency.

[0119] In the above embodiment, ordinary transactions and independent transactions are processed differently during the process of determining block information, which can facilitate subsequent consensus and help improve security.

[0120] In one embodiment, the process of consensus verification of a block proposal includes: determining candidate transactions to be verified contained in the block proposal; when the transaction independence of the candidate transactions to be verified meets the independence condition, executing each transaction in the block proposal, and calculating the block consensus information of the block proposal according to the execution result; when the block consensus information matches the block information, determining that the block proposal consensus is passed.

[0121] Among them, the candidate transaction to be verified refers to the transaction corresponding to LongtimeTxID, that is, the independent transaction in the block proposal that is different from the ordinary transaction, that is, the target transaction in the block packaging process. In practical applications, the slave nodes that are not packaged in this round of consensus can verify the proposal sent by the master node and vote according to the verification results. Specifically, the slave node can determine the candidate transaction to be verified contained in the block proposal based on the proposal information carried in the block proposal. The slave node can query the contract independence of the contract called by the candidate transaction to be verified from the contract independence data maintained locally, and then determine the transaction independence of the candidate transaction to be verified. When the transaction independence of the candidate transaction to be verified meets the independence condition, each transaction in the block proposal (which may include independent transactions and ordinary transactions) is executed, and the block consensus information of the block proposal is calculated according to the execution result. Finally, when the block consensus information matches the block information, it is determined that the block proposal consensus has passed. It can be understood that if the transaction independence of the candidate transaction to be verified does not meet the independence condition, it means that the independent transaction in the block proposal is incorrect, and the consensus failure can be determined without subsequent verification.

[0122] In the above embodiment, judging whether the independence transaction in the block proposal is correct before performing block information verification is equivalent to verifying the LongtimeTxID, which can simplify the formula verification process of the block proposal and help improve efficiency.

[0123] In a specific embodiment, Figure 8 As shown, the blockchain transaction processing method includes the following steps:

[0124] Step S801, for each blockchain transaction in the transaction pool, according to the smart contract called by the blockchain transaction, determine the candidate historical transaction that is the same as the smart contract called by the blockchain transaction.

[0125] Specifically, the master node can filter out candidate historical transactions that are the same as the smart contract called by the blockchain transaction from the executed blockchain transactions based on the smart contract called by the blockchain transaction.

[0126] Step S802: determine historical related transactions whose transaction time meets the time condition from each candidate historical transaction.

[0127] In actual applications, the execution time of the same smart contract will be affected by the hardware configuration and network status of the blockchain system. However, it is unlikely that the hardware configuration will change in a short period of time. Based on this, the transaction time meets the time condition, which may mean that the time difference between the transaction time and the current time is less than the time difference threshold, or the time difference between the transaction time and the current time is less than or equal to the time difference threshold. Furthermore, the network status is usually associated with the time period. Therefore, the transaction time meets the time condition, which may also mean that the transaction time is the same as the time period to which the current time belongs. Specifically, the master node can obtain the transaction time of each candidate historical transaction. Then, each transaction time is matched with the time condition respectively, and the historical associated transactions whose transaction time meets the time condition are determined from each candidate historical transaction.

[0128] Step S803: determining the independence coefficient of each historical related transaction according to the matching result between the transaction duration of each historical related transaction and the duration threshold.

[0129] Among them, the independence coefficient is used to characterize the contribution of historical related transactions to the contract independence of smart contracts; the duration threshold can be set according to the timeout conditions of ordinary transactions in the blockchain system. For example, the maximum duration allowed for a single ordinary transaction can be determined as the duration threshold, or the duration deviation can be superimposed on the maximum duration allowed for a single ordinary transaction to obtain the duration threshold. Specifically, the master node can match the transaction time of each historical related transaction with the duration threshold, determine the matching results of each transaction time with the duration threshold, and then determine the independence coefficient corresponding to each matching result.

[0130] Step S804: fill each independence coefficient into a bitmap representing the time difference according to the time difference between each transaction time of each historical related transaction and the current time.

[0131] The bitmap is also called a dot map or a grid map, and is composed of multiple blocks. In this embodiment, the time difference can be represented by the bitmap, and each direction of the bitmap corresponds to a different time difference parameter. Specifically, the master node can fill each independence coefficient into the bitmap according to the time difference between the transaction time of each historical related transaction and the current time, and the correspondence between different positions and the time difference parameter in the bitmap representing the time difference.

[0132] Step S805: Determine the weight of each independence coefficient according to the position of each independence coefficient in the bitmap.

[0133] Specifically, the master node may configure corresponding weights for different positions in the bitmap, and determine the weights of the respective independence coefficients according to the respective positions of the independence coefficients in the bitmap.

[0134] Step S806: Perform weighted statistics on each independence coefficient according to the weight corresponding to each independence coefficient to obtain the contract independence of the smart contract.

[0135] Specifically, the master node can perform weighted statistics on each independence coefficient according to the weight corresponding to each independence coefficient to obtain the contract independence of the smart contract. Figure 6 For example, the weight can be inversely correlated with the time difference, that is, the closer the transaction time is to the current time, the greater the weight. For example, after Tx(A2) is executed, the contract independence of its smart contract A is greater than the contract independence of smart contract A after Tx(A3) is executed.

[0136] Step S807, determining the contract independence of the smart contract called by the blockchain exchange as the transaction independence of the blockchain transaction, and determining candidate transactions whose transaction independence meets the independence condition from each blockchain transaction.

[0137] The independence condition may refer to that the transaction independence is greater than the independence threshold, or may refer to that the transaction independence is greater than or equal to the independence threshold. Specifically, the master node may match the independence condition with the transaction independence of each blockchain transaction, and determine the candidate transactions whose transaction independence satisfies the independence condition from each blockchain transaction.

[0138] Step S808, when the number of consecutive consensuses of the set type block proposal meets the number condition, extract the time information carried by each candidate transaction.

[0139] Among them, the set type block proposal does not include candidate transactions whose independence meets the independence condition. That is, the set type block proposal only includes ordinary transactions whose independence does not meet the independence condition. Specifically, the master node can determine the proposal type of the block proposal based on the transaction type included in the block proposal passed by consensus, and count the consensus of the set type block proposal to determine the number of consecutive consensuses of the set type block proposal. When the number of consecutive consensuses meets the number condition, the time information carried by each candidate transaction is extracted. Furthermore, the time information carried by the candidate transaction may include the transaction initiation time, the time when the transaction is placed in the transaction pool, etc.

[0140] Step S809: Standardize the independence of each transaction and the time information to obtain the independence factor and time factor corresponding to each candidate transaction.

[0141] Among them, standardization is to use certain mathematical transformation methods to convert the original data into a specific unified specification, so that the data is kept within a small range, in order to eliminate the differences in the properties, dimensions, magnitudes and other attribute characteristics between different variables, and thus convert them into dimensionless standardized values, ensuring that the values ​​of each indicator are at the same magnitude, which is convenient for comprehensive analysis and comparison between indicators. Specifically, the master node can extract the time information carried by each candidate transaction, and standardize the independence of each transaction and each time information, respectively, to obtain the independence factor and time factor corresponding to each candidate transaction.

[0142] Step S810: For each candidate transaction, the priority of the candidate transaction is determined by combining the independence factor and the time factor of the candidate transaction.

[0143] After determining the independence factor and time factor corresponding to each candidate transaction, the master node combines the independence factors and time factors to determine the priority of each candidate transaction. For example, the master node can perform a weighted sum or average of the independence factor and time factor of the candidate transaction to determine the priority of the candidate transaction. In a specific implementation, in order to avoid a long transaction waiting time, a relatively higher weight can be assigned to the time factor during the priority determination process.

[0144] Step S811, select the target transaction from the candidate transactions in descending order of priority, and clear the number of consecutive consensuses.

[0145] Step S812, adding the target transaction to the temporary block, and when the target transaction is executed, encoding the transaction information of the target transaction to obtain the transaction encoding information of the target transaction.

[0146] Step S813, according to the respective positions of the multiple target transactions in the Merkle tree, the transaction encoding information of each target transaction is re-encoded to determine the root node information of the Merkle tree.

[0147] Step S814, determine the block information of the temporary block based on the root node information, generate a block proposal carrying the block information, and broadcast it.

[0148] Step S815, when the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

[0149] In a specific embodiment, the process of consensus verification of a block proposal may include: determining candidate transactions to be verified contained in the block proposal; when the transaction independence of the candidate transactions to be verified meets the independence condition, executing each transaction in the block proposal, and calculating the block consensus information of the block proposal based on the execution results; when the block consensus information matches the block information, determining that the block proposal consensus has passed.

[0150] In a specific embodiment, the process of consensus verification of a block proposal may include: encoding the block consensus information of the block proposal according to the execution status of each transaction in the block proposal at the current node, and determining that the block information verification is passed when the block consensus information matches the block information, and further determining the candidate transactions to be verified whose independence meets the independence condition in the block proposal. Then, the transaction information of the candidate transactions to be verified is encoded to obtain the transaction consensus information of the candidate transactions to be verified, and according to the respective positions of the multiple candidate transactions to be verified in the Merkle tree of the current node, the transaction consensus information of each candidate transaction to be verified is secondary encoded to determine the root node consensus information of the Merkle tree of the current node. Finally, the transaction consensus information is matched with the transaction encoding information, and the root node consensus information is matched with the root node information, and when the transaction consensus information matches the transaction encoding information, and the root node consensus information matches the root node information, it is determined that the block proposal consensus is passed. In the process of consensus verification of the block proposal, BlockHash, LongTimeTxID and LongTimeTxRoot are all verified, which can ensure the accuracy of the verification results, thereby improving security. It should be noted that in an environment with a relatively high degree of trust, the slave node can also verify only the block information without verifying the transaction coding information and root node information to improve processing efficiency.

[0151] The above-mentioned blockchain transaction processing method can give an independence attribute to the blockchain transaction that calls the contract before the transaction is executed, and screen out candidate transactions that meet the independence condition, that is, the expected execution time is relatively long from each blockchain transaction. The target transaction selected from each candidate transaction is added to the temporary block, and the restriction of the transaction timeout condition on the target transaction is removed. When the target transaction is executed, a block proposal is formed and broadcasted. When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain, thereby ensuring that the blockchain transaction with a longer expected execution time can also smoothly achieve packaging consensus and chain, which is conducive to improving the performance of the blockchain system.

[0152] The following is a detailed introduction to the blockchain transaction processing method with reference to the accompanying drawings.

[0153] For the blockchain system, its main goal is to reach a consensus on the block (including the execution status and results of the transactions in the block, etc.), so it is inevitable that a contract cannot be run indefinitely. In other words, an execution time needs to be set for the execution of the contract, and transactions that exceed this execution time will be stopped. In the actual blockchain system, each round of consensus is a block, and there will be many transactions in the corresponding block. The relationship between these transactions is also relatively complex, which may be conflicting or non-conflicting. In order for the consensus to be executed normally, a timeout is usually set for the execution of all transactions in a block. Transactions that can be completed and accepted within this time range are considered part of the block. Those that are not completed or accepted will be put back into the transaction pool and wait for the next round of consensus to be executed again. Usually, the execution time of a transaction is much shorter than the timeout allowed by the entire block, so that many transactions in the block can be executed normally. However, on the one hand, this will cause some transactions with longer transaction execution times to be unable to be consensused, thereby affecting the performance of the blockchain system. On the other hand, if Fig. 9 As shown in the figure, the transaction execution process in a block is very complicated. There are usually dependencies between different transactions. When there are dependencies between transactions, they need to be executed in a specific order. In this case, although the execution time of some transactions is within the execution time of a single transaction, they may conflict with other transactions and be executed repeatedly, resulting in a long actual execution time and the inability to reach consensus, thus affecting the performance of the blockchain system.

[0154] Based on this, this application proposes a blockchain transaction processing method, which obtains the contract independence of the smart contract by counting the execution time of the blockchain exchange calling the smart contract, and then determines the transaction independence of the blockchain transaction, wherein the transaction independence is positively correlated with the expected execution time of the blockchain transaction, so that the execution time of the blockchain can be estimated before the blockchain transaction is executed. Therefore, for the target transaction with a relatively long expected execution time in the block, the restriction on the transaction execution time is removed, and a block proposal is formed and broadcasted when the target transaction is executed to ensure that the target transaction can be executed normally.

[0155] In actual applications, it is impossible to obtain all independent transactions in the transaction pool at once. It may be necessary to obtain them according to certain rules, and it is also necessary to specify when to obtain independent transactions from the transaction pool. Among them, independent transactions can mean that the execution time of the transaction is greater than the execution time of a single transaction, or the contract independence corresponding to the transaction is greater than the independence threshold.

[0156] In one embodiment, Fig.10As shown in , each configuration item can be configured to limit the blockchain transaction processing rules. The configuration items may include TimeoutSeconds, MaxFetchCount, BackPolicy, FetchPolicy, and ContractThreshold. Among them, TimeoutSeconds is the timeout time of a single independent transaction configuration. This configuration item will be close to the timeout time of the consensus algorithm and much longer than the timeout time of ordinary transactions. It is used to avoid timeouts caused by algorithm logic errors, such as the existence of infinite loop logic. Among them, the timeout time of the consensus algorithm refers to the length of time each node waits at each stage of the consensus process. Taking the Byzantine fault-tolerant algorithm consensus as an example, please refer to Fig.11 The three-stage model of the consensus algorithm can prevent the entire consensus process from being too long by setting the timeout of the consensus algorithm.

[0157] MaxFetchCount is the maximum number of independent transactions to be taken out, that is, the maximum number of target transactions in the temporary block. BackPolicy is the priority strategy for taking independent transactions out of the transaction pool. It can be determined by first-in-first-out order, or by combining the transaction independence and timestamp of each candidate transaction. FetchPolicy represents the strategy for obtaining independent transactions from the transaction pool, indicating when independent transactions need to be obtained from the transaction pool. It can be obtained as soon as there are independent transactions, that is, give priority to transactions with longer expected execution time; or it can be obtained once every X consensuses to ensure that blockchain transactions with relatively long and relatively short expected execution times have the opportunity to be recognized. ContractThreshold represents the independence threshold, which can be configured when independent transactions need to be verified to prevent nodes from doing evil. In the case where the bitmap representing the time difference in the contract independence calculation process is 5 bits and the unit independence is 20, the independence threshold can be a number between 0 and 100.

[0158] In one embodiment, independent transactions and ordinary transactions can be stored separately in the form of transaction sets. That is, each independent transaction is placed in an independent transaction set, and each ordinary transaction is placed in an ordinary transaction set. Compared with ordinary transactions, independent transactions may have a higher priority. From a stricter perspective, we hope that each node in the blockchain handles these independent transactions in the same way. For blockchain, a reasonable way to handle this is to reach a consensus. In a blockchain system based on the Byzantine fault-tolerant algorithm, the master node will package multiple transactions into a block to form a proposal. In order to better reach a consensus on independent transactions, this application adjusts the structure of the block, such as Figure 7As shown in the figure, LongTimeTxID and its corresponding root LongTimeTxRoot are added on the basis of the traditional block structure. During the candidate block verification process, these two parts can reach an agreement through consensus so that the node can make correct operations.

[0159] In one embodiment, the process of the master node fetch transaction is as follows Fig.12 As shown. Specifically, the master node can obtain the configuration parameter FetchPolicy, and determine whether it is necessary to obtain independent transactions based on FetchPolicy. When it is not necessary to obtain independent transactions, the master node obtains ordinary transactions from the transaction pool, executes the obtained transactions according to the transaction scheduling strategy, calculates TxRoot, TxResultRoot and other information, and obtains BlockHash through encoding, generates the corresponding block proposal and broadcasts it. Among them, in the process of executing transactions according to the transaction scheduling strategy, a serial or parallel scheduling model can be adopted, or a more complex model such as a directed acyclic graph can be adopted. Furthermore, the master node can also record timed transactions during the transaction execution process, and update the contract independence of each transaction calling the contract according to the execution time of each transaction. These timed transactions can be regarded as independent transactions discovered during this execution process and put back into the transaction pool to wait for the next consensus.

[0160] When it is determined based on FetchPolicy that an independent transaction needs to be obtained, the master node can determine whether the current transaction pool contains independent transactions. If the current transaction pool does not contain independent transactions, ordinary transactions are taken out of the transaction pool for processing. If the current transaction pool contains independent transactions, the target transaction is selected from each independent transaction according to the configured priority policy BackPolicy. Then, the master node executes the target transaction and aggregates the target transaction ID, calculates information such as LongTimeTxRoot, obtains BlockHash through encoding, generates the corresponding block proposal and broadcasts it. Similarly, in the process of executing the target transaction, a serial or parallel scheduling model can be used, or a more complex model such as a directed acyclic graph can be used.

[0161] It should be noted that in some embodiments, the master node can also take out a part of the independent transactions and a part of the ordinary transactions, package them into the same temporary block to form a block proposal and broadcast them. In this case, it is necessary to distribute and calculate information such as TxRoot, TxResultRoot and LongTimeTxRoot, and perform hash coding on these information to obtain BlockHash, generate the corresponding block proposal and broadcast it.

[0162] In one embodiment, the consensus processing flow of the slave node is as follows: Fig.13As shown, specifically, after the slave node obtains the broadcasted proposal message, it can deserialize the network message and convert the proposal message into an internal data structure that can be processed by the program. Then, the proposal is subjected to basic verification to obtain the verification result. The specific content of the basic verification may include, for example, verifying whether the initiator of the proposal is the master node, verifying the signature information in the proposal, and so on. If the basic verification fails, the proposal message is discarded, the current consensus fails, and the next consensus is awaited. If the basic verification passes, the slave node further obtains the LongTimeTxID set in the proposal, and determines whether the independent transaction LongTimeTxID contained in the LongTimeTxID set is correct according to the locally maintained contract independence. Exemplarily, the slave node can query the contract independence of each exchange call contract in the LongTimeTxID set from the locally maintained contract independence data, and determine that the LongTimeTxID is correct if the contract independence satisfies the independent condition corresponding to the configuration parameter ContractThreshold (for example, greater than the independence threshold), otherwise determine that the LongTimeTxID is wrong. If the LongTimeTxID set includes an incorrect LongTimeTxID, the slave node will vote against it and the consensus will fail. If the LongTimeTxIDs included in the LongTimeTxID set are all correct, the slave node will execute the transaction in the proposal, verify the transaction results, transaction read sets, transaction write sets, and transaction execution process, and calculate BlockHash based on the results if all verifications are passed. If the calculated BlockHash is consistent with the BlockHash carried in the consensus proposal, the slave node will vote in favor and proceed with the subsequent consensus process. If the consensus is passed, the block data will be written into the blockchain ledger.

[0163] The above-mentioned blockchain transaction processing method can give an independence attribute to the blockchain transaction that calls the contract before the transaction is executed, and screen out candidate transactions that meet the independence condition, that is, the expected execution time is relatively long from each blockchain transaction. The target transaction selected from each candidate transaction is added to the temporary block, and the restriction of the transaction timeout condition on the target transaction is removed. When the target transaction is executed, a block proposal is formed and broadcasted. When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain, thereby ensuring that the blockchain transaction with a longer expected execution time can also smoothly achieve packaging consensus and chain, which is conducive to improving the performance of the blockchain system.

[0164] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0165] Based on the same inventive concept, the embodiment of the present application also provides a blockchain transaction processing device for implementing the blockchain transaction processing method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in the one or more blockchain transaction processing device embodiments provided below can refer to the limitations of the blockchain transaction processing method above, and will not be repeated here.

[0166] In some embodiments, Fig.14 As shown, a blockchain transaction processing device is provided, including: a transaction independence determination module 1402, a candidate transaction determination module 1404, a block proposal generation module 1406, and a chaining module 1408, wherein:

[0167] The transaction independence determination module 1402 is used to determine the transaction independence of each blockchain transaction in the transaction pool based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; the transaction independence is positively correlated with the expected execution time of the blockchain transaction;

[0168] A candidate transaction determination module 1404 is used to determine, from various blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition;

[0169] The block proposal generation module 1406 is used to add the target transaction selected from the candidate transactions to the temporary block, and when the target transaction is executed, form a block proposal and broadcast it;

[0170] The on-chain module 1408 is used to write the transaction information of the target transaction into the blockchain when the block proposal consensus is passed.

[0171] In one embodiment, the blockchain transaction processing device further includes: an associated transaction determination module, which is used to determine the historical associated transactions of the blockchain transaction according to the smart contract called by the blockchain transaction; and a contract independence determination module, which is used to perform execution time statistics on the smart contract according to the transaction time of each historical associated transaction, and obtain the contract independence of the smart contract. The smart contracts called by the historical associated transactions and the blockchain transactions are the same.

[0172] In one embodiment, the associated transaction determination module is specifically used to: determine, based on the smart contract called by the blockchain transaction, candidate historical transactions that are the same as the smart contract called by the blockchain transaction; and determine, from each candidate historical transaction, historical associated transactions whose transaction time meets the time condition.

[0173] In one embodiment, the contract independence determination module includes: an independence coefficient determination submodule, which is used to determine the independence coefficient of each historical related transaction according to the matching result of the transaction time of each historical related transaction and the time threshold; and a contract independence determination submodule, which is used to perform execution time statistics on the smart contract according to each independence coefficient to determine the contract independence of the smart contract. The independence coefficient is used to characterize the contribution of the historical related transaction to the contract independence of the smart contract.

[0174] In one embodiment, the contract independence determination submodule includes: a bitmap filling unit, which is used to fill each independence coefficient into the bitmap representing the time difference according to the time difference between the transaction time of each historical related transaction and the current time; a contract independence determination unit, which is used to perform execution time statistics on the smart contract based on the independence coefficient filled in each position in the bitmap, and determine the contract independence of the smart contract.

[0175] In one embodiment, the contract independence determination unit is specifically used to: determine the weight of each independence coefficient according to the respective position of each independence coefficient in the bitmap; perform weighted statistics on each independence coefficient according to the weight corresponding to each independence coefficient to obtain the contract independence of the smart contract.

[0176] In one embodiment, the blockchain transaction processing device further includes: a consensus counting module, which is used to determine the number of consecutive consensuses of a set type of block proposal; and a target transaction selection module, which is used to select a target transaction from each candidate transaction when the number of consecutive consensuses meets the number condition, and reset the number of consecutive consensuses to zero. The set type of block proposal does not include candidate transactions whose independence meets the independence condition.

[0177] In one embodiment, the blockchain transaction processing device also includes: a priority determination module, used to determine the priority of each candidate transaction; a target transaction selection module, used to select a target transaction from each candidate transaction in order of priority from large to small.

[0178] In a specific embodiment, the priority determination module is specifically used to: extract the time information carried by each candidate transaction; standardize the independence of each transaction and the time information respectively to obtain the independence factor and time factor corresponding to each candidate transaction; for each candidate transaction, determine the priority of the candidate transaction in combination with the independence factor and time factor of the candidate transaction.

[0179] In one embodiment, the block proposal generation module 1406 is specifically used to: when the target transaction is executed, encode the transaction information of the target transaction to obtain the transaction encoding information of the target transaction; according to the respective positions of multiple target transactions in the Merkle tree, re-encode the transaction encoding information of each target transaction to determine the root node information of the Merkle tree; determine the block information of the temporary block based on the root node information, generate a block proposal carrying the block information, and broadcast it.

[0180] In one embodiment, the blockchain transaction processing device also includes a consensus verification module, which is used to determine the candidate transactions to be verified contained in the block proposal; when the transaction independence of the candidate transactions to be verified meets the independence condition, execute each transaction in the block proposal, and calculate the block consensus information of the block proposal based on the execution result; when the block consensus information matches the block information, it is determined that the block proposal consensus has passed.

[0181] In one embodiment, the blockchain transaction processing device also includes a consensus verification module, which is used to: encode the block consensus information of the block proposal according to the execution status of each transaction in the block proposal at the current node; when the block consensus information matches the block information, determine the candidate transactions to be verified in the block proposal whose independence meets the independence condition; encode the transaction information of the candidate transactions to be verified to obtain the transaction consensus information of the candidate transactions to be verified, and according to the respective positions of multiple candidate transactions to be verified in the Merkle tree of the current node, re-encode the transaction consensus information of each candidate transaction to be verified to determine the root node consensus information of the Merkle tree of the current node; when the transaction consensus information matches the transaction encoding information, and the root node consensus information matches the root node information, it is determined that the block proposal consensus is passed.

[0182] Each module in the above-mentioned blockchain transaction processing device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0183] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Fig.15 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data involved in the blockchain transaction processing method. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a blockchain transaction processing method is implemented.

[0184] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Fig.16 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface, the display unit and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless method can be implemented through WIFI, a mobile cellular network, NFC (near field communication) or other technologies. When the computer program is executed by the processor, a blockchain transaction processing method is implemented. The display unit of the computer device is used to form a visually visible image, and can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covered on the display screen, or a button, trackball or touchpad set on the computer device casing, or an external keyboard, touchpad or mouse, etc.

[0185] Those skilled in the art will understand that Fig.15 and Fig.16The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0186] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned blockchain transaction processing method when executing the computer program.

[0187] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above-mentioned blockchain transaction processing method are implemented.

[0188] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above-mentioned blockchain transaction processing method when executed by a processor.

[0189] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of the relevant regions and areas.

[0190] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

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

[0192] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A blockchain transaction processing method, characterized in that: The method comprises: For each blockchain transaction in the transaction pool, the transaction independence of the blockchain transaction is determined based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction; Determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition; Adding the target transaction selected from the candidate transactions to the temporary block, and forming a block proposal and broadcasting it when the target transaction is executed; When the block proposal consensus is passed, the transaction information of the target transaction is written into the blockchain.

2. The method according to claim 1, characterized in that The method further comprises: Determine, according to the smart contract called by the blockchain transaction, the historical associated transactions of the blockchain transaction; the historical associated transactions are the same as the smart contracts called by the blockchain transactions respectively; According to the transaction duration of each of the historical related transactions, the execution duration of the smart contract is counted to obtain the contract independence of the smart contract.

3. The method according to claim 2, characterized in that Determining the historical associated transactions of the blockchain transaction according to the smart contract called by the blockchain transaction includes: According to the smart contract called by the blockchain transaction, determine the candidate historical transaction that is the same as the smart contract called by the blockchain transaction; Determine, from each of the candidate historical transactions, a historical associated transaction whose transaction time satisfies the time condition.

4. The method according to claim 2, characterized in that: The execution time of the smart contract is counted according to the transaction time of each of the historical related transactions to obtain the contract independence of the smart contract, including: According to the matching result of the transaction duration of each of the historical related transactions and the duration threshold, the independence coefficient of each of the historical related transactions is determined; the independence coefficient is used to characterize the contribution of the historical related transactions to the contract independence of the smart contract; According to each of the independence coefficients, the execution time of the smart contract is counted to determine the contract independence of the smart contract.

5. The method according to claim 4, characterized in that The step of performing execution time statistics on the smart contract according to each of the independence coefficients to determine the contract independence of the smart contract includes: According to the time difference between the transaction time of each of the historical related transactions and the current time, each of the independence coefficients is filled into the bitmap representing the time difference; Based on the independence coefficient filled in each position in the bitmap, the execution time of the smart contract is counted to determine the contract independence of the smart contract.

6. The method according to claim 5, characterized in that The performing execution time statistics of the smart contract based on the independence coefficient filled in each position in the bitmap to determine the contract independence of the smart contract includes: Determining the weight of each of the independence coefficients according to the respective positions of the independence coefficients in the bitmap; According to the weights corresponding to the respective independence coefficients, weighted statistics are performed on the independence coefficients to obtain the contract independence of the smart contract.

7. The method according to claim 1, characterized in that The method further comprises: Determine the number of consecutive consensuses of a set type of block proposal; the set type of block proposal does not include candidate transactions whose independence meets the independence condition; When the number of consecutive consensuses meets the number condition, a target transaction is selected from each of the candidate transactions, and the number of consecutive consensuses is reset to zero.

8. The method according to claim 1, characterized in that The process of selecting a target transaction from the candidate transactions includes: Determining respective priorities of the candidate transactions; A target transaction is selected from the candidate transactions in descending order of priority.

9. The method according to claim 8, characterized in that The determining the priority of each of the candidate transactions comprises: Extracting time information carried by each of the candidate transactions; Standardizing the independence of each transaction and the time information to obtain the independence factor and time factor corresponding to each candidate transaction; For each of the candidate transactions, the priority of the candidate transaction is determined by combining the independence factor and the time factor of the candidate transaction.

10. The method according to any one of claims 1 to 9, characterized in that When the target transaction is executed, a block proposal is formed and broadcasted, including: When the target transaction is executed, encoding the transaction information of the target transaction to obtain transaction encoding information of the target transaction; According to respective positions of the plurality of target transactions in the Merkle tree, secondary encoding is performed on the transaction encoding information of each of the target transactions to determine the root node information of the Merkle tree; The block information of the temporary block is determined based on the root node information, and a block proposal carrying the block information is generated and broadcasted.

11. The method according to claim 10, characterized in that The process of consensus verification of the block proposal includes: Determine the candidate transactions to be verified included in the block proposal; When the transaction independence of the candidate transaction to be verified meets the independence condition, execute each transaction in the block proposal, and calculate the block consensus information of the block proposal according to the execution result; When the block consensus information matches the block information, it is determined that the block proposal consensus is passed.

12. A blockchain transaction processing device, characterized in that: The device comprises: A transaction independence determination module is used to determine the transaction independence of each blockchain transaction in the transaction pool based on the contract independence of the smart contract called by the blockchain exchange; the contract independence is obtained by counting the execution time of the smart contract; and the transaction independence is positively correlated with the expected execution time of the blockchain transaction; A candidate transaction determination module, used to determine, from each of the blockchain transactions, candidate transactions whose transaction independence satisfies an independence condition; A block proposal generation module, used to add a target transaction selected from each of the candidate transactions to a temporary block, and to form and broadcast a block proposal when the target transaction is executed; The on-chain module is used to write the transaction information of the target transaction into the blockchain when the block proposal consensus is passed.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 11 are implemented.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

Images