Blockchain-based order allocation methods, devices, computer equipment, and storage media

Abstract

This application relates to a blockchain-based order allocation method, apparatus, computer device, and storage medium. The blockchain-based order allocation method includes: evenly distributing multiple first transaction orders to be allocated among block builders; upon receiving multiple second transaction orders, acquiring historical performance information of each block builder; wherein the historical performance information includes processing information of block builders for different categories of transaction orders; the second transaction orders are subsequent orders to the first transaction orders; and based on the order category of each second transaction order and the historical performance information of each block builder, allocating the multiple second transaction orders to the block builders. This application solves the problem of the inability to reasonably allocate transaction order flows among different builders, which exacerbates the trend of blockchain centralization, and achieves a reasonable allocation of transaction order flows among different builders, stably promoting the decentralized development of blockchain.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to blockchain-based order allocation methods, apparatus, computer equipment, and storage media. Background Technology

[0002] In the existing Proposer-Builder Separation (PBS) scheme, the block proposer is only responsible for proposing the content of the next block, while the block builder is responsible for actually packaging transactions and building the block. However, a large number of transaction order flows and block building rights are gradually concentrated in the hands of at least a few builders, making the allocation of order flows usually monopolized by a few major block builders. This makes it impossible to reasonably allocate transaction order flows among different builders, exacerbating the trend of block centralization.

[0003] There is currently no effective solution to the problem that the relevant technologies cannot reasonably distribute transaction order flows among different builders, which exacerbates the trend of blockchain centralization. Summary of the Invention

[0004] This embodiment provides a blockchain-based order allocation method, apparatus, computer device, and storage medium to address the problem in related technologies where transaction order flows cannot be reasonably allocated among different builders, exacerbating the trend of blockchain centralization.

[0005] Firstly, this embodiment provides a blockchain-based order allocation method, the method comprising:

[0006] The multiple first transaction orders to be allocated are evenly distributed to the block builders;

[0007] Upon receiving multiple second transaction orders, the historical performance information of each block builder is obtained; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order;

[0008] Based on the order category of each of the second transaction orders and the historical performance information of each of the block builders, multiple second transaction orders are assigned to each of the block builders.

[0009] In some embodiments, prior to the average distribution of the multiple first transaction orders to be allocated to the block builders, the method further includes:

[0010] Based on a preset encapsulation format, the received multiple first transaction orders are encapsulated.

[0011] Each of the first transaction orders, after being packaged and processed, is transmitted to a trusted execution environment for storage.

[0012] In some embodiments, the step of evenly distributing the multiple first transaction orders to be allocated to each block builder includes:

[0013] Obtain the random seed corresponding to each block builder;

[0014] Based on the random seed, a random permutation order corresponding to each block builder is generated;

[0015] Based on the random arrangement, the multiple first transaction orders to be allocated are evenly distributed to each of the block builders.

[0016] In some embodiments, the allocation of multiple second transaction orders to each of the block builders based on the order category of each second transaction order and the historical performance information of each of the block builders includes:

[0017] Based on the historical performance information of each block builder, a number of corresponding historical performance parameters are determined; the historical performance parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders;

[0018] Determine the target weights corresponding to each of the aforementioned historical performance parameters;

[0019] Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each of the block builders.

[0020] In some embodiments, before allocating the plurality of second transaction orders to the respective block builders based on the order category of each second transaction order and the target weight corresponding to the different block builders, the method further includes:

[0021] Based on the target weight corresponding to each block builder and the preset deviation control constant, the maximum weight threshold is determined;

[0022] When it is detected that the target weight corresponding to the block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold.

[0023] In some embodiments, allocating multiple second transaction orders to each of the block builders based on the order category of each second transaction order and the target weight corresponding to different block builders includes:

[0024] The minimum number of orders to be allocated to each block builder is determined based on the preset base order volume, the average number of orders obtained by each block builder in the historical period, and the preset ratio.

[0025] Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each block builder; wherein, the number of orders obtained by each block builder is not less than the minimum number of orders.

[0026] In some embodiments, after allocating multiple second transaction orders to the respective block builders based on the order category of each second transaction order and the historical performance information of each block builder, the method further includes:

[0027] The target reward for each block builder is determined based on the preset base reward and the number of orders processed by each block builder within the historical period.

[0028] The target reward is allocated to the corresponding block builder.

[0029] Secondly, this embodiment provides a blockchain-based order allocation device, including:

[0030] The first allocation module is used to evenly distribute the multiple first transaction orders to be allocated to each block builder;

[0031] The acquisition module is used to acquire historical performance information of each block builder when multiple second transaction orders are received; wherein, the historical performance information includes the processing information of the block builder for different types of transaction orders; and the second transaction order is a subsequent order of the first transaction order;

[0032] The second allocation module is used to allocate multiple second transaction orders to each of the block builders based on the order category of each second transaction order and the historical performance information of each block builder.

[0033] Thirdly, this embodiment provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the blockchain-based order allocation method described in the first aspect above.

[0034] Fourthly, this embodiment provides a storage medium storing a computer program that, when executed by a processor, implements the blockchain-based order allocation method described in the first aspect above.

[0035] Compared with related technologies, the blockchain-based order allocation method, apparatus, computer equipment, and storage medium provided in this embodiment distribute multiple first transaction orders to be allocated evenly among block builders; upon receiving multiple second transaction orders, it acquires the historical performance information of each block builder; wherein the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction orders are subsequent orders of the first transaction orders; based on the order category of each second transaction order and the historical performance information of each block builder, the multiple second transaction orders are allocated to each block builder, solving the problem of the inability to reasonably allocate transaction order flow among different builders, which exacerbates the trend of blockchain centralization, and realizing the reasonable allocation of transaction order flow among different builders, thus stably promoting the decentralized development of the blockchain.

[0036] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0037] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0038] Figure 1 This is a hardware structure block diagram of a terminal device for a blockchain-based order allocation method provided in one embodiment of this application;

[0039] Figure 2 This is a flowchart of a blockchain-based order allocation method provided in one embodiment of this application;

[0040] Figure 3 This is a flowchart of an order allocation method during the system initialization phase provided in an embodiment of this application;

[0041] Figure 4 This is a flowchart of an order allocation method during the system operation phase provided in an embodiment of this application;

[0042] Figure 5 This is a flowchart of a blockchain-based order allocation method provided in a preferred embodiment of this application;

[0043] Figure 6 This is a structural block diagram of a blockchain-based order allocation device provided in one embodiment of this application.

[0044] In the diagram: 102, processor; 104, memory; 106, transmission device; 108, input / output device; 10, first allocation module; 20, acquisition module; 30, second allocation module. Detailed Implementation

[0045] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below in conjunction with the accompanying drawings and embodiments.

[0046] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning as understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these,” used in this application, do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to such processes, methods, products, or devices. The terms “connected,” “linked,” and “coupled,” used in this application, are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. The term “multiple” used in this application refers to two or more. The "and / or" operator describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: A alone, A and B simultaneously, and B alone. Typically, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," and "third," etc., used in this application are merely for distinguishing similar objects and do not represent a specific ordering of the objects.

[0047] The method embodiments provided in this example can be executed on a terminal, computer, or similar computing device. For example, it can run on a terminal. Figure 1 This is a hardware structure block diagram of the terminal for the blockchain-based order allocation method in this embodiment. For example... Figure 1 As shown, a terminal may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 and a memory 104 for storing data are also included. The processor 102 may be, but is not limited to, a microprocessor (MCU) or a programmable logic device (FPGA). The terminal may also include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the terminal described above. For example, the terminal may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0048] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the blockchain-based order allocation method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer programs stored in the memory 104, thereby implementing the aforementioned method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0049] The transmission device 106 is used to receive or send data via a network. This network includes a wireless network provided by the terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 can be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0050] This embodiment provides a blockchain-based order allocation method. Figure 2 This is a flowchart of the blockchain-based order allocation method in this embodiment, as shown below. Figure 2 As shown, the process includes the following steps:

[0051] Step S210: Distribute the multiple first transaction orders to be allocated equally to each block builder;

[0052] Step S220: When multiple second transaction orders are received, obtain the historical performance information of each block builder; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order;

[0053] Step S230: Based on the order category of each second transaction order and the historical performance information of each block builder, the multiple second transaction orders are allocated to each block builder.

[0054] Specifically, when a user submits a transaction order to the Aggregated Order Distribution System (AODS), the system encapsulates the received transaction order based on a preset encapsulation format, such as encapsulating it as a bundle. The encapsulation result includes information such as the maximum block height of the order, the transaction hash value, and whether the order should be rolled back. Each encapsulated first transaction order is then transmitted to a Trusted Execution Environment (TEE) for storage. The TEE provides hardware-level security protection, ensuring that transactions stored in the TEE cannot be accessed by any block builder. It can be understood that every transaction order submitted to the system undergoes the above encapsulation process before being stored in the TEE.

[0055] It's important to note that each block builder needs to register in the AODS system. Registration information includes the builder's address, Uniform Resource Locator (URL), and builder reward address. The block builder registration process is completed through smart contracts to ensure decentralization and transparency. Furthermore, the AODS system implements a decentralized mechanism, opening up block builder registration to increase participant diversity and ensuring fair participation across all block builders. This guarantees that block building power is not concentrated in the hands of a few nodes, promoting the decentralized development of blockchains.

[0056] Furthermore, during the initialization phase of the AODS system, the multiple first transaction orders awaiting allocation in the current system are evenly distributed to each block builder. Preferably, a random seed corresponding to each block builder is obtained. This random seed is generated based on the system startup timestamp and builder registration information after all block builders have registered. Based on the random seed, a pseudo-random number generator is used to generate a random permutation order corresponding to each block builder. Based on this random permutation order, the multiple first transaction orders awaiting allocation in the current system are evenly distributed to each block builder, thus ensuring that the order in which each block builder receives orders is completely random while evenly distributing transaction orders. If the total number of orders is not divisible by the number of builders, the excess orders will be distributed to some builders sequentially according to the aforementioned random permutation order.

[0057] During the AODS system's operation, the system receives multiple second transaction orders submitted by users. It acquires historical performance information for each block builder, including their processing information for different types of transaction orders. This historical performance information can be collected at regular intervals, such as every 10 blocks, to enable periodic evaluation. Based on each block builder's historical performance information, several corresponding historical performance parameters are determined. These parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders. The order on-chain success rate refers to the proportion of orders successfully uploaded to the chain by the builder for the same type of transaction order, while the order processing efficiency refers to the proportion of orders successfully sent to the chain by the builder for the same type of transaction order. Calculations are performed on each historical performance parameter to obtain corresponding target weights, which are used to evaluate the block builder's historical performance in handling corresponding order categories. Finally, based on the order category of each second transaction order and the target weights corresponding to different block builders within each order category, multiple second transaction orders are allocated to different block builders.

[0058] When determining the target weight, a fixed maximum weight threshold can be preset, or the maximum weight threshold can be calculated based on the target weight corresponding to each block builder and a preset deviation control constant. When it is detected that the target weight corresponding to a block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold. This avoids extreme skewness in order allocation caused by performance within a single time period, and helps improve the rationality of transaction order allocation. In addition, this embodiment adopts a minimum order guarantee mechanism to ensure that the number of orders obtained by each block builder is not less than the minimum order number, so as to promote the balance of order allocation. For example, a fixed minimum order number can be preset, or a random minimum order number can be generated based on a preset base order volume. The random minimum order number should be within a preset range. Alternatively, the minimum order number to be allocated to a block builder can be calculated based on a preset base order volume, the average number of orders obtained by each block builder in historical periods, and a preset ratio. In this embodiment, the method for setting the maximum weight threshold and the minimum order number is not limited.

[0059] Furthermore, within different time periods, the target reward to be allocated to each block builder is determined, and the target reward is allocated to the corresponding block builder. Specifically, block builders to be rewarded within the current time period can be selected, and pre-set rewards can be allocated to the selected block builders; alternatively, based on preset base rewards and the number of orders processed by each block builder within historical periods, the target reward corresponding to each block builder can be calculated, and the reward can be allocated according to the calculation results.

[0060] In the existing PBS scheme, block proposers are only responsible for proposing the content of the next block, while block builders are responsible for actually packaging transactions and building blocks. However, a large number of transaction order flows and block building rights are gradually concentrated in the hands of at least a few builders, which makes the allocation of order flows usually monopolized by a few major block builders. It is impossible to reasonably allocate transaction order flows among different builders, which exacerbates the trend of block centralization.

[0061] Compared to existing technologies, this application evenly distributes multiple first transaction orders to be allocated among block builders. Upon receiving multiple second transaction orders, it acquires the historical performance information of each block builder. This historical performance information includes the block builder's processing information for different types of transaction orders. Second transaction orders are subsequent orders to the first transaction orders. Based on the order category of each second transaction order and the historical performance information of each block builder, multiple second transaction orders are allocated to each block builder. Therefore, by allocating orders based on the subsequent order categories and the builder's processing performance for different types of orders after an initial even distribution, this application solves the problem of the inability to reasonably allocate transaction order flows among different builders, which exacerbates the trend of block centralization. It achieves a reasonable allocation of transaction order flows among different builders, stably promotes the decentralized development of blocks, and improves order processing efficiency.

[0062] In some embodiments, the following steps are included before the multiple first transaction orders to be allocated are evenly distributed among the block builders:

[0063] Based on a preset encapsulation format, the received multiple first transaction orders are encapsulated.

[0064] Each of the first transaction orders, after being packaged and processed, is transmitted to a trusted execution environment for storage.

[0065] Specifically, after the system receives a transaction order, it encapsulates the received multiple transaction orders based on a preset encapsulation method, such as encapsulating them in the form of a Bundle. The encapsulation result includes information such as the maximum block height of the order, the transaction hash value, and whether the order has been rolled back.

[0066] Furthermore, the encapsulated first transaction orders are transmitted to a trusted execution environment for storage. This trusted execution environment provides hardware-level security, ensuring that transactions stored there cannot be accessed by any block builder.

[0067] In this embodiment, multiple received first transaction orders are encapsulated based on a preset encapsulation method, and the encapsulated first transaction orders are transmitted to a trusted execution environment for storage. This avoids the risks of front-running and sandwich attacks, thus ensuring the privacy and security of user transactions.

[0068] In some of these embodiments, such as Figure 3 As shown, step S210, which involves evenly distributing the multiple first transaction orders to be allocated to each block builder, includes the following steps:

[0069] Step S211: Obtain the random seed corresponding to each block builder;

[0070] Step S212: Based on the random seed, generate a random permutation order corresponding to each block builder;

[0071] Step S213: Based on the random arrangement order, the multiple first transaction orders to be allocated are evenly distributed to each block builder.

[0072] Specifically, after all block builders have registered, a random seed corresponding to each block builder is generated based on the system startup timestamp and builder registration information. Based on the random seed, a pseudo-random number generator is used to generate a random permutation order corresponding to each block builder.

[0073] Furthermore, following the randomized order of block builders, the multiple first transaction orders to be allocated in the current system are evenly distributed among the block builders. While evenly distributing the transaction orders, it is ensured that the order in which each block builder receives orders is completely random. It should be noted that if the total number of first transaction orders is not divisible by the number of builders, the excess orders will be distributed to some builders sequentially according to the aforementioned randomized order.

[0074] In this embodiment, the block builders are randomly arranged, and the orders are evenly distributed according to the random arrangement, which helps to improve the randomness of the allocation of transaction orders.

[0075] In some of these embodiments, such as Figure 4 As shown, step S230, which assigns multiple second transaction orders to each block builder based on the order category of each second transaction order and the historical performance information of each block builder, includes the following steps:

[0076] Step S231: Determine multiple historical performance parameters based on the historical performance information of each block builder; the historical performance parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders.

[0077] Step S232: Determine the target weights corresponding to each historical performance parameter;

[0078] Step S233: Based on the order category of each second transaction order and the target weight corresponding to different block builders, allocate multiple second transaction orders to each block builder.

[0079] Specifically, during the operation of the AODS system, historical performance information for each block builder is collected at regular intervals, such as obtaining historical performance information for every 10 blocks. This historical performance information includes the block builder's processing information for different types of transaction orders. Based on the historical performance information of each block builder, several corresponding historical performance parameters are determined. These parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders. The order on-chain success rate refers to the proportion of orders successfully uploaded to the chain by the builder for the same type of transaction order out of the total number of orders. The order processing efficiency refers to the proportion of orders successfully sent to the chain by the builder for the same type of transaction order out of the total number of orders.

[0080] Furthermore, calculations are performed on each historical performance parameter to obtain the corresponding target weight. This target weight is used to evaluate the historical performance of the block builder in handling the corresponding order category. For example, the target weight is calculated as follows:

[0081] W = (T × W1) + (S × W2) (1)

[0082] In equation (1), W represents the target weight; T represents the order on-chain success rate; S represents the order processing efficiency; W1 and W2 are preset adjustment factors, for example, W1 and W2 are both set to 50%. Then, the received second transaction orders are classified, and the second transaction orders of different categories are allocated to each block builder according to the target weight corresponding to the block builder under different order categories.

[0083] In this embodiment, based on the historical performance information of each block builder, multiple historical performance parameters are determined. These parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders. The target weights corresponding to each historical performance parameter are determined. Then, based on the order category of each second transaction order and the target weights corresponding to different block builders, multiple second transaction orders are allocated to each block builder, thereby reasonably allocating the transaction order flow and improving order processing efficiency.

[0084] In some embodiments, before allocating multiple second transaction orders to each block builder based on the order category of each second transaction order and the target weight corresponding to different block builders, the following steps are also included:

[0085] The maximum weight threshold is determined based on the target weight corresponding to each block builder and the preset deviation control constant.

[0086] When it is detected that the target weight corresponding to the block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold.

[0087] Specifically, based on the target weight corresponding to each block builder and the preset deviation control constant, the maximum weight threshold is calculated. The specific calculation formula is as follows:

[0088] W max =μ+k×σ (2)

[0089] In equation (2), W max σ represents the maximum weight threshold; μ represents the average target weight of all current block builders; σ represents the standard deviation of the target weight of all block builders; k represents the preset deviation control constant, for example, k=2 means that the allowable weight fluctuation does not exceed twice the standard deviation of the average.

[0090] Furthermore, when the target weight corresponding to the block builder is detected to exceed the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold to avoid extreme bias in order allocation caused by the performance within a single time period.

[0091] In this embodiment, based on the target weight corresponding to each block builder and the preset deviation control constant, a maximum weight threshold is determined. When it is detected that the target weight corresponding to a block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold, which helps to improve the rationality of subsequent transaction order allocation.

[0092] In some embodiments, multiple second transaction orders are allocated to different block builders based on the order category of each second transaction order and the target weight corresponding to different block builders, including the following steps:

[0093] The minimum number of orders to be allocated to a block builder is determined based on the preset base order volume, the average number of orders obtained by each block builder in the historical period, and the preset ratio.

[0094] Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each block builder; wherein, the number of orders obtained by each block builder is not less than the minimum number of orders.

[0095] Specifically, a minimum order guarantee mechanism is adopted to ensure that each block builder receives no fewer orders than the minimum order quantity, thereby promoting a balanced allocation of orders within the system. The minimum order quantity can be determined in several ways. For example, a fixed minimum order quantity can be preset; or, a random minimum order quantity can be generated based on a preset base order quantity, with the randomly generated minimum order quantity falling within a preset range; or, the minimum order quantity to be allocated to a block builder can be calculated based on the preset base order quantity, the average number of orders each block builder receives over historical periods, and a preset ratio. The specific calculation formula is as follows:

[0096]

[0097] In equation (3), P represents the minimum order quantity; O α This indicates the preset base order quantity; This represents the average number of orders acquired by all builders in the previous time period; β represents the preset ratio, used to indicate the ratio of the minimum order guarantee to the average number of orders across the entire network. The initial value of β is usually set to 0.1, and can be dynamically adjusted later.

[0098] Furthermore, in the process of allocating multiple second transaction orders to each block builder based on the order category of each second transaction order and the target weight corresponding to different block builders, the number of orders obtained by each block builder is controlled to be no less than the minimum number of orders. It is understood that this embodiment executes subsequent order allocation based on a minimum order guarantee mechanism.

[0099] In this embodiment, based on the preset base order volume, the average number of orders obtained by each block builder in the historical period, and the preset ratio, the minimum number of orders to be allocated to each block builder is determined. Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each block builder. The number of orders obtained by each block builder is not less than the minimum number of orders, thereby reducing the risk of order centralization and improving the balance of order allocation in the system.

[0100] In some embodiments, after allocating multiple second transaction orders to block builders based on the order category of each second transaction order and the historical performance information of each block builder, the following steps are also included:

[0101] The target reward for each block builder is determined based on the preset base reward and the number of orders processed by each block builder within the historical period.

[0102] The target reward will be allocated to the corresponding block builder.

[0103] Specifically, within different time periods, multiple block builders expected to receive rewards in the current week are selected, and pre-set rewards are allocated to each selected block builder. Preferably, based on the preset base reward and the number of orders processed by each block builder in the historical period, the target reward corresponding to each block builder is calculated, and the reward is allocated according to the calculation results. The specific calculation formula is as follows:

[0104]

[0105] In equation (4), R represents the target reward corresponding to each block builder; R base Indicates the preset basic reward; O i This represents the number of orders successfully processed by the block builder within period i; O avg This represents the average number of orders processed by all block builders within the current time period.

[0106] In this embodiment, based on the preset basic reward and the number of orders processed by each block builder in the historical period, the target reward corresponding to each block builder is determined, and the target reward is allocated to the corresponding block builder. In this way, through the allocation of order rewards, high-quality block building is maintained and the decentralized ecosystem of the system is stabilized.

[0107] The present embodiment will now be described and illustrated through preferred embodiments.

[0108] Figure 5 This is a flowchart of a blockchain-based order allocation method according to a preferred embodiment, as shown below. Figure 5 As shown, this blockchain-based order allocation method includes the following steps:

[0109] Step S510: Based on a preset encapsulation format, encapsulate the received multiple first transaction orders; then transmit each encapsulated first transaction order to a trusted execution environment for storage.

[0110] Step S520: Obtain the random seed corresponding to each block builder; generate a random permutation order corresponding to each block builder based on the random seed; and distribute the multiple first transaction orders to be allocated equally to each block builder based on the random permutation order.

[0111] Step S530: When the system receives multiple second transaction orders, obtain the historical performance information of each block builder; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order;

[0112] Step S540: Determine multiple historical performance parameters based on the historical performance information of each block builder; the historical performance parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders.

[0113] Step S550: Determine the target weights corresponding to each historical performance parameter; based on the order category of each second transaction order and the target weights corresponding to different block builders, allocate multiple second transaction orders to each block builder;

[0114] Step S560: Determine the target reward for each block builder based on the preset base reward and the number of orders processed by each block builder in the historical period; allocate the target reward to the corresponding block builder.

[0115] In this embodiment, based on a preset encapsulation method, multiple received first transaction orders are encapsulated, and the encapsulated first transaction orders are transmitted to a trusted execution environment for storage. The random seed corresponding to each block builder is obtained. Based on the random seed, a random arrangement order corresponding to each block builder is generated, and based on the random arrangement order, the multiple first transaction orders to be allocated are evenly distributed to each block builder.

[0116] Furthermore, when the system receives multiple second transaction orders, it acquires the historical performance information of each block builder. Based on this information, it determines several historical performance parameters, including the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders. It then determines the target weights corresponding to each historical performance parameter. Based on the order category of each second transaction order and the target weights for different block builders, the multiple second transaction orders are allocated to each block builder. This solves the problem of the inability to reasonably distribute transaction order flows among different builders, which exacerbates the trend of block centralization. It achieves a reasonable distribution of transaction order flows among different builders, steadily promoting the decentralized development of the block.

[0117] Then, based on the preset base reward and the number of orders processed by each block builder in the historical period, the target reward for each block builder is determined, and the target reward is allocated to the corresponding block builder to ensure the decentralized stability of the system.

[0118] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0119] This embodiment also provides a blockchain-based order allocation device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. The terms "module," "unit," "subunit," etc., used below refer to combinations of software and / or hardware that perform predetermined functions. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0120] Figure 6 This is a structural block diagram of the blockchain-based order allocation device in this embodiment, as shown below. Figure 6 As shown, the device includes:

[0121] The first allocation module 10 is used to evenly distribute the multiple first transaction orders to be allocated to each block builder;

[0122] The acquisition module 20 is used to acquire the historical performance information of each block builder when multiple second transaction orders are received; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order;

[0123] The second allocation module 30 is used to allocate multiple second transaction orders to each block builder based on the order category of each second transaction order and the historical performance information of each block builder.

[0124] The apparatus provided in this embodiment evenly distributes multiple first transaction orders to be allocated to each block builder; upon receiving multiple second transaction orders, it acquires the historical performance information of each block builder; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order; based on the order category of each second transaction order and the historical performance information of each block builder, multiple second transaction orders are allocated to each block builder, solving the problem of the inability to reasonably allocate transaction order flow among different builders, which exacerbates the trend of block centralization, and realizing the reasonable allocation of transaction order flow among different builders, thus steadily promoting the decentralized development of blocks.

[0125] In some of these embodiments, in Figure 6 In addition to the above, the device also includes a storage module for encapsulating multiple received first transaction orders based on a preset encapsulation format; and for transmitting each encapsulated first transaction order to a trusted execution environment for storage.

[0126] In some embodiments, the first allocation module 10 is further configured to obtain a random seed corresponding to each block builder; generate a random permutation order corresponding to each block builder based on the random seed; and distribute the multiple first transaction orders to be allocated to each block builder equally based on the random permutation order.

[0127] In some embodiments, the second allocation module 30 is further configured to determine multiple historical performance parameters based on the historical performance information of each block builder; the historical performance parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders; determine the target weight corresponding to each historical performance parameter; and allocate multiple second transaction orders to each block builder based on the order category of each second transaction order and the target weight corresponding to different block builders.

[0128] In some of these embodiments, in Figure 6 Based on this, the device also includes an update module, which is used to determine the maximum weight threshold based on the target weight corresponding to each block builder and the preset deviation control constant; when it is detected that the target weight corresponding to the block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold.

[0129] In some embodiments, the second allocation module 30 is further configured to determine the minimum number of orders to be allocated to a block builder based on a preset base order quantity, the average number of orders obtained by each block builder in a historical period, and a preset ratio; and to allocate multiple second transaction orders to each block builder based on the order category of each second transaction order and the target weight corresponding to different block builders; wherein the number of orders obtained by each block builder is not less than the minimum number of orders.

[0130] In some of these embodiments, in Figure 6 Based on this, the device also includes a reward module, which is used to determine the target reward for each block builder based on the preset base reward and the number of orders processed by each block builder in the historical period; and to allocate the target reward to the corresponding block builder.

[0131] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0132] This embodiment also provides a computer device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0133] Optionally, the computer device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0134] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0135] S1, distribute the multiple first transaction orders to be allocated equally to each block builder;

[0136] S2, upon receiving multiple second transaction orders, obtain the historical performance information of each block builder; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order;

[0137] S3 allocates multiple second transaction orders to each block builder based on the order category of each second transaction order and the historical performance information of each block builder.

[0138] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0139] Furthermore, in conjunction with the blockchain-based order allocation method provided in the above embodiments, this embodiment can also provide a storage medium for implementation. This storage medium stores a computer program; when executed by a processor, the computer program implements any of the blockchain-based order allocation methods described in the above embodiments.

[0140] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0141] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0142] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0143] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A blockchain-based order allocation method, characterized in that, The method includes: The multiple first transaction orders to be allocated are evenly distributed to the block builders; Upon receiving multiple second transaction orders, historical performance information of each block builder is obtained; wherein, the historical performance information includes the block builder's processing information for different types of transaction orders; the second transaction order is a subsequent order of the first transaction order; Based on the order category of each of the second transaction orders and the historical performance information of each of the block builders, multiple second transaction orders are assigned to each of the block builders.

2. The blockchain-based order allocation method according to claim 1, characterized in that, Before the process of evenly distributing the multiple first transaction orders to be allocated to the block builders, the method further includes: Based on a preset encapsulation format, the received multiple first transaction orders are encapsulated. Each of the first transaction orders, after being packaged and processed, is transmitted to a trusted execution environment for storage.

3. The blockchain-based order allocation method according to claim 1, characterized in that, The process of evenly distributing the multiple first transaction orders to be allocated to each block builder includes: Obtain the random seed corresponding to each block builder; Based on the random seed, a random permutation order corresponding to each block builder is generated; Based on the random arrangement, the multiple first transaction orders to be allocated are evenly distributed to each of the block builders.

4. The blockchain-based order allocation method according to claim 1, characterized in that, The allocation of multiple second transaction orders to each block builder based on the order category of each second transaction order and the historical performance information of each block builder includes: Based on the historical performance information of each block builder, a number of corresponding historical performance parameters are determined; the historical performance parameters include the block builder's order on-chain success rate and order processing efficiency for different types of transaction orders; Determine the target weights corresponding to each of the aforementioned historical performance parameters; Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each of the block builders.

5. The blockchain-based order allocation method according to claim 4, characterized in that, Before allocating multiple second transaction orders to each of the block builders based on the order category of each second transaction order and the target weight corresponding to different block builders, the method further includes: Based on the target weight corresponding to each block builder and the preset deviation control constant, the maximum weight threshold is determined; When it is detected that the target weight corresponding to the block builder exceeds the maximum weight threshold, the target weight corresponding to the block builder is updated to the maximum weight threshold.

6. The blockchain-based order allocation method according to claim 4, characterized in that, The allocation of multiple second transaction orders to each block builder based on the order category of each second transaction order and the target weight corresponding to different block builders includes: The minimum number of orders to be allocated to each block builder is determined based on the preset base order volume, the average number of orders obtained by each block builder in the historical period, and the preset ratio. Based on the order category of each second transaction order and the target weight corresponding to different block builders, multiple second transaction orders are allocated to each block builder; wherein, the number of orders obtained by each block builder is not less than the minimum number of orders.

7. The blockchain-based order allocation method according to claim 1, characterized in that, After allocating multiple second transaction orders to the respective block builders based on the order category of each second transaction order and the historical performance information of each block builder, the process further includes: The target reward for each block builder is determined based on the preset base reward and the number of orders processed by each block builder within the historical period. The target reward is allocated to the corresponding block builder.

8. A blockchain-based order allocation device, characterized in that, include: The first allocation module is used to evenly distribute the multiple first transaction orders to be allocated to each block builder; The acquisition module is used to acquire historical performance information of each block builder when multiple second transaction orders are received; wherein, the historical performance information includes the processing information of the block builder for different types of transaction orders; and the second transaction order is a subsequent order of the first transaction order; The second allocation module is used to allocate multiple second transaction orders to each of the block builders based on the order category of each second transaction order and the historical performance information of each block builder.

9. A computer device, comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the steps of the blockchain-based order allocation method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the blockchain-based order allocation method as described in any one of claims 1 to 7.

Images