Blockchain transaction scheduling method and apparatus, electronic device, and storage medium

Abstract

The embodiment of the application discloses a kind of scheduling method, device, electronic equipment and storage medium of blockchain transaction, the scheduling method of the blockchain transaction is executed by executing multiple blockchain transactions, the first weight of target transaction and the second weight of first reference transaction are determined when the target transaction executed is as target transaction, target transaction and first reference transaction conflict with each other are scheduled, since first weight and second weight are determined based on resource consumption parameter, therefore, according to the size relationship between first weight and second weight, target transaction is scheduled, equivalent to according to resource consumption parameter, target transaction is scheduled, so that when target transaction is scheduled, it can be implemented to retain the blockchain transaction with more resource consumption, and re-execute the blockchain transaction with less resource consumption, avoid causing resource waste, improve the performance of blockchain network, can be widely applied in cloud computing, blockchain and other technical fields.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a method, apparatus, electronic device and storage medium for scheduling blockchain transactions. Background Technology

[0002] Currently, during the execution of blockchain transactions, if conflicting blockchain transactions exist, they are executed sequentially. Therefore, transaction scheduling is necessary, i.e., retaining one blockchain transaction while re-executing the others. Related technologies typically retain blockchain transactions based on a preset transaction order or the order in which they were completed. This approach may lead to the re-execution of resource-intensive transactions, resulting in resource waste and reduced blockchain network performance. Summary of the Invention

[0003] The following is an overview of the subject matter described in detail in this application. This overview is not intended to limit the scope of the claims.

[0004] This application provides a method, apparatus, electronic device, and storage medium for scheduling blockchain transactions, which can avoid resource waste and improve the performance of the blockchain network.

[0005] On one hand, embodiments of this application provide a method for scheduling blockchain transactions, including:

[0006] Obtain multiple blockchain transactions to be executed, and execute each of the blockchain transactions;

[0007] Obtain the completed target transaction from the plurality of blockchain transactions, and determine a first conflict relationship between the target transaction and at least one first reference transaction, wherein the first reference transaction is the blockchain transaction that has been completed other than the target transaction;

[0008] When the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, a first weight of the target transaction and a second weight of the first reference transaction are obtained, wherein the first weight is determined based on the resource consumption parameters of executing the target transaction, and the second weight is determined based on the resource consumption parameters of executing the first reference transaction;

[0009] The target transaction is scheduled according to the relationship between the first weight and the second weight.

[0010] On the other hand, embodiments of this application also provide a blockchain transaction scheduling device, including:

[0011] The execution module is used to acquire multiple blockchain transactions to be executed and execute each of the blockchain transactions;

[0012] The conflict detection module is used to obtain the completed target transaction from multiple blockchain transactions, and determine the first conflict relationship between the target transaction and at least one first reference transaction, wherein the first reference transaction is the blockchain transaction that has been completed other than the target transaction.

[0013] The weight acquisition module is used to acquire a first weight of the target transaction and a second weight of the first reference transaction when the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, wherein the first weight is determined based on the resource consumption parameters of executing the target transaction, and the second weight is determined based on the resource consumption parameters of executing the first reference transaction;

[0014] The first scheduling module is used to schedule the target transaction according to the relationship between the first weight and the second weight.

[0015] Furthermore, the aforementioned first scheduling module is specifically used for:

[0016] The target transaction is scheduled according to the relationship between the first weight and each of the second weights;

[0017] Alternatively, the sum of the first weights of all the second weights can be calculated, and the target transaction can be scheduled according to the relationship between the first weights and the sum of the first weights.

[0018] Furthermore, the target transaction is obtained after all blockchain transactions have been executed, and the first reference transaction is not added to the transaction snapshot. The aforementioned first scheduling module is specifically used for:

[0019] When the first weight is greater than each of the second weights, the target transaction is added to the transaction snapshot;

[0020] Alternatively, if the first weight is less than any of the second weights, the target transaction is re-executed;

[0021] Alternatively, when the first weight is equal to at least one of the second weights and the first weight is greater than the remaining second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0022] Furthermore, the aforementioned first scheduling module is specifically used for:

[0023] The target transaction, and the first reference transaction with the same weight as the target transaction, are used as the first transaction set;

[0024] Add one of the blockchain transactions in the transaction set to the transaction snapshot, and re-execute the remaining blockchain transactions in the transaction set.

[0025] Furthermore, the aforementioned blockchain transaction scheduling device also includes:

[0026] The second scheduling module is used to, whenever all blockchain transactions that were not added to the transaction snapshot are re-executed, designate the re-executed blockchain transactions that were not added to the transaction snapshot as the target transactions; and schedule the target transactions again until all blockchain transactions are added to the transaction snapshot.

[0027] Furthermore, the target transaction is obtained whenever one of the blockchain transactions is completed, and the first reference transaction is not added to the transaction snapshot. The aforementioned first scheduling module is specifically used for:

[0028] When the first weight is greater than the sum of the first weights, wait for a preset time, and then schedule the target transaction after the preset time has elapsed.

[0029] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0030] Alternatively, when the first weight equals the sum of the first weights, wait for a preset time and, after the preset time is reached, schedule or re-execute the target transaction.

[0031] Furthermore, the aforementioned conflict detection module is specifically used for:

[0032] A second conflict relationship is determined between the target transaction and the second reference transaction, wherein the second reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction;

[0033] When the second conflict relationship indicates that there is no conflict between the target transaction and the second reference transaction, a first conflict relationship is determined between the target transaction and at least one first reference transaction.

[0034] Furthermore, the aforementioned first scheduling module is specifically used for:

[0035] After the preset time period is reached, a third conflict relationship is determined between the target transaction and at least one third reference transaction, wherein the third reference transaction is a blockchain transaction that has been executed and has not been added to the transaction snapshot, other than the target transaction.

[0036] When the third conflict relationship indicates that there is a conflict between the target transaction and the third reference transaction, the third weight of the third reference transaction is obtained, wherein the third weight is determined based on the resource consumption parameters of executing the third reference transaction;

[0037] Calculate the sum of the second weights of all the third weights, and schedule the target transaction according to the relationship between the first weight and the sum of the second weights.

[0038] Furthermore, the aforementioned first scheduling module is specifically used for:

[0039] When the first weight is greater than the sum of the second weights, the target transaction is added to the transaction snapshot;

[0040] Alternatively, if the first weight is less than the sum of the second weights, the target transaction is re-executed;

[0041] Alternatively, when the first weight equals the sum of the second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0042] Furthermore, the aforementioned first scheduling module is specifically used for:

[0043] A fourth conflict relationship is determined between the target transaction and the fourth reference transaction, wherein the fourth reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction.

[0044] When the fourth conflict relationship indicates that there is no conflict between the target transaction and the fourth reference transaction, a third conflict relationship is determined between the target transaction and at least one third reference transaction.

[0045] Furthermore, the aforementioned blockchain transaction scheduling device also includes:

[0046] The third scheduling module is used to select the blockchain transaction that was not added to the transaction snapshot as the target transaction whenever the blockchain transaction that was not added to the transaction snapshot is re-executed.

[0047] The target transaction is rescheduled until all the blockchain transactions have been added to the transaction snapshot.

[0048] Furthermore, the target transaction is obtained whenever one of the blockchain transactions is completed, and the first reference transaction has been added to the transaction snapshot. The aforementioned first scheduling module is specifically used for:

[0049] When the first weight is greater than the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction;

[0050] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0051] Alternatively, when the first weight equals the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction or the target transaction is re-executed.

[0052] Furthermore, the aforementioned blockchain transaction scheduling device also includes:

[0053] The fourth scheduling module is used to re-execute the first reference transaction that was replaced in the transaction snapshot; whenever the first reference transaction that was replaced is re-executed, the re-executed first reference transaction is used as the target transaction; the target transaction is scheduled again until all the blockchain transactions are added to the transaction snapshot.

[0054] Furthermore, the resource consumption parameters include at least one of the following: the transaction execution time of the blockchain transaction, the number of read set keys of the blockchain transaction, the read set memory size of the blockchain transaction, the number of write set keys of the blockchain transaction, and the write set memory size of the blockchain transaction. The aforementioned weight acquisition module is specifically used for:

[0055] Determine the score corresponding to at least one of the following for the target transaction: transaction execution time, number of read set keys, size of read set memory, number of write set keys, and size of write set memory;

[0056] The first weight is obtained based on at least one of the stated scores.

[0057] On the other hand, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described blockchain transaction scheduling method.

[0058] On the other hand, embodiments of this application also provide a computer-readable storage medium storing a computer program, which is executed by a processor to implement the above-described blockchain transaction scheduling method.

[0059] On the other hand, embodiments of this application also provide a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned blockchain transaction scheduling method.

[0060] The embodiments of this application include at least the following beneficial effects: by executing multiple blockchain transactions, the completed blockchain transactions are used as target transactions. When scheduling conflicting target transactions and first reference transactions, the first weight of the target transaction and the second weight of the first reference transaction are first obtained. Since the first weight and the second weight are both determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the second weight is equivalent to scheduling the target transaction according to the resource consumption parameters. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption when scheduling target transactions, avoiding resource waste and improving the performance of the blockchain network.

[0061] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. Attached Figure Description

[0062] The accompanying drawings are used to provide a further understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0063] Figure 1 A schematic diagram illustrating an optional implementation environment provided for an embodiment of this application;

[0064] Figure 2 A schematic diagram of an optional process for scheduling blockchain transactions provided in an embodiment of this application;

[0065] Figure 3 This is a schematic diagram of an optional process before deterministic scheduling optimization provided in an embodiment of this application;

[0066] Figure 4 This is a schematic diagram of an optional process after optimization of deterministic scheduling provided in an embodiment of this application;

[0067] Figure 5 A schematic diagram of an optional first scheduling step provided in an embodiment of this application;

[0068] Figure 6 A schematic diagram of an optional second scheduling stage provided in an embodiment of this application;

[0069] Figure 7 This is a schematic diagram of an optional architecture before nondeterministic scheduling optimization provided in an embodiment of this application;

[0070] Figure 8 A schematic diagram of an optional architecture after optimization of nondeterministic scheduling provided in an embodiment of this application;

[0071] Figure 9 This is a schematic diagram illustrating an optional process after optimization of nondeterministic scheduling, provided as an embodiment of this application.

[0072] Figure 10 This is a schematic diagram illustrating another optional process after optimization of nondeterministic scheduling, provided for an embodiment of this application.

[0073] Figure 11 A schematic diagram of an optional block verification process between nodes provided in an embodiment of this application;

[0074] Figure 12 A schematic diagram of an optional structure of the blockchain transaction scheduling device provided in the embodiments of this application;

[0075] Figure 13 A schematic diagram of another optional structure of the blockchain transaction scheduling device provided in the embodiments of this application;

[0076] Figure 14 A schematic diagram of another optional structure of the blockchain transaction scheduling device provided in the embodiments of this application;

[0077] Figure 15 A schematic diagram of another optional structure of the blockchain transaction scheduling device provided in the embodiments of this application;

[0078] Figure 16 This is a partial structural block diagram of a terminal provided in an embodiment of this application;

[0079] Figure 17 A partial structural block diagram of the server provided in an embodiment of this application. Detailed Implementation

[0080] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0081] It should be noted that in various specific embodiments of this application, when processing data related to the characteristics of the target object, such as target object attribute information or attribute information sets, is required, the permission or consent of the target object will be obtained first. Furthermore, the collection, use, and processing of this data will comply with relevant laws, regulations, and standards. The target object can be a user. In addition, when embodiments of this application need to obtain target object attribute information, separate permission or consent from the target object will be obtained through pop-ups or redirection to a confirmation page. Only after obtaining the target object's separate permission or consent will the necessary target object-related data for the normal operation of the embodiments of this application be obtained.

[0082] To facilitate understanding of the technical solutions provided in the embodiments of this application, some key terms used in the embodiments of this application will be explained below:

[0083] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include a blockchain underlying platform, a platform product service layer, and an application service layer. The blockchain underlying platform can include processing modules such as user management, basic services, smart contracts, and operational monitoring. The user management module is responsible for managing the identity information of all blockchain participants, including maintaining public and private key generation (account management), key management, and maintaining the correspondence between user real identities and blockchain addresses (access management). Under authorization, it also monitors and audits 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. After consensus is reached on valid requests, they are recorded in storage. For a new business request, the basic service first performs interface adaptation parsing and authentication (interface adaptation), and then encrypts the business information through a consensus algorithm (consensus management). The blockchain process involves several layers of data transmission and processing. The first layer, after encryption, transmits the encrypted data consistently and completely to the shared ledger (network communication) and stores it. The second layer, the smart contract module, is responsible for contract registration, issuance, triggering, and execution. Developers can define contract logic using a programming language and publish it to the blockchain (contract registration). Based on the contract terms, the module invokes keys or other events to trigger execution, completing the contract logic. It also provides functions for contract upgrades and cancellations. The third layer, the operation monitoring module, is primarily responsible for deployment, configuration modification, contract settings, cloud adaptation, and real-time visualization of the product's operational status during product release. This includes alerts, network status monitoring, and node device health monitoring. The platform's product service layer provides basic capabilities and implementation frameworks for typical applications. Developers can leverage these capabilities and add business characteristics to implement business logic on the blockchain. The fourth layer provides blockchain-based application services to business stakeholders.

[0084] Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources in an on-demand and easily scalable manner through a network. In a broader sense, cloud computing also refers to the delivery and usage model of services, meaning obtaining necessary services in an on-demand and easily scalable manner through a network. These services can be IT and software related, internet-related, or other services. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0085] Currently, during the execution of blockchain transactions, if conflicting blockchain transactions exist, they are executed sequentially. Therefore, transaction scheduling is necessary, i.e., retaining one blockchain transaction while re-executing the others. Related technologies typically retain blockchain transactions based on a preset transaction order or the order in which they were completed. This approach may lead to the re-execution of resource-intensive transactions, resulting in resource waste and reduced blockchain network performance.

[0086] Based on this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for scheduling blockchain transactions, which can avoid resource waste and improve the performance of the blockchain network.

[0087] Reference Figure 1 , Figure 1 This is a schematic diagram of an optional implementation environment provided in an embodiment of this application. The implementation environment includes a terminal 101 and a server 102, wherein the terminal 101 and the server 102 are connected through a communication network, and the number of terminals 101 can be one or more.

[0088] For example, any terminal 101 can send a blockchain transaction to be executed to the server 102. Any two terminals 101 can send different blockchain transactions, and the same terminal 101 can also send different blockchain transactions. The server 102 can obtain multiple blockchain transactions to be executed and execute each blockchain transaction. It can also obtain a target transaction that has been executed from the multiple blockchain transactions, determine a first conflict relationship between the target transaction and at least one first reference transaction, wherein the first reference transaction is a blockchain transaction that has been executed other than the target transaction. When the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, it can obtain a first weight of the target transaction and a second weight of the first reference transaction, wherein the first weight is determined based on the resource consumption parameters of executing the target transaction, and the second weight is determined based on the resource consumption parameters of executing the first reference transaction. The server can also schedule the target transaction according to the relationship between the first weight and the second weight.

[0089] Server 102 executes multiple blockchain transactions and uses the completed blockchain transactions as target transactions. When scheduling conflicting target transactions and first reference transactions, it first obtains the first weight of the target transaction and the second weight of the first reference transaction. Since both the first and second weights are determined based on resource consumption parameters, scheduling the target transactions according to the relationship between the first and second weights is equivalent to scheduling the target transactions according to resource consumption parameters. This allows the server to retain blockchain transactions with higher resource consumption and re-execute blockchain transactions with lower resource consumption when scheduling target transactions, thus avoiding resource waste and improving the performance of the blockchain network.

[0090] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. Additionally, server 102 can also be a node server in a blockchain network.

[0091] Terminal 101 can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, vehicle terminal, etc., but is not limited to these. Terminal 101 and server 102 can be directly or indirectly connected via wired or wireless communication, and this embodiment of the application does not impose any limitations.

[0092] The methods provided in this application can be applied to various technical fields, including but not limited to cloud computing, blockchain, and other technical fields.

[0093] Reference Figure 2 , Figure 2 This is an optional flowchart illustrating a blockchain transaction scheduling method provided in an embodiment of this application. The blockchain transaction scheduling method can be executed by a server, or by a terminal, or by a server in cooperation with a terminal. The blockchain transaction scheduling method includes, but is not limited to, the following steps 201 to 204.

[0094] Step 201: Obtain multiple blockchain transactions to be executed, and execute each blockchain transaction;

[0095] In a blockchain network, a transaction refers to a transaction generated within that network. Blockchain nodes can execute these transactions. Each node stores a ledger, which includes the blockchain itself and a world state database. The world state database stores the current state of all state data. The blockchain records historical transactions involved in changing state data from its initial state to its current state. State data can be stored in key-value pairs. The current state refers to the key of the state data, along with its corresponding value and the current version number. Executing a blockchain transaction involves reading or writing state data. If a transaction reads state data, it includes the key; if it writes state data, it includes the key and its corresponding value.

[0096] For example, a first blockchain transaction is used to read first state data and write second state data. The first blockchain transaction includes a key 'key1' for the first state data, a key 'key2' for the second state data, and a value 'value2' for key 'key2'. When the first blockchain transaction is executed, the value 'value1' corresponding to key 'key1' is read from the world state database. At this time, the current version number of key 'key1' in the world state database does not change. Then, the value 'value2' corresponding to key 'key2' is written to the world state database. The version number corresponding to key 'key2' in the world state database will change. For example, before executing the first blockchain transaction, the world state database stores key 'key2', the value corresponding to key 'key2' is value 'value2', and the current version number corresponding to key 'key2' is 1. After executing the first blockchain transaction, the current version number corresponding to key 'key2' is incremented by one, the value corresponding to key 'key2' is updated to value 'value2', and the current version number corresponding to key 'key2' is updated to 2.

[0097] Based on this, in the embodiments of this application, after a blockchain node obtains multiple blockchain transactions to be executed, the blockchain node can use multiple threads to execute the blockchain transactions concurrently. It can be understood that threads can also be replaced by processes, coroutines, or other execution bodies. Each thread executes one blockchain transaction, which requires that each blockchain transaction corresponds to the same initial world state. This means that the execution environment of each thread is the same. Specifically, the current world state is obtained from the world state database and used as the initial world state. Then, each thread executes the corresponding blockchain transaction based on the same initial world state.

[0098] For example, a batch of 20 blockchain transactions to be executed is obtained. Then, based on the same initial world state, the 20 blockchain transactions are executed concurrently using multiple threads. After all 20 blockchain transactions have been executed, the intermediate world state corresponding to each blockchain transaction can be obtained. Generally speaking, since there are differences between different blockchain transactions, the intermediate world states corresponding to each blockchain transaction are different. Therefore, 20 different intermediate world states can be obtained.

[0099] Step 202: Obtain the completed target transaction from multiple blockchain transactions, and determine the first conflict relationship between the target transaction and at least one first reference transaction;

[0100] The first reference transaction is the blockchain transaction that has been completed, excluding the target transaction.

[0101] The execution times of different blockchain transactions can vary. When a blockchain transaction is completed, it can be used as the target transaction. If no other blockchain transactions are completed when the target transaction is completed, it means that there is no conflict between the target transaction and other blockchain transactions at the time of the target transaction's completion. Conversely, if other blockchain transactions have been completed when the target transaction is completed, it means that there may be a conflict between the target transaction and other blockchain transactions at the time of the target transaction's completion. Therefore, the currently completed blockchain transactions other than the target transaction are used as the first reference transactions. Conflict detection is performed on the target transaction and the first reference transaction to determine the first conflict relationship between them. The first conflict relationship is used to indicate whether there is a conflict between the target transaction and the first reference transaction.

[0102] For example, based on the above content regarding the concurrent execution of 20 blockchain transactions using multiple threads, it is known that after all 20 blockchain transactions are executed, 20 corresponding intermediate world states can be obtained. During the execution of each blockchain transaction, a corresponding read set and write set are created for each blockchain transaction. The read set is used to indicate the state data read by executing the blockchain transaction. Therefore, the read set includes the key of the read state data and the commit version number corresponding to the key. The read set may also include the value corresponding to the key of the read state data. The write set is used to indicate the state data inserted, deleted, or updated by executing the blockchain transaction. Therefore, the write set includes the key of the written state data and the value corresponding to the key. The read set and write set of a blockchain transaction can be collectively referred to as the read-write set of a blockchain transaction.

[0103] In a series of blockchain transactions, when the blockchain transaction executed earlier in the execution order is completed and the current state of the corresponding state data is updated, the current version number corresponding to the key will change. When the blockchain transaction executed earlier in the execution order is executed and the state data needs to be read, the current version number corresponding to the key of the state data will be read. If the version number corresponding to the key is updated when the blockchain transaction executed earlier in the execution order is executed, then the current version number corresponding to the key is the updated version number. The updated version number is used as the commit version number corresponding to the key and recorded in the read set.

[0104] Therefore, executing 20 blockchain transactions yields 20 read / write sets. Ideally, any two read / write sets are disjoint, meaning they do not contain the same key. In this case, the 20 blockchain transactions can be executed in parallel, and the resulting 20 intermediate world states can be directly merged to obtain the final world state, which is then used as the execution result of this batch of blockchain transactions. Normally, there will be at least one pair of intersecting read / write sets, meaning they contain at least one common key. When the read / write set of one blockchain transaction intersects with the read / write set of another, it is equivalent to these two blockchain transactions conflicting with each other, requiring sequential execution of each conflicting blockchain transaction.

[0105] Step 203: When the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, obtain the first weight of the target transaction and the second weight of the first reference transaction;

[0106] The first weight is determined based on the resource consumption parameters of executing the target transaction, and the second weight is determined based on the resource consumption parameters of executing the first reference transaction.

[0107] Among them, the resource consumption parameter is used to indicate the resources required to execute a blockchain transaction. These resources can be time resources, memory resources, etc. For example, when the resource is a time resource, the resource consumption parameter can be the execution time of the blockchain transaction. When the resource is a memory resource, the resource consumption parameter can be at least one of the following: number of read set keys, read set memory size, number of write set keys, and write set memory size.

[0108] Specifically, when the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, it means that the target transaction and the first reference transaction need to be executed sequentially. The first weight of the target transaction is determined based on the resource consumption parameters of executing the target transaction, and the second weight of the first reference transaction is determined based on the resource consumption parameters of executing the first reference transaction. Then, the target transaction and the first reference transaction are scheduled according to the weight between the first weight of the target transaction and the second weight of the first reference transaction.

[0109] Step 204: Schedule the target transaction according to the relationship between the first weight and the second weight.

[0110] Since both the first and second weights are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first and second weights is equivalent to scheduling the target transaction according to the resource consumption parameters. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption when scheduling target transactions, thus avoiding resource waste and improving the performance of the blockchain network.

[0111] In one possible implementation, the target transaction is scheduled based on the relationship between the first weight and the second weight, specifically:

[0112] The target transaction is scheduled according to the relationship between the first weight and each of the second weights;

[0113] Alternatively, calculate the sum of the first weights for all second weights, and schedule the target transaction based on the relationship between the first weights and the sum of the first weights.

[0114] The relationship between the first weight and each of the second weights refers to the first weight being greater than the second weight, or the first weight being less than the second weight, or the first weight being equal to the second weight; the relationship between the first weight and the sum of the first weights refers to the first weight being greater than the sum of the first weights, or the first weight being less than the sum of the first weights, or the first weight being equal to the sum of the first weights.

[0115] By comparing the magnitudes of the first weight and each of the second weights, it is possible to effectively determine whether the resource consumption of executing the target transaction is greater than the resource consumption of executing each of the first reference transactions. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption, thus avoiding resource waste and improving the performance of the blockchain network.

[0116] In one possible implementation, the target transaction is obtained after all blockchain transactions have been executed. The first reference transaction is not added to the transaction snapshot. The target transaction is scheduled according to the relationship between the first weight and each of the second weights. Specifically, this could be as follows:

[0117] When the first weight is greater than each of the second weights, the target transaction is added to the transaction snapshot;

[0118] Alternatively, if the first weight is less than any of the second weights, the target transaction is re-executed;

[0119] Alternatively, when the first weight is equal to at least one second weight and the first weight is greater than the remaining second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0120] A transaction snapshot refers to the completion queue of blockchain transactions. When a blockchain transaction is completed, it is added to the transaction snapshot, which is equivalent to adding the completed blockchain to the end of the completion queue. When multiple threads execute multiple blockchain transactions concurrently, there can be multiple completion queues, depending on the number of blockchain transactions that can be executed in parallel. Multiple blockchain transactions that conflict with each other correspond to the same completion queue. Blockchain transactions added to the transaction snapshot earlier are placed earlier in the completion queue, and blockchain transactions added later are placed later. Subsequently, the conflicting blockchain transactions can be executed sequentially according to their order in the completion queue.

[0121] One approach is to schedule blockchain transactions using deterministic scheduling. The execution result of each blockchain transaction is deterministic. Deterministic scheduling performs conflict detection on blockchain transactions in rounds. The timing of conflict detection is configured as follows: after all blockchain transactions have been executed, conflict detection is performed on each completed blockchain transaction to determine the conflict relationships between them. For example, in the first round, conflict detection is performed only after all blockchain transactions have been executed. The result of conflict detection can be that there are no conflicts between multiple blockchain transactions, or that there are conflicts between multiple blockchain transactions, or that there are conflicts between multiple blockchain transactions or no conflicts. When the result indicates that there are no conflicts between multiple blockchain transactions, it means that these multiple blockchain transactions can be executed in parallel. When the result indicates that there are conflicts between multiple blockchain transactions, it means that these multiple blockchain transactions need to be executed sequentially.

[0122] Therefore, for multiple conflicting blockchain transactions, only one blockchain transaction is retained in the current round and added to the transaction snapshot. The remaining blockchain transactions are re-executed in the next round. Since deterministic scheduling handles conflicts between transactions in rounds, conflict detection is only performed on blockchain transactions in the next round after all blockchain transactions that need to be re-executed have been re-executed. Therefore, in deterministic scheduling, the target transaction is obtained after all blockchain transactions have been executed. The first reference transaction to be conflict-detected is not added to the transaction snapshot, so there is no need to perform conflict detection on the first reference transaction that has been added to the transaction snapshot.

[0123] Currently, when scheduling multiple conflicting blockchain transactions using deterministic scheduling, the blockchain transactions are added to the transaction snapshot according to the order in which they were completed, and the remaining blockchain transactions are re-executed. This may result in resource-intensive blockchain transactions being re-executed, leading to resource waste and reduced performance of the blockchain network.

[0124] Based on this, the scheduling method provided in this application can optimize deterministic scheduling. When scheduling a target transaction and a first reference transaction that conflict with each other, the first weight of the target transaction and the second weight of the first reference transaction are first obtained. Since both the first weight and the second weight are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the second weight is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain transaction. The first weight is used to indicate the resources required to execute the target transaction, and the second weight is used to indicate the resources required to execute the first reference transaction. When the resources required to execute the target transaction are small, the first weight of the target transaction is small; conversely, when the resources required to execute the target transaction are large, the first weight of the target transaction is large. Similarly, when the resources required to execute the first reference transaction are small, the second weight of the first reference transaction is small; conversely, when the resources required to execute the first reference transaction are large, the second weight of the first reference transaction is large.

[0125] Specifically, for the three comparison scenarios of the first weight and the second weight, if the first weight is the largest, the target transaction is retained and added to the transaction snapshot; if the first weight is less than any of the second weights, the target transaction is re-executed; if the first weight is the same as some of the second weights and the first weight is greater than the rest of the second weights, the target transaction can be added to the transaction snapshot or re-executed. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption when scheduling target transactions, thus avoiding resource waste and improving the performance of the blockchain network.

[0126] Exemplarily, for three blockchain transactions A, B, and C that conflict with each other, before executing the blockchain transactions, the sequence numbers of the three blockchain transactions can be determined as: A < B < C. The three blockchain transactions are started to be executed simultaneously. The first-round execution results will definitely be A, B, and C. Assume that the order of the resource consumption required to execute these three blockchain transactions is: A < B < C. In the first round, when all three blockchain transactions are executed, conflict detection is performed on the blockchain transactions. Since blockchain transaction A, blockchain transaction B, and blockchain transaction C conflict with each other, scheduling needs to be performed on blockchain transaction A, blockchain transaction B, and blockchain transaction C. One of the blockchain transactions is taken as the target transaction, and the remaining blockchain transactions are taken as the first reference transactions. When blockchain transaction A is the target transaction and blockchain transactions B and C are the first reference transactions, the first weight of blockchain transaction A is less than the second weight of blockchain transaction B, and at the same time, the first weight of blockchain transaction A is less than the second weight of blockchain transaction C. Therefore, in the next round, blockchain transaction A is re-executed. Similarly, when blockchain transaction B is the target transaction, it can be determined that blockchain transaction B needs to be re-executed in the next round. In the next round, blockchain transactions A and B can be started to be executed simultaneously. When blockchain transaction C is the target transaction, the first weight of blockchain transaction C is greater than the second weight of blockchain transaction A, and the first weight of blockchain transaction C is greater than the second weight of blockchain transaction B. Therefore, blockchain transaction C is added to the transaction snapshot. Thus, during the conflict handling in the first round, it is possible to retain the blockchain transaction C with more resource consumption and add this blockchain transaction C to the transaction snapshot, and re-execute the blockchain transactions A and B with less resource consumption. Similarly, during the conflict handling in the second round, it is possible to retain the blockchain transaction B with more resource consumption and add this blockchain transaction B to the transaction snapshot, and re-execute the blockchain transaction A with less resource consumption, avoiding resource waste and improving the performance of the blockchain network.

[0127] In a possible implementation manner, adding the target transaction to the transaction snapshot or re-executing the target transaction can specifically be taking the target transaction and the first reference transactions with the same weight as the target transaction as the first transaction set; adding one of the blockchain transactions in the transaction set to the transaction snapshot and re-executing the remaining blockchain transactions in the transaction set; based on this, when dealing with the situation where the first weight is the same as some of the second weights and the first weight is greater than the remaining second weights, taking the target transaction and the first reference transactions with the same weight as the target transaction as the first transaction set, and then in the first transaction set, selecting the blockchain transaction to be added to the transaction snapshot and selecting the blockchain transaction to be re-executed, so that the conflicting blockchain transactions can be executed serially.

[0128] One approach is to select blockchain transactions randomly. Specifically, a blockchain transaction is randomly selected from the first transaction set and added to the transaction snapshot. The remaining blockchain transactions in the first transaction set are then re-executed. When all blockchain transactions have been added to the transaction snapshot, regardless of whether the random selection results are to add the transaction snapshot to the transaction snapshot or to add the remaining blockchain transactions, it can be guaranteed that conflicting blockchain transactions can be executed serially.

[0129] Therefore, when using a random selection method, the execution order of multiple blockchain transactions executed sequentially is not fixed. However, as long as the execution result is the same after all blockchain transactions are executed, consensus can be achieved subsequently. The execution process of a blockchain transaction is as follows: first, the transaction execution function in the smart contract is called; then, based on the transaction execution function and the blockchain transaction, historical transaction data is processed. There can be multiple smart contracts, and each smart contract can deploy multiple transaction execution functions. Therefore, the corresponding transaction execution function in the corresponding smart contract needs to be called. Historical transaction data refers to the state data of the initial world state before the execution of the blockchain transaction. The execution result of the blockchain transaction is the final world state after the execution of the blockchain transaction. Therefore, when executing non-conflicting blockchain transactions in parallel and serially executing conflicting blockchain transactions, changing the execution order of multiple serially executed blockchain transactions can also ensure that the final world state obtained after all blockchain transactions are executed is the same.

[0130] State data can be stored in the form of key-value pairs. Different blockchain transactions can be used to process state data corresponding to different keys, or they can be used to process state data corresponding to the same key. When different blockchain transactions are used to process state data corresponding to the same key, and the blockchain transactions are executed in parallel, the blockchain transactions will conflict with each other.

[0131] For example, there are three blockchain transactions to be executed, as follows: the first blockchain transaction is for the first object to transfer 100 yuan to the second object through its own account; the second blockchain transaction is for the first object to transfer 200 yuan to the third object through its own account; and the third blockchain transaction is for the fourth object to transfer 200 yuan to the fifth object through its own account.

[0132] Before executing each blockchain transaction, the specific state data corresponding to the initial world state are as follows: the first historical transaction data is that the first object's account has 500 yuan, and the second historical transaction data is that the fourth object's account has 300 yuan.

[0133] Through conflict detection, it can be determined that the first blockchain transaction and the second blockchain transaction conflict with each other and need to be executed sequentially. The third blockchain transaction does not conflict with the other blockchain transactions and can be executed in parallel with the other blockchain transactions.

[0134] Assuming that executing the first blockchain transaction and executing the second blockchain transaction require the same amount of resources, which is equivalent to the first blockchain transaction and the second blockchain transaction having the same weight, a random selection method can be used to choose between them.

[0135] In the first scenario: First, the first transaction execution function is called to execute the first blockchain transaction, processing the first historical transaction data. The first execution result is that the first object's account has 400 yuan. Then, using the first execution result as historical transaction data, the second transaction execution function is called to execute the second blockchain transaction, processing the first execution result. The second execution result is that the first object's account has 200 yuan. During the execution of the first and second blockchain transactions, the third blockchain transaction can be executed in parallel. The third transaction execution function is called to execute the third blockchain transaction, processing the third historical transaction data. The third execution result is that the fourth object's account has 100 yuan. Therefore, after all blockchain transactions are executed, the final world state is: the first object's account has 200 yuan, and the fourth object's account has 100 yuan.

[0136] In the second scenario: First, the second transaction execution function is called to execute the second blockchain transaction, processing the first historical transaction data. The first execution result is that the first object's account has 300 yuan. Then, using the first execution result as historical transaction data, the first transaction execution function is called again to execute the first blockchain transaction, processing the first execution result. The second execution result is that the first object's account has 200 yuan. During the execution of the first and second blockchain transactions, the third blockchain transaction can be executed in parallel. The third transaction execution function is called to execute the third blockchain transaction, processing the third historical transaction data. The third execution result is that the fourth object's account has 100 yuan. Therefore, after all blockchain transactions are executed, the final world state is: the first object's account has 200 yuan, and the fourth object's account has 100 yuan.

[0137] As can be seen, compared with the first case, the second case does not change the final world state obtained after all blockchain transactions have been executed. Therefore, when executing non-conflicting blockchain transactions in parallel and executing conflicting blockchain transactions in sequence, changing the execution order of multiple serially executed blockchain transactions can also ensure that the final world state obtained after all blockchain transactions have been executed is the same.

[0138] Alternatively, a fixed selection method can be used. Specifically, the blockchain transactions located at a fixed position in the first transaction set are added to the transaction snapshot, and the remaining blockchain transactions in the first transaction set are re-executed. Assuming that the blockchain transactions are arranged sequentially in the first transaction set, the fixed position can be the first or the last. Therefore, the blockchain transactions located at the first or the last position in the first transaction set are added to the transaction snapshot. The fixed position can also be the middle position. When the number of blockchain transactions in the first transaction set is even, half of the number of transactions is used as the value of the middle position. For example, if the number of transactions is 4 and the value of the middle position is 2, then the blockchain transaction located in the second position in the first transaction set is added to the transaction snapshot. Similarly, the fixed selection method will not affect the execution result of the blockchain transactions.

[0139] In one possible implementation, the blockchain transaction scheduling method further includes:

[0140] Whenever all blockchain transactions that were not added to the transaction snapshot are re-executed, the blockchain transactions that were re-executed but not added to the transaction snapshot will be used as the target transactions.

[0141] The target transactions are rescheduled until all blockchain transactions have been added to the transaction snapshot.

[0142] One approach is to schedule the target transaction using deterministic scheduling. Deterministic scheduling involves round-robin conflict detection of blockchain transactions. For example, in the first round, conflict detection is performed only after all blockchain transactions have been executed to determine the conflict relationships between them. The result of conflict detection can be that there are no conflicts between multiple blockchain transactions, or that there are conflicts between multiple blockchain transactions, or that there are conflicts between multiple blockchain transactions or that there are no conflicts. When the result of conflict detection indicates that there are no conflicts between multiple blockchain transactions, it means that these multiple blockchain transactions can be executed in parallel. Therefore, when the target transaction does not conflict with any of the first reference transactions, the target transaction can be added to the transaction snapshot without re-executing it. However, when the result of conflict detection indicates that there are conflicts between multiple blockchain transactions, it means that these multiple blockchain transactions need to be executed serially.

[0143] Therefore, when a target transaction conflicts with the first reference transaction, the target transaction cannot be executed in parallel with the conflicting first reference transaction. The target transaction is scheduled according to the relationship between the first and second weights. Specifically, in the current round, for conflicting blockchain transactions, the blockchain transaction with the highest weight is added to the transaction snapshot. In the next round, the blockchain transaction with the lower weight is re-executed. Furthermore, in the second round, after all blockchain transactions that need to be re-executed have been re-executed, conflict detection is performed on the re-executed blockchain transactions. The re-executed blockchain transactions are equivalent to the target transaction in the first round, so the target transaction can be scheduled again according to the scheduling method of the first round. Thus, if conflicting blockchain transactions still exist in the current round, the blockchain transaction with the lower weight needs to be re-executed, and then the target transaction is scheduled again in the next round until a round without conflicting blockchain transactions is entered. Only when this round ends is the scheduling of the target transaction completed, which is equivalent to all blockchain transactions being added to the transaction snapshot.

[0144] Specifically, refer to Figure 3 , Figure 3 The schematic diagram of an optional process before deterministic scheduling optimization provided in this application embodiment adds the first completed blockchain transaction to the transaction snapshot according to the order in which blockchain transactions are completed, and re-executes the remaining blockchain transactions. This may cause blockchain transactions that consume more resources to be re-executed, resulting in resource waste and reduced performance of the blockchain network.

[0145] Additionally, refer to Figure 4 , Figure 4 This is an optional flowchart of the deterministic scheduling optimization provided in the embodiments of this application. Six blockchain transactions are executed in parallel. The six blockchain transactions are: Tx0, Tx1, Tx2, Tx3, Tx4 and Tx5. The execution time of Tx0 is 3 seconds, the execution time of Tx1 is 1 second, the execution time of Tx2 is 2 seconds, the execution time of Tx3 is 4 seconds, the execution time of Tx4 is 2 seconds, and the execution time of Tx5 is 4 seconds. The preset duration is 1 second. Based on the resources required to execute each blockchain transaction, the weight of Tx0 is determined to be 30, the weight of Tx1 is 10, the weight of Tx2 is 20, the weight of Tx3 is 40, the weight of Tx4 is 20, and the weight of Tx5 is 40.

[0146] In the first round, after all blockchain transactions have been executed, conflict detection is performed on each blockchain transaction. For example, Tx0 is designated as the target transaction, and the other executed blockchain transactions that have not been added to the transaction snapshot are designated as first reference transactions. The first reference transactions include Tx1, Tx2, Tx3, Tx4, and Tx5. Then, the first conflict relationship between the target transaction and each of the first reference transactions is determined. Since the read / write sets of Tx0, Tx2, and Tx5 all contain the key k1, while the read / write sets of Tx1, Tx3, and Tx4 do not contain the key k1, conflict detection determines that there is a conflict between Tx0 and Tx2, and a conflict between Tx0 and Tx5. Then, based on the relationship between the weights of Tx0 and Tx2, Tx0 is scheduled, and based on the relationship between the weights of Tx0 and Tx5, Tx0 is scheduled. Based on the weight relationship between Tx0 and Tx5, Tx0 is scheduled. Since the weight of Tx0 is less than that of Tx5, Tx0 is re-executed. Similarly, it is determined that Tx2 will be re-executed, and Tx5 is added to the transaction snapshot. Then, Tx1 is selected as the target transaction. Both Tx1 and Tx3 contain the key k2 in their read and write sets. After conflict detection, it is determined that there is a conflict between Tx1 and Tx3. Based on the weight relationship between Tx1 and Tx3, Tx1 is scheduled. Since the weight of Tx1 is less than that of Tx3, Tx1 is re-executed. Similarly, Tx3 is added to the transaction snapshot. Then, Tx4 is selected as the target transaction. Both Tx4 and Tx5 contain the key k3 in their read and write sets. After conflict detection, it is determined that Tx4 does not conflict with other blockchain transactions, and Tx4 is added to the transaction snapshot.

[0147] In the second round, the re-executed Tx0, Tx1, and Tx2 are scheduled to determine whether to add Tx0 and Tx1 to the transaction snapshot and re-execute Tx2.

[0148] In the third round, the re-executed Tx2 is scheduled to determine whether to add Tx2 to the transaction snapshot. After the third round, all blockchain transactions are added to the transaction snapshot, completing the scheduling of the target transaction.

[0149] As can be seen, compared to the total execution time of 12 seconds before the deterministic scheduling optimization, the total execution time after the deterministic scheduling optimization is 9 seconds, a reduction of 3 seconds, and the execution efficiency is improved by 25%, which is a significant improvement in execution efficiency. At the same time, it can retain blockchain transactions with higher resource consumption and re-execute blockchain transactions with lower resource consumption, avoiding resource waste and improving the performance of the blockchain network.

[0150] In addition, based on the scheduling results of the target transactions, a Directed Acyclic Graph (DAG) is constructed. Subsequently, the DAG and each blockchain transaction can be packaged together to obtain a proposal block carrying the DAG. The proposal block is then sent to the validator nodes in the blockchain network, and the validator nodes can execute the blockchain transactions in the proposal block based on the DAG.

[0151] In one possible implementation, the target transaction is obtained whenever one of the blockchain transactions is executed. The first reference transaction is not added to the transaction snapshot. The target transaction is scheduled according to the relationship between the first weight and the sum of the first weights. Specifically, this could be as follows:

[0152] When the first weight is greater than the sum of the first weights, wait for a preset time, and then schedule the target transaction after the preset time has been reached.

[0153] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0154] Alternatively, when the first weight equals the sum of the first weights, wait for a preset time and then schedule or re-execute the target transaction after the preset time has elapsed.

[0155] Among these methods, nondeterministic scheduling can be used to schedule target transactions. In nondeterministic scheduling, the execution result of each blockchain transaction is uncertain. Nondeterministic scheduling uses the specific execution time of the blockchain transaction as the judgment criterion. In nondeterministic scheduling, the conflict detection time point is configured as follows: whenever a blockchain transaction is completed, a conflict detection is performed on that blockchain transaction to determine the conflict relationship between that blockchain transaction and the other completed blockchain transactions. The result of the conflict detection can be that there is no conflict between the blockchain transaction and the other completed blockchain transactions, or it can be that there is a conflict between the blockchain transaction and the other completed blockchain transactions. When the result of the conflict detection indicates that there is no conflict between the blockchain transaction and the other completed blockchain transactions, it means that the blockchain transaction can be executed in parallel with the other completed blockchain transactions. When the result of the conflict detection indicates that there is a conflict between the blockchain transaction and the other completed blockchain transactions, it means that the blockchain transaction needs to be executed serially with the conflicting blockchain transactions.

[0156] Therefore, for conflicting blockchain transactions, only one blockchain transaction is retained and added to the transaction snapshot, while the remaining blockchain transactions are re-executed. Since the execution times of different blockchain transactions can be different, the conflict detection time points corresponding to different blockchain transactions can also be different in nondeterministic scheduling. The target transaction is obtained whenever one of the blockchain transactions is completed.

[0157] Currently, when scheduling multiple conflicting blockchain transactions using nondeterministic scheduling, the blockchain transactions are added to the transaction snapshot according to the order in which they were completed, and the remaining blockchain transactions are re-executed. This may result in resource-intensive blockchain transactions being re-executed, leading to resource waste and reduced performance of the blockchain network.

[0158] Based on this, the scheduling method provided in this application can optimize nondeterministic scheduling. Nondeterministic scheduling is applicable to pessimistic scenarios, where a blockchain transaction can depend on multiple blockchain transactions simultaneously. When the target transaction is completed, it enters the first scheduling stage. In the first scheduling stage: when the target transaction is completed, the conflicting target transactions and first reference transactions are scheduled. First, the first weight of the target transaction and the second weight of the first reference transaction are obtained. The number of first reference transactions can be one or more. Therefore, based on the number of first reference transactions, different scheduling situations can be distinguished, as follows:

[0159] Scheduling Situation 11: The number of first reference transactions is one. The sum of the first weights is the second weight of the first reference transaction. Since both the first weight and the second weight are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the sum of the first weights is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain exchange. The first weight is used to indicate the resources required to execute the target exchange, and the second weight is used to indicate the resources required to execute the first reference exchange. When the resources required to execute the target exchange are small, the first weight is small, and vice versa. Similarly, when the resources required to execute the first reference exchange are small, the sum of the first weights is small, and vice versa.

[0160] Scheduling Situation 12: There are multiple first reference transactions, and there is no conflict between any two first reference transactions when the target transaction is completed. All first reference transactions can be used as the first reference set. The second weights of all first reference transactions need to be summed, which is equivalent to obtaining the sum of the first weights of the first reference set. Since both the first weight and the second weight are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the sum of the first weights is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain transaction. The first weight is used to indicate the resources required to execute the target transaction, and the second weight is used to indicate the resources required to execute the first reference transaction. When the resources required to execute the target transaction are small, the first weight is small, and vice versa. Similarly, when the resources required to execute all first reference transactions in the first reference set are small, the sum of the first weights is small, and vice versa.

[0161] For example, first reference transaction 1, first reference transaction 2, and first reference transaction 3 are all used to process state data corresponding to the same key. The execution time of first reference transaction 1 is 1 second, the execution time of first reference transaction 2 is 2 seconds, and the execution time of first reference transaction 3 is 3 seconds. First reference transaction 1 and first reference transaction 2 are executed simultaneously. After one second, first reference transaction 1 is completed and is used as the target transaction. Through conflict detection, it is determined that first reference transaction 1 does not conflict with other blockchain transactions, and first reference transaction 1 is retained. At this time, first reference transaction 3 begins execution. After two seconds, first reference transaction 2 is completed and first reference transaction 1 is used as the target transaction. Through conflict detection, it is determined that first reference transaction 2 conflicts with first reference transaction 1, and the weight relationship between first reference transaction 2 and first reference transaction 1 is determined. Assuming that first reference transaction 2 has a larger weight, first reference transaction 1 is re-executed, and first reference transaction 2 is retained. After three seconds, first reference transaction 1 is completed again and first reference transaction 1 is used as the target transaction. After conflict detection, it is determined that the first reference transaction 1 does not conflict with the other blockchain transactions, and the first reference transaction 1 is retained. After four seconds, the first reference transaction 3 is executed and is taken as the target transaction. Through conflict detection, it is determined that the first reference transaction 3 conflicts with the other blockchain transactions. Since there is no conflict between the first reference transaction 1 and the first reference transaction 2 when the first reference transaction 3 is executed, the first reference transaction 1 and the first reference transaction 2 are taken as the first reference set. Assuming that the weight of the first reference transaction 1 is 100, the weight of the first reference transaction 2 is 200, and the weight of the first reference transaction 3 is 250, the first weight of the first reference set is summed by summing the weights of the first reference transaction 1 and the first reference transaction 2, and the first weight sum is 300. Comparing the first weight with the first weight sum, since 250 < 300, the first reference transaction 3 is re-executed, and the first reference transaction 1 and the first reference transaction 2 are retained. This achieves the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption, avoiding resource waste and improving the performance of the blockchain network.

[0162] Based on this, since a blockchain transaction can depend on multiple blockchain transactions simultaneously in a pessimistic scenario, when the target transaction is completed, some of the blockchain transactions it depends on may not have been completed yet. By setting a preset time and waiting, we can wait for each of the blockchain transactions that the target transaction depends on to be completed, making the scheduling result of the target transaction more accurate and thus improving the certainty of the execution result. Specifically, if it is not necessary to re-execute the target transaction in the first scheduling stage, it enters the second scheduling stage. In the second scheduling stage, after the preset time is reached, the target transaction is scheduled. This allows us to retain blockchain transactions that consume more resources and re-execute blockchain transactions that consume less resources when scheduling the target transaction, avoiding resource waste and improving the performance of the blockchain network.

[0163] It should be noted that different blockchain transactions can correspond to different preset durations. However, it is necessary to ensure that the preset durations are set according to the same delay rules on each node. For example, the preset durations can be set according to the contract, and all nodes must have the same preset duration for the same contract.

[0164] In one possible implementation, determining a first conflict relationship between the target transaction and at least one first reference transaction can specifically involve determining a second conflict relationship between the target transaction and a second reference transaction, wherein the second reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction; when the second conflict relationship indicates that there is no conflict between the target transaction and the second reference transaction, the first conflict relationship between the target transaction and at least one first reference transaction is determined.

[0165] The second conflict relationship is used to indicate whether there is a conflict between the target transaction and the second reference transaction.

[0166] Based on this, in the first scheduling stage, it is necessary to first determine whether there is a conflict between the target transaction and the second reference transaction, which is equivalent to determining whether there is a conflict between the target transaction and the blockchain transactions that have been added to the transaction snapshot. If there is a conflict, the target transaction is re-executed. Subsequently, there is no need to determine the relationship between the first weight and the sum of the first weights, which can improve the scheduling efficiency of blockchain transactions and thus improve the execution efficiency of blockchain transactions.

[0167] Specifically, refer to Figure 5 , Figure 5This is an optional flowchart of the first scheduling stage provided in the embodiments of this application. It requires three judgments in sequence. In the first judgment, it is determined whether there is a conflict between the target transaction and the second reference transaction through the second conflict relationship. If the judgment is yes, the target transaction is re-executed. Otherwise, a second judgment is performed. In the second judgment, it is determined whether there is a conflict between the target transaction and the first reference transaction through the first conflict relationship. If the judgment is no, the target transaction is re-executed. Otherwise, a third judgment is performed. In the third judgment, it is determined whether the first weight is greater than the sum of the first weights. When the first weight is greater than the sum of the first weights, the second scheduling stage is entered. In the second scheduling stage, it waits for a preset time. When the first weight is less than the sum of the first weights, the target transaction is re-executed. When the first weight is equal to the sum of the first weights, one can choose to enter the second scheduling stage or choose to re-execute the target transaction. The figure shows the option to re-execute the target transaction.

[0168] Specifically, when a blockchain transaction begins execution, the current transaction count in the transaction snapshot is used as the first reference count. The current transaction count in the transaction snapshot refers to the number of blockchain transactions included in the transaction snapshot. After the corresponding transaction execution time, the blockchain transaction is completed. When the blockchain transaction is completed, it is used as the target transaction, and the current transaction count in the transaction snapshot is used as the second reference count. The first reference count and the second reference count are compared. If the first reference count and the second reference count are the same, it means that the target transaction does not have a second reference transaction; otherwise, the target transaction has a second reference transaction.

[0169] Conversely, in another possible implementation, the first scheduling stage may not require determining whether there is a conflict between the target transaction and the second reference transaction. Compared to the stage where it is necessary to determine whether there is a conflict between the target transaction and the second reference transaction, the scheduling process will take a little more time. However, this time is much less than the time spent re-executing blockchain transactions that consume more resources. Therefore, when scheduling target transactions, it is possible to retain blockchain transactions that consume more resources and re-execute blockchain transactions that consume fewer resources, thereby avoiding resource waste and improving the performance of the blockchain network.

[0170] In one possible implementation, the target transaction is scheduled after a preset time period has elapsed. Specifically, after the preset time period has elapsed, a third conflict relationship is determined between the target transaction and at least one third reference transaction. The third reference transaction is a blockchain transaction that, other than the target transaction, has been completed and has not been added to the transaction snapshot. When the third conflict relationship indicates that there is a conflict between the target transaction and the third reference transaction, the third weight of the third reference transaction is obtained. The third weight is determined based on the resource consumption parameters of executing the third reference transaction. The sum of the second weights of all third weights is calculated, and the target transaction is scheduled according to the relationship between the first weight and the sum of the second weights.

[0171] Among them, the third conflict relationship is used to indicate whether there is a conflict between the target transaction and the third reference transaction; the relationship between the first weight and the sum of the second weights refers to the first weight being greater than the sum of the second weights, or the first weight being less than the sum of the second weights, or the first weight being equal to the sum of the second weights.

[0172] Based on this, when the preset waiting time is determined in the first scheduling stage, the second scheduling stage is initiated. In the second scheduling stage, the preset waiting time continues. After the preset time is reached, conflicting target transactions and third reference transactions are scheduled. First, the first weight of the target transaction and the third weight of the third reference transaction are obtained. The number of third reference transactions can be one or more. Therefore, based on the number of third reference transactions, different scheduling scenarios can be identified, as follows:

[0173] Scheduling Situation 13: The number of third reference transactions is one. The sum of the second weights is the third weight of this third reference transaction. Since both the first and third weights are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the sum of the first and second weights is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain exchange. The first weight is used to indicate the resources required to execute the target exchange, and the third weight is used to indicate the resources required to execute the third reference exchange. When the resources required to execute the target exchange are small, the first weight is small, and vice versa. Similarly, when the resources required to execute the third reference exchange are small, the sum of the second weights is small, and vice versa.

[0174] Scheduling Situation 14: There are multiple third reference transactions, and there is no conflict between any two third reference transactions when the target transaction is completed. All third reference transactions can be used as the second reference set. Similar to scheduling situation 12, the third weights of all third reference transactions need to be summed, which is equivalent to obtaining the sum of the second weights of the second reference set. Since the first weight and the third weight are both determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the sum of the second weights is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain transaction. The first weight is used to indicate the resources required to execute the target transaction, and the third weight is used to indicate the resources required to execute the third reference transaction. When the resources required to execute the target transaction are small, the first weight is small, and vice versa. Similarly, when the resources required to execute all third reference transactions in the second reference set are small, the sum of the second weights is small, and vice versa.

[0175] In addition, there is also a scheduling situation 15, which is in contrast to scheduling situation 14.

[0176] Scheduling Situation 15: There are multiple third reference transactions, and there are conflicts between the third reference transactions when the target transaction is completed. In the transaction set composed of the target transaction and the third reference transactions, the blockchain transaction with the largest weight is retained, and the blockchain transaction with the smallest weight is re-executed.

[0177] In one possible implementation, the target transaction is scheduled based on the relationship between the sum of the first weight and the second weight, specifically:

[0178] When the sum of the first weights is greater than the sum of the second weights, the target transaction is added to the transaction snapshot;

[0179] Alternatively, if the sum of the first weights is less than the sum of the second weights, the target transaction is re-executed;

[0180] Alternatively, when the first weight equals the sum of the second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0181] Based on this, for the three comparison scenarios of the sum of the first weight and the second weight, if the first weight is greater than the sum of the second weight, the target transaction is retained and added to the transaction snapshot; if the first weight is less than the sum of the second weight, the target transaction is re-executed; if the first weight is equal to the sum of the second weight, the target transaction can be added to the transaction snapshot or re-executed. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption when scheduling target transactions, avoiding resource waste and improving the performance of the blockchain network.

[0182] In one possible implementation, determining a third conflict relationship between the target transaction and at least one third reference transaction can specifically involve: determining a fourth conflict relationship between the target transaction and a fourth reference transaction, wherein the fourth reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction; when the fourth conflict relationship indicates that there is no conflict between the target transaction and the fourth reference transaction, determining a third conflict relationship between the target transaction and at least one third reference transaction.

[0183] The fourth conflict relationship is used to indicate whether there is a conflict between the target transaction and the fourth reference transaction.

[0184] Based on this, in the second scheduling stage, it is necessary to first determine whether there is a conflict between the target transaction and the fourth reference transaction. This is equivalent to determining whether there is a conflict between the target transaction and the blockchain transactions that have been added to the transaction snapshot. If there is a conflict, the target transaction is re-executed. Subsequently, there is no need to determine the relationship between the sum of the first weight and the second weight, which can improve the scheduling efficiency of blockchain transactions and thus improve the execution efficiency of blockchain transactions.

[0185] Specifically, refer to Figure 6 , Figure 6 This is an optional flowchart of the second scheduling stage provided in the embodiments of this application. It requires three judgments in sequence. In the first judgment, it is determined whether there is a conflict between the target transaction and the fourth reference transaction through the fourth conflict relationship. If the judgment is yes, the target transaction is re-executed. Otherwise, a second judgment is performed. In the second judgment, it is determined whether there is a conflict between the target transaction and the third reference transaction through the first conflict relationship. If the judgment is no, the target transaction is re-executed. Otherwise, a third judgment is performed. In the third judgment, it is determined whether the first weight is greater than the sum of the second weights. When the first weight is greater than the sum of the second weights, the target transaction is added to the transaction snapshot. When the first weight is less than the sum of the second weights, the target transaction is re-executed. When the first weight is equal to the sum of the second weights, it is possible to choose to add the target transaction to the transaction snapshot or to choose to re-execute the target transaction. The figure shows the option to re-execute the target transaction.

[0186] When the target transaction is completed, the current transaction quantity in the transaction snapshot is used as the second reference quantity. After a preset time, the target transaction reaches the preset time. When the target transaction reaches the preset time, the current transaction quantity in the transaction snapshot is used as the third reference quantity. The second reference quantity and the third reference quantity are compared. When the second reference quantity and the third reference quantity are the same, it means that the target transaction does not have a fourth reference transaction. Otherwise, the blockchain transaction has a fourth reference transaction.

[0187] Conversely, in another possible implementation, the second scheduling stage may not require determining whether there is a conflict between the target transaction and the fourth reference transaction. Compared to the stage where it is necessary to determine whether there is a conflict between the target transaction and the fourth reference transaction, the scheduling process will take a little more time. However, this time is much less than the time spent re-executing blockchain transactions that consume more resources. Therefore, when scheduling target transactions, it is possible to retain blockchain transactions that consume more resources and re-execute blockchain transactions that consume fewer resources, thereby avoiding resource waste and improving the performance of the blockchain network.

[0188] In one possible implementation, the blockchain transaction scheduling method further includes:

[0189] Whenever a blockchain transaction that was not added to the transaction snapshot is re-executed, the re-executed blockchain transaction that was not added to the transaction snapshot will be used as the target transaction.

[0190] The target transactions are rescheduled until all blockchain transactions have been added to the transaction snapshot.

[0191] One approach is to schedule the target transaction using a nondeterministic scheduling method. In nondeterministic scheduling, the execution result of each blockchain transaction is uncertain. Nondeterministic scheduling is applicable to pessimistic scenarios, where a blockchain transaction can depend on multiple blockchain transactions simultaneously. Nondeterministic scheduling uses the specific execution time of the blockchain transaction as the criterion. In nondeterministic scheduling, the conflict detection time point is configured as follows: whenever a blockchain transaction is completed, a conflict detection is performed on that blockchain transaction to determine the conflict relationship between that blockchain transaction and the other completed blockchain transactions. Therefore, when a blockchain transaction is re-executed, a conflict detection needs to be performed on that blockchain transaction again to determine the conflict relationship between that blockchain transaction and the other completed blockchain transactions. When all blockchain transactions are added to the transaction snapshot, it indicates that the scheduling of the target transaction has been completed.

[0192] Specifically, refer to Figure 7 , Figure 7The embodiment of this application provides an optional flowchart before nondeterministic scheduling optimization. According to the order in which blockchain transactions are completed, the blockchain transaction that is completed first is added to the transaction snapshot, and the remaining blockchain transactions are re-executed. This may cause blockchain transactions that consume more resources to be re-executed, resulting in resource waste and reduced performance of the blockchain network.

[0193] Additionally, refer to Figure 8 , Figure 8 This is an optional flowchart illustrating an optimized nondeterministic scheduling method provided in this application embodiment. In nondeterministic scheduling, whenever a blockchain transaction is completed, conflict detection is performed on that blockchain transaction to determine the conflict relationship between that blockchain transaction and the other completed blockchain transactions. In addition, since a blockchain transaction is allowed to depend on multiple blockchain transactions simultaneously in a pessimistic scenario, when the target transaction is completed, some of the blockchain transactions that the target transaction depends on may not have been completed yet. By setting a preset time and waiting, it is possible to wait for each blockchain transaction that the target transaction depends on to be completed, making the scheduling result of the target transaction more accurate, thereby improving the determinism of the execution result.

[0194] Specifically, six blockchain transactions are executed in parallel: Tx0, Tx1, Tx2, Tx3, Tx4, and Tx5. The execution time for Tx0 is 3 seconds, for Tx1 it is 1 second, for Tx2 it is 2 seconds, for Tx3 it is 4 seconds, for Tx4 it is 2 seconds, and for Tx5 it is 4 seconds. The preset duration is 1 second. Based on the resources required to execute each blockchain transaction, the weights of Tx0, Tx1, Tx2, Tx3, Tx4, and Tx5 are determined to be 30, 10, 20, 40, and 40 respectively.

[0195] When one second has elapsed, Tx1 is completed. Tx1 is then used as the target transaction. In the first scheduling phase, conflict detection is performed to determine that Tx1 does not conflict with other blockchain transactions. Tx1 then enters the second scheduling phase, where it waits for a preset time.

[0196] When two seconds have elapsed, Tx1 reaches its preset duration. In the second scheduling phase, conflict detection confirms that Tx1 does not conflict with other blockchain transactions, and Tx1 is added to the transaction snapshot. Simultaneously, Tx2 is executed and designated as the target transaction. In the first scheduling phase, conflict detection confirms that Tx2 does not conflict with other blockchain transactions, and Tx2 enters the second scheduling phase, where it waits for a preset duration. At the same time, Tx4 is executed and designated as the target transaction. In the first scheduling phase, conflict detection confirms that Tx4 does not conflict with other blockchain transactions, and Tx4 enters the second scheduling phase, where it waits for a preset duration.

[0197] When three seconds have elapsed, Tx0 is completed. Tx0 is then used as the target transaction. In the first scheduling phase, conflict detection is performed. Since both Tx0 and Tx2's read / write sets contain the key k1, and Tx2 has been completed but not added to the transaction snapshot, Tx2 is determined to be the first reference transaction conflicting with Tx1. Based on the weight relationship between Tx0 and Tx2, Tx0 is scheduled. Because Tx0's weight is greater than Tx2's weight, Tx0 enters the second scheduling phase. The system waits for a preset time. Meanwhile, when Tx2 reaches its preset time, conflict detection in the second scheduling phase determines that Tx0 is a third reference transaction that conflicts with Tx2. Based on the weights of Tx2 and Tx0, Tx2 is scheduled. Since the weight of Tx2 is less than that of Tx0, Tx2 is re-executed. At the same time, when Tx4 reaches its preset time, conflict detection in the second scheduling phase determines that Tx4 does not conflict with the other blockchain transactions, and Tx4 is added to the transaction snapshot.

[0198] When four seconds have elapsed, Tx0 reaches its preset duration and passes conflict detection in the second scheduling phase. Since both Tx0 and Tx5's read / write sets contain key k1, and Tx5 has been executed but not added to the transaction snapshot, Tx5 is determined to be a third reference transaction conflicting with Tx0. Based on the weight relationship between Tx0 and Tx5, Tx0 is scheduled. Because Tx0's weight is less than Tx5's, Tx0 is re-executed. Simultaneously, Tx3 completes execution and is designated as the target transaction. Passing conflict detection in the first scheduling phase, Tx3 is then... Since key k2 is present in both the read and write sets of Tx3 and Tx1, and Tx1 has been added to the transaction snapshot, Tx1 is determined to be the second reference transaction that conflicts with Tx3, and Tx3 is re-executed. At the same time, Tx5 is executed and is used as the target transaction. In the first scheduling stage, conflict detection determines that Tx0 is the first reference transaction that conflicts with Tx5. Based on the relationship between the weights of Tx5 and Tx0, Tx5 is scheduled. Since the weight of Tx5 is greater than the weight of Tx0, Tx5 waits for a preset time in the second scheduling stage.

[0199] When five seconds have elapsed, Tx2 is re-executed. Tx2 is then used as the target transaction. In the first scheduling phase, conflict detection identifies Tx5 as the first reference transaction conflicting with Tx2. Based on the weights of Tx2 and Tx5, Tx2 is scheduled. Since Tx2's weight is less than Tx5's, Tx2 is re-executed. Simultaneously, Tx5 reaches its preset duration. In the second scheduling phase, conflict detection identifies Tx2 as the third reference transaction conflicting with Tx5. Based on the weights of Tx5 and Tx2, Tx5 is scheduled. Since Tx5's weight is greater than Tx2's, Tx5 is added to the transaction snapshot.

[0200] When seven seconds have elapsed, Tx0 is re-executed and becomes the target transaction. In the first scheduling phase, conflict detection identifies Tx2 as the first reference transaction conflicting with Tx0. Based on the weights of Tx0 and Tx2, Tx0 is scheduled. Since Tx0's weight is greater than Tx2's, Tx0 enters the second scheduling phase, where it waits for a preset time. Simultaneously, Tx2 is re-executed and becomes the target transaction. In the first scheduling phase, conflict detection identifies Tx0 as the first reference transaction conflicting with Tx2. Based on the weights of Tx2 and Tx0, Tx2 is scheduled. Since Tx2's weight is less than Tx0's, Tx2 is re-executed.

[0201] When eight seconds have elapsed, Tx0 reaches its preset duration. In the second scheduling phase, conflict detection is performed, confirming that Tx0 does not conflict with other blockchain transactions, and Tx0 is added to the transaction snapshot. At the same time, Tx3 is executed and is taken as the target transaction. In the first scheduling phase, conflict detection is performed, confirming that Tx3 does not conflict with other blockchain transactions, and Tx3 enters the second scheduling phase, where it waits for a preset duration.

[0202] When nine seconds have elapsed, Tx2 is executed. Tx2 is then used as the target transaction. In the first scheduling phase, conflict detection confirms that Tx2 does not conflict with other blockchain transactions, and Tx2 enters the second scheduling phase, where it waits for a preset time. Simultaneously, Tx3 reaches its preset time. In the second scheduling phase, conflict detection confirms that Tx3 does not conflict with other blockchain transactions, and Tx3 is added to the transaction snapshot. When ten seconds have elapsed, Tx2 reaches its preset time. In the second scheduling phase, conflict detection confirms that Tx2 does not conflict with other blockchain transactions, and Tx2 is added to the transaction snapshot.

[0203] As can be seen, compared to the total execution time of 12 seconds before nondeterministic scheduling optimization, the total execution time after nondeterministic scheduling optimization for pessimistic scenarios is 10 seconds, a reduction of two seconds, and the execution efficiency is improved by nearly 17%. The significantly improved execution efficiency enables the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption, avoiding resource waste and improving the performance of the blockchain network.

[0204] In addition, based on the scheduling results of the target transactions, a directed acyclic graph (DAG) of transactions is constructed. The DAG and each blockchain transaction are packaged together to obtain a proposal block carrying the DAG. The proposal block is then sent to the verification nodes in the blockchain network, and the verification nodes can execute the blockchain transactions in the proposal block based on the DAG.

[0205] In one possible implementation, the extended time can be further optimized. For example, the preset duration can be optimized block by block. The block with the highest block height in the blockchain is taken as the initial block, and an initial preset duration is set for the initial block. The corresponding blockchain transactions are scheduled according to the initial preset duration, and then executed. The total execution time is determined, and the preset duration is optimized based on the total execution time. In the next block after the initial block, the corresponding blockchain transactions are scheduled according to the optimized preset duration, and then executed. The preset duration can be optimized again based on the total execution time. Therefore, the preset duration can be continuously optimized to obtain a better preset duration, which can effectively improve execution efficiency. The optimization of the preset duration can be either extending or shortening the preset duration, depending on the actual situation.

[0206] Alternatively, the preset duration can be optimized through simulation training. The block with the highest block height in the blockchain is used as the initial block, and a preset duration is set for it. Then, a batch of blockchain transactions are selected from the transaction pool as sample transactions. Based on the initial block, the corresponding sample transactions are scheduled according to the initial preset duration, executed, and the total execution time is determined. Based on the total execution time, an optimized preset duration is determined. Then, based on the initial block again, the corresponding sample transactions are scheduled according to the optimized preset duration, executed, and the total execution time is determined. The preset duration can be optimized again using the total execution time. Therefore, the preset duration can be continuously optimized to obtain a better preset duration, effectively improving execution efficiency.

[0207] In one possible implementation, the target transaction is acquired whenever one of the blockchain transactions is executed. A first reference transaction has been added to the transaction snapshot. The target transaction is scheduled according to the relationship between a first weight and the sum of first weights. Specifically, this could be as follows:

[0208] When the first weight is greater than the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction;

[0209] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0210] Alternatively, when the first weight equals the sum of the first weights, replace the first reference transaction in the transaction snapshot with the target transaction or re-execute the target transaction.

[0211] Based on this, the scheduling method provided in this application embodiment can also optimize the nondeterministic scheduling in optimistic scenarios. In optimistic scenarios, the number of blockchain transactions that a blockchain exchange depends on is less than or equal to one. When conflicting blockchain transactions are executed serially, each blockchain transaction depends only on the previous blockchain transaction and will not depend on multiple blockchain transactions at the same time. Exchanging the execution order of blockchain transactions will not affect the final execution result. Therefore, conflicting transaction replacement is allowed in optimistic scenarios. Specifically, when a blockchain transaction is completed, if there is no conflicting transaction in the transaction snapshot, the blockchain transaction can be temporarily added to the transaction snapshot. Alternatively, if there is a conflicting transaction in the transaction snapshot, and replacement is required, the conflicting transaction in the transaction snapshot can be replaced by the blockchain transaction, and the conflicting transaction can be re-executed. Therefore, in optimistic scenarios, the first reference transaction is the blockchain transaction that has been added to the transaction snapshot.

[0212] When a target transaction is completed, conflicting target transactions and first reference transactions are scheduled. First, the first weight of the target transaction and the second weight of the first reference transaction are obtained. There can be one or more first reference transactions. Therefore, based on the number of first reference transactions, different scheduling scenarios can be identified, as follows:

[0213] Scheduling Situation 21: The number of first reference transactions is one. The first weight sum is the second weight of the first reference transaction. Since both the first weight and the second weight are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the first weight sum is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain exchange. The first weight is used to indicate the resources required to execute the target exchange, and the second weight is used to indicate the resources required to execute the first reference exchange. When the resources required to execute the target exchange are small, the first weight is small, and vice versa. Similarly, when the resources required to execute the first reference exchange are small, the first weight sum is small, and vice versa.

[0214] Specifically, when multiple blockchain transactions that process state data corresponding to the same key are executed in parallel, and the completion times of each blockchain transaction do not overlap, the first completed blockchain transaction is temporarily added to the transaction snapshot. Subsequent completed blockchain transactions are compared in weight with the blockchain transactions in the transaction snapshot, and a decision is made based on the weight comparison result to determine whether replacement is needed. If the completion times of some blockchain transactions overlap, the blockchain transaction that performs conflict detection first will not consider the later-performed conflict detection transactions as conflicting transactions. For example, when two blockchain transactions are executed in parallel and complete simultaneously, one of the blockchain transactions... As a target transaction, conflict detection is performed on it. Since another blockchain transaction will not be considered a conflicting transaction, the blockchain transaction that has undergone conflict detection is temporarily added to the transaction snapshot, which is equivalent to having zero first reference transactions. Then, another blockchain transaction is used as the target transaction, and conflict detection is performed on it. The other blockchain transaction is compared with the blockchain transaction in the transaction snapshot in terms of weight. Based on the weight comparison result, it is determined whether to replace it, which is equivalent to having one first reference transaction. Similarly, if the execution time of three or more blockchain transactions overlaps, only the blockchain transaction that has been added to the transaction snapshot will be used as the first reference transaction.

[0215] In addition, based on the scheduling results of the target transactions, a directed acyclic graph (DAG) of transactions is constructed. The DAG and each blockchain transaction are packaged together to obtain a proposal block carrying the DAG. The proposal block is then sent to the verification nodes in the blockchain network, and the verification nodes can execute the blockchain transactions in the proposal block based on the DAG.

[0216] Scheduling Situation 22: There are multiple first reference transactions, all of which have been added to the transaction snapshot. All first reference transactions can be used as the third reference set. The second weights of all first reference transactions need to be summed, which is equivalent to obtaining the sum of the first weights of the third reference set. Since both the first and second weights are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weights and the sum of the first weights is equivalent to scheduling the target transaction according to the resource consumption parameters. The resource consumption parameters are used to indicate the resources required to execute the blockchain exchange. The first weight is used to indicate the resources required to execute the target exchange, and the second weight is used to indicate the resources required to execute the first reference exchange. When the resources required to execute the target exchange are small, the first weight is small, and vice versa. Similarly, when the resources required to execute all first reference exchanges in the third reference set are small, the sum of the first weights is small, and vice versa.

[0217] Furthermore, due to system scheduling, not all transactions can start in complete parallel. System scheduling refers to the operating system's scheduling of the program. In this case, when a later-executed blockchain transaction is completed, all the first reference transactions that were executed earlier and have been completed can be used as the objects of weight comparison. The sum of the first weights of all second weights is calculated. By comparing the first weight with the sum of the first weights, it is possible to effectively determine whether the resource consumption of executing the target transaction is greater than the resource consumption corresponding to executing all the first reference transactions that were executed earlier and have been completed. Thus, blockchain transactions with higher resource consumption are retained, and blockchain transactions with lower resource consumption are re-executed, avoiding resource waste and improving the performance of the blockchain network.

[0218] Specifically, refer to Figure 9 , Figure 9This is an alternative flowchart of nondeterministic scheduling optimization provided in the embodiments of this application. Three blockchain transactions are executed in parallel: Tx0, Tx1, and Tx2. The execution time of Tx0 is 3 seconds, the execution time of Tx1 is 1 second, and the execution time of Tx2 is 2 seconds. Based on the resources required to execute each blockchain transaction, the weight of Tx0 is determined to be 25, the weight of Tx1 is 10, and the weight of Tx2 is 20.

[0219] When one second has elapsed, Tx1 is executed. Tx1 is then used as the target transaction. Through conflict detection, it is determined that Tx1 does not conflict with other blockchain transactions, and Tx1 is added to the transaction snapshot. At the same time, due to system scheduling reasons, Tx0 begins execution.

[0220] When two seconds have elapsed, Tx2 is executed. Tx2 is then used as the target transaction. Through conflict detection, it is determined that Tx1 is the first reference transaction that conflicts with Tx2. Based on the relationship between the weights of Tx1 and Tx2, Tx2 is scheduled. Since the weight of Tx2 is greater than the weight of Tx1, Tx2 replaces Tx1 in the transaction snapshot. This is equivalent to adding Tx2 to the transaction snapshot and re-executing Tx1.

[0221] When three seconds have elapsed, Tx1 is re-executed. Tx1 is then used as the target transaction. Through conflict detection, it is determined that Tx1 does not conflict with other blockchain transactions, and Tx1 is added to the transaction snapshot.

[0222] When four seconds have elapsed, Tx0 is executed. Using Tx0 as the target transaction, conflict detection identifies Tx1 and Tx2 as first reference transactions that conflict with Tx0. Since Tx1 and Tx2 do not conflict with each other, they are used as the third reference set. The total weight of the third reference set is calculated to be 30. Based on the relationship between the weight of Tx0 and the total weight, Tx0 is scheduled. Because the weight of Tx0 is less than the total weight, Tx0 is re-executed. This process preserves resource-intensive blockchain transactions and re-executes less resource-intensive ones, avoiding resource waste and improving the performance of the blockchain network.

[0223] Among them, for the three comparison scenarios of the first weight and the sum of the first weights, if the first weight is greater than the sum of the first weights, the target transaction is retained and the target transaction replaces the first reference transaction. This is equivalent to temporarily adding the target transaction to the transaction snapshot and re-executing the first reference transaction. If the first weight is less than the sum of the first weights, the target transaction is re-executed. If the first weight is equal to the sum of the first weights, the target transaction can replace the first reference transaction or re-executing the first reference transaction. In this way, when scheduling target transactions, it is possible to retain blockchain transactions with higher resource consumption and re-execute blockchain transactions with lower resource consumption, thereby avoiding resource waste and improving the performance of the blockchain network.

[0224] In one possible implementation, the blockchain transaction scheduling method further includes:

[0225] Re-execute the first reference transaction that was replaced in the transaction snapshot;

[0226] Whenever the first reference transaction that was replaced is re-executed, the re-executed first reference transaction will be used as the target transaction.

[0227] The target transactions are rescheduled until all blockchain transactions have been added to the transaction snapshot.

[0228] One approach is to schedule the target transaction using a nondeterministic scheduling method. In nondeterministic scheduling, the execution result of each blockchain transaction is uncertain. Nondeterministic scheduling uses the specific execution time of the blockchain transaction as the judgment criterion. Nondeterministic scheduling can be applied to optimistic scenarios, allowing conflicting transactions to be replaced. In nondeterministic scheduling, the conflict detection time point is configured as follows: whenever a blockchain transaction is completed, a conflict detection is performed on that blockchain transaction to determine the conflict relationship between that blockchain transaction and the other completed blockchain transactions. Therefore, when a blockchain transaction is re-executed, a conflict detection needs to be performed on it again. For example, when the first reference transaction is re-executed, the re-executed first reference transaction is taken as the target transaction, and the conflict relationship between the target transaction and the other completed blockchain transactions is re-determined. When all blockchain transactions are added to the transaction snapshot, it indicates that the scheduling of the target transaction has been completed.

[0229] Specifically, refer to Figure 10 , Figure 10This is an alternative flowchart illustrating the optimized nondeterministic scheduling provided in the embodiments of this application. In nondeterministic scheduling, whenever a blockchain transaction is completed, a conflict detection is performed on the blockchain transaction to determine the conflict relationship between the blockchain transaction and the other completed blockchain transactions. In addition, in an optimistic scenario, conflicting transactions are allowed to be replaced.

[0230] Specifically, six blockchain transactions are executed in parallel: Tx0, Tx1, Tx2, Tx3, Tx4, and Tx5. The execution time of Tx0 is 3 seconds, Tx1 is 1 second, Tx2 is 2 seconds, Tx3 is 4 seconds, Tx4 is 2 seconds, and Tx5 is 4 seconds. Based on the resources required to execute each blockchain transaction, the weights of Tx0, Tx1, Tx2, Tx3, Tx4, and Tx5 are determined to be 30, 10, 20, 40, and 40 respectively.

[0231] When one second has elapsed, Tx1 is executed. Tx1 is then used as the target transaction. Through conflict detection, it is determined that Tx1 does not conflict with other blockchain transactions, and Tx1 is added to the transaction snapshot.

[0232] When two seconds have elapsed, Tx2 is executed and set as the target transaction. Through conflict detection, it is determined that Tx2 does not conflict with other blockchain transactions, and Tx2 is added to the transaction snapshot. At the same time, Tx4 is executed and set as the target transaction. Through conflict detection, it is determined that Tx4 does not conflict with other blockchain transactions, and Tx4 is added to the transaction snapshot.

[0233] When three seconds have elapsed, Tx0 is executed. Tx0 is then used as the target transaction. Through conflict detection, Tx2 is identified as the first reference transaction that conflicts with Tx0. Based on the weight relationship between Tx0 and Tx2, Tx0 is scheduled. Since the weight of Tx0 is greater than the weight of Tx2, Tx0 replaces Tx2 in the transaction snapshot. This is equivalent to adding Tx0 to the transaction snapshot and re-executing Tx2.

[0234] When four seconds have elapsed, Tx3 is executed and becomes the target transaction. Conflict detection identifies Tx1 as the first reference transaction conflicting with Tx3. Based on the weights of Tx3 and Tx1, Tx3 is scheduled. Since Tx3 has a greater weight than Tx1, Tx3 replaces Tx1 in the transaction snapshot, effectively adding Tx3 to the snapshot, and Tx1 is re-executed. Simultaneously, Tx5 is executed and becomes the target transaction. Conflict detection identifies Tx0 as the first reference transaction conflicting with Tx5. Based on the weights of Tx5 and Tx0, Tx5 is scheduled. Since Tx5 has a greater weight than Tx0, Tx5 replaces Tx0 in the transaction snapshot, effectively adding Tx5 to the snapshot, and Tx0 is re-executed.

[0235] When five seconds have elapsed, Tx1 is executed and becomes the target transaction. Conflict detection determines that Tx1 does not conflict with other blockchain transactions, and Tx1 is added to the transaction snapshot. Simultaneously, Tx2 is executed and becomes the target transaction. Conflict detection determines that Tx5 is the first reference transaction that conflicts with Tx2. Based on the weights of Tx2 and Tx5, Tx2 is scheduled. Since the weight of Tx2 is less than that of Tx5, Tx2 is re-executed.

[0236] When seven seconds have elapsed, Tx0 is executed and becomes the target transaction. Conflict detection determines that Tx0 does not conflict with other blockchain transactions, and Tx0 is added to the transaction snapshot. Simultaneously, Tx2 is executed and becomes the target transaction. Conflict detection determines that Tx0 is the first reference transaction that conflicts with Tx2. Based on the weight of Tx2 and Tx0, Tx2 is scheduled. Since the weight of Tx2 is less than that of Tx0, Tx2 is re-executed.

[0237] When nine seconds have elapsed, Tx2 is executed. Tx2 is then used as the target transaction. Through conflict detection, it is determined that Tx2 does not conflict with other blockchain transactions, and Tx2 is added to the transaction snapshot.

[0238] Refer again Figure 7 As can be seen, compared to the total execution time of 12 seconds before the nondeterministic scheduling optimization, the total execution time after the nondeterministic scheduling optimization for the optimistic scenario is 9 seconds, a reduction of 3 seconds, and the execution efficiency is improved by 25%, which is a significant improvement in execution efficiency.

[0239] In one possible implementation, the resource consumption parameters include at least one of the following: the transaction execution time of the blockchain transaction, the number of read set keys of the blockchain transaction, the read set memory size of the blockchain transaction, the number of write set keys of the blockchain transaction, and the write set memory size of the blockchain transaction. The first weight can be determined through the following steps:

[0240] Determine the score corresponding to at least one of the following for the target transaction: transaction execution time, number of read set keys, read set memory size, number of write set keys, and write set memory size;

[0241] The first weight is determined by at least one score.

[0242] Among them, the resource consumption parameter is used to indicate the resources required to execute a blockchain transaction. Therefore, the first weight is used to indicate the resources required to execute the target transaction. The resources required to execute a blockchain transaction can be time resources, memory resources, etc.

[0243] For the requesting party, the transaction execution time is a very sensitive factor regarding the time resources consumed in executing a blockchain transaction. It can be determined by the transaction execution time of the blockchain transaction. Therefore, the resource consumption parameter can be the transaction execution time.

[0244] Furthermore, regarding the memory resources consumed in executing blockchain transactions, the information of the read and write sets involved is an important factor in assessing resource consumption for the transaction executor. It can be determined by at least one of the following: the number of read set keys, the size of the read set memory, the number of write set keys, and the size of the write set memory, for the following reasons:

[0245] State data can be stored in key-value pairs. During the execution of a blockchain transaction, a read set and a write set are created for that transaction. The read set indicates the state data read by the blockchain transaction, and therefore includes the key of the read state data, the commit version number corresponding to the key, and the value corresponding to the key. The write set indicates the state data inserted, deleted, or updated by the blockchain transaction, and therefore includes the key of the written state data and the value corresponding to the key. The number of keys in the read set refers to the number of keys contained in the read set, and the number of keys in the write set refers to the number of keys contained in the write set. The memory size of the read set refers to the total memory occupied by each piece of data in the read set, and the memory size of the write set refers to the total memory occupied by each piece of data in the write set. It is evident that creating both read and write sets consumes memory space. The more keys a read set contains, the more memory resources it typically consumes; the more keys a write set contains, the more memory resources it typically consumes; the larger the total memory occupied by each piece of data in the read set, the more memory resources it consumes; and the larger the total memory occupied by each piece of data in the write set, the more memory resources it consumes.

[0246] Therefore, the memory resources consumed in executing a blockchain transaction can be determined by at least one of the following: the number of read set keys, the read set memory size, the number of write set keys, and the write set memory size. Thus, the resource consumption parameters can be the number of read set keys, the read set memory size, the write set keys, and the write set memory size.

[0247] It is understood that other parameters for indicating the resources required to execute a blockchain transaction can be selected as resource consumption parameters according to the actual situation, and this application embodiment does not limit them.

[0248] Specifically, when using multiple types of resource consumption parameters to determine the first weight, in order to facilitate calculation, it is necessary to standardize the values ​​of each resource consumption parameter. Therefore, the first weight can be obtained by first calculating the score corresponding to each resource consumption parameter and then summing the scores.

[0249] In one possible implementation, since different resource consumption parameters have different degrees of influence on the evaluation of resource consumption, corresponding upper limits for the scores of each resource consumption parameter can be set.

[0250] For example, the upper limit of the score corresponding to each resource consumption parameter is shown in Table 1 below:

[0251] Table 1

[0252] 100 Transaction execution time 50 Number of read set keys 70 Read set memory size 20 Number of write set keys 30 Write set memory size

[0253] As shown in Table 1, corresponding upper limits for scores are set according to the degree of influence of each resource consumption parameter on the evaluation of resource consumption. For example, the transaction execution time has the greatest influence on the evaluation of resource consumption, so the upper limit for the score corresponding to the transaction execution time is the largest. Then, based on the upper limit of the score of the resource consumption parameter and the actual parameter value, the score corresponding to the resource consumption parameter can be determined.

[0254] Taking transaction execution time as an example, the maximum score corresponding to the transaction execution time is 100 points. By setting multiple time thresholds, 100 points are divided into multiple score ranges. For example, the time thresholds can be set to 1 second, 2 seconds, 3 seconds, 4 seconds, and 5 seconds. When the transaction execution time is less than 1 second, the score corresponding to the transaction execution time is 100 points. When the transaction execution time is between 1 and 2 seconds, the score corresponding to the transaction execution time is in the score range of 80 to 100 points. When the transaction execution time is between 2 and 3 seconds, the score corresponding to the transaction execution time is in the score range of 50 to 80 points. Within the specified range, when the transaction execution time is between 3 and 4 seconds, the score corresponding to the transaction execution time is between 20 and 50 points; when the transaction execution time is between 4 and 5 seconds, the score corresponding to the transaction execution time is between 0 and 20 points; and when the transaction execution time is greater than 5 seconds, the score corresponding to the transaction execution time is 0 points. Within the score range, the actual score can be determined according to the linear relationship between the score and the transaction execution time. Similarly, the scores corresponding to other resource consumption parameters can be calculated, and then all scores are added together to obtain the first weight.

[0255] It is understood that the upper limit of the score corresponding to the resource consumption parameter can be set to other values ​​according to the actual situation, and this application embodiment does not limit it.

[0256] In another possible implementation, the same upper limit for the score can be set for each resource consumption parameter, for example, the upper limit for the score can be set to 100 points. Taking transaction execution time as an example again, the actual score of transaction execution time can be determined according to the above score determination method. According to the same principle, the score corresponding to other resource consumption parameters can be determined. Since different resource consumption parameters have different degrees of influence on the evaluation of resource consumption, corresponding weight values ​​can be set for the score corresponding to different resource consumption parameters according to the degree of influence of each resource consumption parameter on the evaluation of resource consumption. Then, based on the corresponding weight values, the score corresponding to each resource consumption parameter is weighted, and then all weighted scores are added together to obtain the first weight.

[0257] Reference Figure 11 , Figure 11This is a schematic diagram of an optional block verification process between nodes provided in an embodiment of this application. The blockchain network includes block-producing nodes and verification nodes. There can be multiple verification nodes. Multiple blockchain transactions, such as Tx0, Tx1, Tx2, Tx3, Tx4, and Tx5, are executed in parallel using multi-threaded methods by the block-producing nodes. The completed blockchain transactions are used as target transactions. When scheduling conflicting target transactions and first reference transactions, a first weight of the target transaction and a second weight of the first reference transaction are first obtained. Since both the first and second weights are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first and second weights is equivalent to scheduling the target transaction according to the resource consumption parameters. This allows for the scheduling of the target transaction based on the resource consumption parameters. When scheduling target transactions, the system retains blockchain transactions that consume more resources and re-executes those that consume fewer resources, thus avoiding resource waste and improving the performance of the blockchain network. Based on the scheduling results of the target transactions, a directed acyclic graph (DAG) of transactions is constructed. The DAG and each blockchain transaction are packaged together to obtain a proposal block carrying the DAG. The proposal block also contains the final world state determined based on the execution results of the blockchain transactions. The block-producing node sends the proposal block to each verification node. The verification node can execute the blockchain transactions in the proposal block based on the DAG to obtain a reference world state. The reference state is compared with the final state. If the reference world state is the same as the final world state, the verification of the proposal block is successful; otherwise, the verification fails.

[0258] It is understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated in this embodiment, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0259] Reference Figure 12 , Figure 12 This is a schematic diagram of an optional structure of a blockchain transaction scheduling device provided in an embodiment of this application. The blockchain transaction scheduling device 1200 includes:

[0260] The execution module 1201 is used to acquire multiple blockchain transactions to be executed and execute each blockchain transaction.

[0261] The conflict detection module 1202 is used to obtain the target transaction that has been executed from multiple blockchain transactions, and determine the first conflict relationship between the target transaction and at least one first reference transaction, wherein the first reference transaction is a blockchain transaction that has been executed other than the target transaction.

[0262] The weight acquisition module 1203 is used to acquire a first weight of the target transaction and a second weight of the first reference transaction when the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction. The first weight is determined based on the resource consumption parameters of executing the target transaction, and the second weight is determined based on the resource consumption parameters of executing the first reference transaction.

[0263] The first scheduling module 1204 is used to schedule the target transaction according to the relationship between the first weight and the second weight.

[0264] Furthermore, the aforementioned first scheduling module 1204 is specifically used for:

[0265] The target transaction is scheduled according to the relationship between the first weight and each of the second weights;

[0266] Alternatively, calculate the sum of the first weights for all second weights, and schedule the target transaction based on the relationship between the first weights and the sum of the first weights.

[0267] Furthermore, the target transaction is obtained after all blockchain transactions have been executed, and the first reference transaction is not added to the transaction snapshot. The aforementioned first scheduling module 1204 is specifically used for:

[0268] When the first weight is greater than each of the second weights, the target transaction is added to the transaction snapshot;

[0269] Alternatively, if the first weight is less than any of the second weights, the target transaction is re-executed;

[0270] Alternatively, when the first weight is equal to at least one second weight and the first weight is greater than the remaining second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0271] Furthermore, the aforementioned first scheduling module 1204 is specifically used for:

[0272] The target transaction, along with a first reference transaction with an equal weight to the target transaction, is defined as the first transaction set.

[0273] Add one of the blockchain transactions from the transaction set to the transaction snapshot, and re-execute the remaining blockchain transactions in the transaction set.

[0274] Furthermore, refer to Figure 12 , Figure 12This is another optional structural diagram of the blockchain transaction scheduling device provided in the embodiments of this application. The blockchain transaction scheduling device 1200 further includes:

[0275] The second scheduling module 1205 is used to schedule the blockchain transactions that have been re-executed but not added to the transaction snapshot as target transactions whenever all blockchain transactions that have not been added to the transaction snapshot have been re-executed; and to schedule the target transactions again until all blockchain transactions have been added to the transaction snapshot.

[0276] Furthermore, the target transaction is obtained whenever one of the blockchain transactions is completed; the first reference transaction is not added to the transaction snapshot. The aforementioned first scheduling module 1204 is specifically used for:

[0277] When the first weight is greater than the sum of the first weights, wait for a preset time, and then schedule the target transaction after the preset time has been reached.

[0278] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0279] Alternatively, when the first weight equals the sum of the first weights, wait for a preset time and then schedule or re-execute the target transaction after the preset time has elapsed.

[0280] Furthermore, the aforementioned conflict detection module 1202 is specifically used for:

[0281] Determine a second conflict relationship between the target transaction and the second reference transaction, wherein the second reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction;

[0282] When a second conflict relationship indicates that there is no conflict between the target transaction and the second reference transaction, a first conflict relationship is determined between the target transaction and at least one first reference transaction.

[0283] Furthermore, the aforementioned first scheduling module 1204 is specifically used for:

[0284] After a preset time period is reached, a third conflict relationship is determined between the target transaction and at least one third reference transaction, wherein the third reference transaction is a blockchain transaction that has been executed and has not been added to the transaction snapshot, other than the target transaction.

[0285] When a third conflict relationship indicates that there is a conflict between the target transaction and the third reference transaction, the third weight of the third reference transaction is obtained, wherein the third weight is determined based on the resource consumption parameters of executing the third reference transaction;

[0286] Calculate the sum of the second weights of all third weights, and schedule the target transaction according to the relationship between the sum of the first weights and the sum of the second weights.

[0287] Furthermore, the aforementioned first scheduling module 1204 is specifically used for:

[0288] When the sum of the first weights is greater than the sum of the second weights, the target transaction is added to the transaction snapshot;

[0289] Alternatively, if the sum of the first weights is less than the sum of the second weights, the target transaction is re-executed;

[0290] Alternatively, when the first weight equals the sum of the second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

[0291] Furthermore, the aforementioned first scheduling module 1204 is specifically used for:

[0292] Determine the fourth conflict relationship between the target transaction and the fourth reference transaction, wherein the fourth reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction;

[0293] When the fourth conflict relationship indicates that there is no conflict between the target transaction and the fourth reference transaction, a third conflict relationship is determined between the target transaction and at least one third reference transaction.

[0294] Furthermore, refer to Figure 14 , Figure 14 This is another optional structural diagram of the blockchain transaction scheduling device provided in the embodiments of this application. The blockchain transaction scheduling device 1200 further includes:

[0295] The third scheduling module 1206 is used to select any blockchain transaction that has not been added to the transaction snapshot as the target transaction whenever it is re-executed; and to schedule the target transaction again until all blockchain transactions are added to the transaction snapshot.

[0296] Furthermore, the target transaction is obtained whenever one of the blockchain transactions is completed, and the first reference transaction has been added to the transaction snapshot. The aforementioned first scheduling module 1204 is specifically used for:

[0297] When the first weight is greater than the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction;

[0298] Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed;

[0299] Alternatively, when the first weight equals the sum of the first weights, replace the first reference transaction in the transaction snapshot with the target transaction or re-execute the target transaction.

[0300] Furthermore, refer to Figure 15 , Figure 15 This is another optional structural diagram of the blockchain transaction scheduling device provided in the embodiments of this application. The blockchain transaction scheduling device 1200 further includes:

[0301] The fourth scheduling module 1207 is used to re-execute the first reference transaction that was replaced in the transaction snapshot; whenever the first reference transaction that was replaced is re-executed, the re-executed first reference transaction is used as the target transaction; the target transaction is scheduled again until all blockchain transactions are added to the transaction snapshot.

[0302] Furthermore, the resource consumption parameters include at least one of the following: the transaction execution time of the blockchain transaction, the number of read set keys of the blockchain transaction, the read set memory size of the blockchain transaction, the number of write set keys of the blockchain transaction, and the write set memory size of the blockchain transaction. The aforementioned weight acquisition module 1203 is specifically used for:

[0303] Determine the score corresponding to at least one of the following for the target transaction: transaction execution time, number of read set keys, read set memory size, number of write set keys, and write set memory size;

[0304] The first weight is determined by at least one score.

[0305] The aforementioned blockchain transaction scheduling device 1200 and blockchain transaction scheduling method are based on the same inventive concept. By executing multiple blockchain transactions, the completed blockchain transactions are used as target transactions. When scheduling conflicting target transactions and first reference transactions, the first weight of the target transaction and the second weight of the first reference transaction are first obtained. Since both the first weight and the second weight are determined based on resource consumption parameters, scheduling the target transaction according to the relationship between the first weight and the second weight is equivalent to scheduling the target transaction according to the resource consumption parameters. This allows for the retention of blockchain transactions with higher resource consumption and the re-execution of blockchain transactions with lower resource consumption when scheduling target transactions, thus avoiding resource waste and improving the performance of the blockchain network.

[0306] The electronic device provided in this application embodiment for executing the scheduling method of the above-described blockchain transaction can be a terminal, referring to... Figure 16 , Figure 16This is a partial structural block diagram of a terminal provided in an embodiment of this application. The terminal includes: a camera assembly 1610, a memory 1620, an input unit 1630, a display unit 1640, a sensor 1650, an audio circuit 1660, a wireless fidelity (WiFi) module 1670, a processor 1680, and a power supply 1690, among other components. Those skilled in the art will understand that... Figure 16 The terminal structure shown does not constitute a limitation on the terminal and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0307] The camera assembly 1610 can be used to capture images or videos. Optionally, the camera assembly 1610 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the terminal, and the rear-facing camera is located on the back of the terminal. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions.

[0308] The memory 1620 can be used to store software programs and modules. The processor 1680 executes various terminal functions and data processing by running the software programs and modules stored in the memory 1620.

[0309] The input unit 1630 can be used to receive input numeric or character information, and to generate key signal inputs related to the terminal's settings and function control. Specifically, the input unit 1630 may include a touch panel 1631 and other input devices 1632.

[0310] The display unit 1640 can be used to display input or provided information, as well as various menus of the terminal. The display unit 1640 may include a display panel 1641.

[0311] Audio circuitry 1660, speaker 1661, and microphone 1662 provide an audio interface.

[0312] The power source 1690 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery.

[0313] The number of sensors 1650 can be one or more, and these sensors 1650 include, but are not limited to: accelerometers, gyroscopes, pressure sensors, optical sensors, etc.

[0314] An accelerometer can detect the magnitude of acceleration along the three axes of a coordinate system established by the terminal. For example, an accelerometer can be used to detect the components of gravitational acceleration along the three axes. The processor 1680 can control the display unit 1640 to display the user interface in either a landscape or portrait view based on the gravitational acceleration signal acquired by the accelerometer. The accelerometer can also be used for games or to collect user motion data.

[0315] The gyroscope sensor can detect the terminal's orientation and rotation angle. It can work in conjunction with an accelerometer to capture the user's 3D movements on the terminal. Based on the data collected by the gyroscope sensor, the processor 1680 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0316] The pressure sensor can be installed on the side bezel of the terminal and / or on the lower layer of the display unit 1640. When the pressure sensor is installed on the side bezel of the terminal, it can detect the user's grip signal on the terminal, and the processor 1680 can perform left / right hand recognition or quick operation based on the grip signal collected by the pressure sensor. When the pressure sensor is installed on the lower layer of the display unit 1640, the processor 1680 can control the operable controls on the UI interface based on the user's pressure operation on the display unit 1640. The operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0317] An optical sensor is used to collect ambient light intensity. In one embodiment, the processor 1680 can control the display brightness of the display unit 1640 based on the ambient light intensity collected by the optical sensor. Specifically, when the ambient light intensity is high, the display brightness of the display unit 1640 is increased; when the ambient light intensity is low, the display brightness of the display unit 1640 is decreased. In another embodiment, the processor 1680 can also dynamically adjust the shooting parameters of the camera assembly 1610 based on the ambient light intensity collected by the optical sensor.

[0318] In this embodiment, the processor 1680 included in the terminal can execute the blockchain transaction scheduling method of the previous embodiment.

[0319] The electronic device provided in this application embodiment for executing the scheduling method of the above-described blockchain transactions can also be a server, see reference. Figure 17 , Figure 17The diagram illustrates a partial structural block of a server provided in this application embodiment. The server 1700 can vary significantly due to different configurations or performance characteristics. It may include one or more Central Processing Units (CPUs) 1722 (e.g., one or more processors) and a memory 1732, and one or more storage media 1730 (e.g., one or more mass storage devices) for storing application programs 1742 or data 1744. The memory 1732 and storage media 1730 may be temporary or persistent storage. The program stored in the storage media 1730 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server 1700. Furthermore, the CPU 1722 may be configured to communicate with the storage media 1730 and execute the series of instruction operations in the storage media 1730 on the server 1700.

[0320] Server 1700 may also include one or more power supplies 1726, one or more wired or wireless network interfaces 1750, one or more input / output interfaces 1758, and / or one or more operating systems 1741, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0321] The processor in server 1700 can be used to schedule blockchain transactions.

[0322] This application also provides a computer-readable storage medium for storing program code, which is used to execute the blockchain transaction scheduling method of the foregoing embodiments.

[0323] This application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the aforementioned blockchain transaction scheduling method.

[0324] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatuses.

[0325] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0326] It should be understood that in the description of the embodiments of this application, "multiple" means two or more, "greater than", "less than", "exceeding" etc. are understood to exclude the number itself, and "above", "below", "within" etc. are understood to include the number itself.

[0327] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0328] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0329] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0330] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0331] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0332] The above provides a detailed description of the preferred embodiments of this application. However, this application is not limited to the above-described embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for scheduling blockchain transactions, characterized in that, include: Obtain multiple blockchain transactions to be executed, and execute each of the blockchain transactions; A target transaction that has been executed is obtained from a plurality of blockchain transactions, and a first conflict relationship is determined between the target transaction and at least one first reference transaction, wherein the first reference transaction is a blockchain transaction that has been executed and is currently completed other than the target transaction, the target transaction is obtained when all blockchain transactions have been executed and the first reference transaction is not added to the transaction snapshot; When the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction, a first weight of the target transaction and a second weight of the first reference transaction are obtained. The first weight is determined based on the resource consumption parameters for executing the target transaction, and the second weight is determined based on the resource consumption parameters for executing the first reference transaction. The resource consumption parameters include at least one of the following: transaction execution time of the blockchain transaction, number of read keys of the blockchain transaction, read set memory size of the blockchain transaction, number of write keys of the blockchain transaction, and write set memory size of the blockchain transaction. The first weight is positively correlated with the resources required to execute the target transaction, and the second weight is positively correlated with the resources required to execute the first reference transaction. When the first weight is greater than each of the second weights, the target transaction is added to the transaction snapshot; Alternatively, if the first weight is less than any of the second weights, the target transaction is re-executed; Alternatively, when the first weight is equal to at least one of the second weights, and the first weight is greater than the remaining second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed. Alternatively, the sum of the first weights of all the second weights can be calculated, and the target transaction can be scheduled according to the relationship between the first weights and the sum of the first weights.

2. The blockchain transaction scheduling method according to claim 1, characterized in that, Adding the target transaction to the transaction snapshot or re-executing the target transaction includes: The target transaction, and the first reference transaction with the same weight as the target transaction, are used as the first transaction set; Add one of the blockchain transactions in the transaction set to the transaction snapshot, and re-execute the remaining blockchain transactions in the transaction set.

3. The blockchain transaction scheduling method according to claim 2, characterized in that, The scheduling method further includes: Whenever all blockchain transactions that were not added to the transaction snapshot are re-executed, the blockchain transactions that were re-executed but not added to the transaction snapshot will be used as the target transaction. The target transaction is rescheduled until all the blockchain transactions have been added to the transaction snapshot.

4. The blockchain transaction scheduling method according to claim 1, characterized in that, The target transaction is obtained whenever one of the blockchain transactions is completed. The first reference transaction is not added to the transaction snapshot. The scheduling of the target transaction based on the relationship between the first weight and the sum of the first weights includes: When the first weight is greater than the sum of the first weights, wait for a preset time, and then schedule the target transaction after the preset time has elapsed. Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed; Alternatively, when the first weight equals the sum of the first weights, wait for a preset time and, after the preset time is reached, schedule or re-execute the target transaction.

5. The blockchain transaction scheduling method according to claim 4, characterized in that, Determining the first conflict relationship between the target transaction and at least one first reference transaction includes: A second conflict relationship is determined between the target transaction and the second reference transaction, wherein the second reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction; When the second conflict relationship indicates that there is no conflict between the target transaction and the second reference transaction, a first conflict relationship is determined between the target transaction and at least one first reference transaction.

6. The blockchain transaction scheduling method according to claim 4, characterized in that, The step of scheduling the target transaction after the preset time period is reached includes: After the preset time period is reached, a third conflict relationship is determined between the target transaction and at least one third reference transaction, wherein the third reference transaction is a blockchain transaction that has been executed and has not been added to the transaction snapshot, other than the target transaction. When the third conflict relationship indicates that there is a conflict between the target transaction and the third reference transaction, the third weight of the third reference transaction is obtained, wherein the third weight is determined based on the resource consumption parameters of executing the third reference transaction; Calculate the sum of the second weights of all the third weights, and schedule the target transaction according to the relationship between the first weight and the sum of the second weights.

7. The blockchain transaction scheduling method according to claim 6, characterized in that, The step of scheduling the target transaction based on the relationship between the sum of the first weight and the second weight includes: When the first weight is greater than the sum of the second weights, the target transaction is added to the transaction snapshot; Alternatively, if the first weight is less than the sum of the second weights, the target transaction is re-executed; Alternatively, when the first weight equals the sum of the second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed.

8. The blockchain transaction scheduling method according to claim 6, characterized in that, Determining the third conflict relationship between the target transaction and at least one third reference transaction includes: A fourth conflict relationship is determined between the target transaction and the fourth reference transaction, wherein the fourth reference transaction is a blockchain transaction that has been executed and added to the transaction snapshot, other than the target transaction. When the fourth conflict relationship indicates that there is no conflict between the target transaction and the fourth reference transaction, a third conflict relationship is determined between the target transaction and at least one third reference transaction.

9. The method for scheduling blockchain transactions according to any one of claims 4 to 8, characterized in that, The scheduling method further includes: Whenever a blockchain transaction that was not added to the transaction snapshot is re-executed, the blockchain transaction that was re-executed and not added to the transaction snapshot will be used as the target transaction. The target transaction is rescheduled until all the blockchain transactions have been added to the transaction snapshot.

10. The blockchain transaction scheduling method according to claim 1, characterized in that, The target transaction is obtained whenever one of the blockchain transactions is completed. The first reference transaction has been added to the transaction snapshot. The scheduling of the target transaction based on the relationship between the first weight and the sum of the first weights includes: When the first weight is greater than the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction; Alternatively, if the first weight is less than the sum of the first weights, the target transaction is re-executed; Alternatively, when the first weight equals the sum of the first weights, the first reference transaction in the transaction snapshot is replaced with the target transaction or the target transaction is re-executed.

11. The blockchain transaction scheduling method according to claim 10, characterized in that, The scheduling method further includes: Re-execute the first reference transaction that was replaced in the transaction snapshot; Whenever the first reference transaction that was replaced is re-executed, the re-executed first reference transaction shall be used as the target transaction; The target transaction is rescheduled until all the blockchain transactions have been added to the transaction snapshot.

12. The blockchain transaction scheduling method according to claim 1, characterized in that, The first weight is determined through the following steps: Determine the score corresponding to at least one of the following for the target transaction: transaction execution time, number of read set keys, size of read set memory, number of write set keys, and size of write set memory; The first weight is obtained based on at least one of the stated scores.

13. A scheduling device for blockchain transactions, characterized in that, include: The execution module is used to acquire multiple blockchain transactions to be executed and execute each of the blockchain transactions; The conflict detection module is used to obtain the completed target transaction from multiple blockchain transactions, determine the first conflict relationship between the target transaction and at least one first reference transaction, wherein the first reference transaction is the blockchain transaction that has been completed other than the target transaction, the target transaction is obtained when all blockchain transactions have been completed, and the first reference transaction has not been added to the transaction snapshot. The weight acquisition module is used to acquire a first weight of the target transaction and a second weight of the first reference transaction when the first conflict relationship indicates that there is a conflict between the target transaction and the first reference transaction. The first weight is determined based on the resource consumption parameters for executing the target transaction, and the second weight is determined based on the resource consumption parameters for executing the first reference transaction. The resource consumption parameters include at least one of the following: transaction execution time of the blockchain transaction, number of read keys of the blockchain transaction, read set memory size of the blockchain transaction, number of write keys of the blockchain transaction, and write set memory size of the blockchain transaction. The first weight is positively correlated with the resources required to execute the target transaction, and the second weight is positively correlated with the resources required to execute the first reference transaction. The first scheduling module is used to add the target transaction to the transaction snapshot when the first weight is greater than each of the second weights; Alternatively, if the first weight is less than any of the second weights, the target transaction is re-executed; Alternatively, when the first weight is equal to at least one of the second weights, and the first weight is greater than the remaining second weights, the target transaction is added to the transaction snapshot or the target transaction is re-executed. Alternatively, the sum of the first weights of all the second weights can be calculated, and the target transaction can be scheduled according to the relationship between the first weights and the sum of the first weights.

14. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the blockchain transaction scheduling method according to any one of claims 1 to 12.

15. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the blockchain transaction scheduling method according to any one of claims 1 to 12.

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

Images