JP7158522B2 - Transaction request processing method, apparatus, device, medium, and program in blockchain - Google Patents

Description

TECHNICAL FIELD Embodiments of the present application relate to computer technology, specifically blockchain technology, and more particularly to transaction request selection methods, apparatus, devices, media, and programs in blockchain.

Currently, in blockchain networks where blockout incentives exist, blockout nodes typically sort transactions according to the fee level of multiple transactions and select transactions for pending processing.

However, the number of transactions processed by blockout nodes is usually limited. prone to error. Therefore, how to guarantee the incentive income of blockout nodes and ensure the smooth execution of each transaction remains a pressing issue in the blockchain space. In addition, regarding blockout nodes, how to improve blockout efficiency is also an issue that cannot be ignored.

Embodiments of the present application disclose a transaction request processing method, apparatus, device, and medium in a blockchain to improve the rationality and selection efficiency of a blockchain node's selection of transaction requests during the block generation process, In addition, blockout efficiency can be improved.

In a first aspect, embodiments of the present application disclose a method of processing transaction requests in a blockchain, the method comprising:
aggregating selected target transaction requests having dependencies in a blockchain network to obtain at least one set of transaction requests;
determining a candidate factor interval to which said transaction request set belongs, said factor interval being used to measure the probability that said transaction request set will participate in a block generation process;
selecting a current target factor interval from the candidate factor intervals and selecting a current target transaction request set to participate in block generation process from the candidate transaction request set corresponding to the current target factor interval.

In a second aspect, embodiments of the present application further disclose an apparatus for processing transaction requests in a blockchain, the apparatus comprising:
a transaction request set determination module that aggregates selected target transaction requests having dependencies in a blockchain network to obtain at least one transaction request set;
A candidate factor interval determination module for determining a candidate factor interval to which the transaction request set belongs, wherein the factor interval is used to measure the probability that the transaction request set participates in a block generation process. a module;
A transaction request set selection module for selecting a current target factor interval from said candidate factor intervals and selecting a current target transaction request set to participate in a block generation process from said candidate transaction request sets corresponding to said current target factor interval. and
In a third aspect, embodiments of the present application further disclose an electronic device comprising:
at least one processor;
a memory communicatively connected to the at least one processor;
The memory stores instructions executable by the at least one processor, the instructions causing the at least one processor to perform the transaction request processing method in a blockchain according to any one of the embodiments herein. performed by the at least one processor to enable

In a fourth aspect, embodiments of the present application provide a non-instantaneous computer-readable storage medium storing computer instructions for causing a computer to perform the method of processing transaction requests in a blockchain according to any one of the embodiments of the present application. disclosed.

According to the technical solution of the embodiment of the present application, the block generation process according to the circular logic of selecting the current target factor interval and selecting the current target transaction request set from the candidate transaction request set corresponding to the current target factor interval. A target transaction request set participating in is cumulatively determined after at least one circular selection, and finally a block is generated by executing the transaction requests in the cumulatively determined target transaction request set; Here, there is a dependency relationship between the transaction requests in the target transaction request set, which improves the rationality and selection efficiency of transaction request selection by blockchain nodes in the block generation process, and improves the blockout efficiency. be able to.
What is described in the Summary of the Invention section is not intended to limit key or critical features of the embodiments of the present application, nor is it intended to limit the scope of the present application. should be understood. Other features of the present application will be readily understood upon reading the following description.

The accompanying drawings are used for a better understanding of the embodiments and do not constitute a limitation to the present application.
4 is a flow chart of a transaction request processing method in a blockchain disclosed in embodiments of the present application; 1 is a schematic diagram of dependencies between multiple transaction requests disclosed in embodiments of the present application; FIG. FIG. 4 is a flow chart of a transaction request processing method within another blockchain disclosed in embodiments of the present application; FIG. FIG. 4 is a schematic diagram of an ordered graph of price/performance ratios and an ordered graph of candidate transaction request sets disclosed in embodiments of the present application; 1 is a schematic diagram of the architecture of transaction request processing in a blockchain disclosed in embodiments of the present application; FIG. FIG. 4 is a flow chart of another transaction request processing method in blockchain disclosed in embodiments of the present application; FIG. 1 is a schematic diagram of the structure of a transaction request processor in a blockchain disclosed in an embodiment of the present application; FIG. 1 is a block diagram of an electronic device disclosed in embodiments of the present application; FIG.

Exemplary embodiments of the present disclosure are described below with reference to the drawings, and various details of the embodiments of the present disclosure are included for ease of understanding and are considered merely exemplary. Should be. Accordingly, those skilled in the art should appreciate that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, in the following description, descriptions of known functions and constructions are omitted for clarity and brevity.

FIG. 1 is a flowchart of a transaction request processing method in a blockchain disclosed in an embodiment of the present application, how a blockchain node with bookkeeping rights (also called blockout rights) waits in the process of block generation. , and the schemes disclosed in the embodiments of the present application are preferably applied to a blockchain network that deploys a consensus mechanism with competing blockouts. Applicable. Chain networks include, but are not limited to, consortium chain networks, public chain networks, etc. The methods disclosed in embodiments of the present application may be performed by a transaction request processor within a blockchain, which may be implemented in software and/or hardware, and integrated on a blockchain node. and blockchain nodes may be deployed on any electronic device with computing power.

As shown in FIG. 1, the transaction request processing method in the blockchain disclosed in the embodiments of the present application may include the following.

At S101, at least one set of transaction requests is obtained by aggregating selected target transaction requests having dependencies in the blockchain network.

Here, the dependency between transaction requests refers to the situation where a blockchain node needs to depend on the processing results of other transaction requests in the process of executing a specific transaction request, or in the process of executing other transaction requests. Refers to a situation where it is necessary to rely on the outcome of processing the current transaction request. A selected transaction request refers to a transaction request that has not been selected by a blockchain node in the blockchain network and has not decided whether to participate in the block generation process. At least one transaction request set (or transaction request sequence) in which at least one transaction request in each transaction request set has dependencies on each other, aggregating selected target transaction requests with dependencies in the blockchain network. get The number of transaction requests in each transaction request set depends on the situation.

FIG. 2 shows a schematic diagram of one dependency between multiple transaction requests by way of example and should not be construed as a specific limitation to the embodiments of the present application. As shown in FIG. 2, transaction request A depends on transaction request B, transaction request B depends on transaction request C, and transaction request A, transaction request B, and transaction request C form one transaction request set 1. may Transaction request D is an independent transaction request that does not depend on other transaction requests, and transaction request D may form one transaction request set 2 by itself. Transaction request E depends on transaction request F, transaction request F depends on transaction request H, and transaction request G likewise depends on transaction request H, so that transaction request E, transaction request F, transaction request H, and transaction request Requests G can form one transaction request set 3 .

At S102, determine the candidate factor interval to which the transaction request set belongs, in which the factor interval is used to measure the probability that the transaction request set participates in the block generation process.

In embodiments of the present application, a plurality of candidate factor intervals can be preset, and those candidate factor intervals are, for example, (0, N], (N, 2N], ..., (xN, (x+1)) N)], and the values of x and N can be set according to the actual situation.There is no upper or lower limit overlap between each candidate factor interval, and the interval The larger the value of the upper or lower bound of , the higher the probability that the transaction request set within the interval will be selected to participate in the block generation process, and based on the attributes of each transaction request set, each transaction Determine the candidate factor interval that the request set belongs to.The attribute of the transaction request set can be any characteristic information that can be used to determine whether the transaction request set was selected to participate in the block generation process. For example, the attributes of a transaction request set include one or more of the following factors: number of transaction requests included in the set, payment instrument information for the transaction requests, space footprint (size) of the transaction requests, priority of the transaction requests, etc. Illustratively, an incentive factor for each transaction request set, i.e., an evaluation value for the transaction request set, may be determined based on attributes of the transaction request set, and then based on the incentive factor. can be used to determine the candidate factor interval to which each transaction request set belongs.

Taking one consideration factor as an example, if the number of transaction requests included in the transaction request set is within a predetermined threshold interval, the incentive factor of the transaction request set is greater, i.e., to participate in the block generation process. , where the threshold interval is the time cost of the blockchain node to execute each transaction request and the packaging cost of producing blocks. It can be determined based on the time cost, thereby achieving a comprehensive evaluation of whether the time cost for executing each transaction request selected by the blockchain node is reasonable during the block generation process. make it possible. If there is a large difference between the number of transaction requests with payment instrument information exceeding the voucher threshold and the first number threshold in the set of transaction requests, then the set of transaction requests may be considered to have a large incentive factor; Here, the bill of payment information, or processing fee, of a transaction request represents the incentive or profit that a blockchain node can obtain after executing that transaction request, so that the bill of payment information contained in the transaction request set is the highest transaction request. The higher the number of , the higher the probability that a blockchain node will select that set of transaction requests to participate in the block generation process from a profitability standpoint. If the difference between the number of transaction requests belonging to high priority in the transaction request set and the second number threshold is large, the larger the incentive factor of the transaction request set may be considered, wherein the transaction The priority of requests may be determined by the blockchain system or assigned by the blockchain nodes themselves, depending on factors such as transaction type involved in the transaction request, generation time, importance, business value, etc. . Embodiments of the present application are not specifically limited. Various types of thresholds involved in the above can be adaptively set in practical applications, and embodiments of the present application are not particularly limited.

Based on the above discussion, the transaction request set incentive factor may also be determined in a complex manner based on at least two considerations. Illustratively, the incentive factor for the set of transaction requests is the difference between the number of transaction requests in the set of transaction requests that have payment instrument information exceeding the voucher threshold and the first number threshold in the set of transaction requests, and a high priority and a second number threshold. Also, the more transaction requests with high payment instrument information included in the transaction request set and the more transaction requests belonging to the higher priority included in the transaction request set, the greater the incentive factor of the transaction request set. In general, transaction requests belonging to a higher priority also correspond to higher instrument of payment information.

Also illustratively, an incentive factor for a transaction request set is determined based on the payment instrument information and space occupancy of the transaction requests in the transaction request set, which is, for example, the total payment instrument for each transaction request in the transaction request set. Calculate the sum of the information, ie, the payment instrument information for each transaction request. Compute the total space occupancy of each transaction request in the transaction request set, that is, the sum of the space occupancy of each transaction request (sum_size). The quotient value of total bill of payment information and total space occupancy is used as the incentive factor for transaction request sets. In this case, the incentive factor can also be said to be the price-performance ratio of a set of transaction requests, which provides blockchain nodes with the space occupancy of each selected transaction request and the revenue obtained by executing these transaction requests. It can be rationalized to make the trade-offs based on , to fully utilize the block space and maximize the revenue as much as possible, and this is for blockchain nodes to aggressively vie for bookkeeping rights. It can also be an effective incentive, thus allowing a more effective and rational incentive calculation model to exist in the blockchain network, ensuring the normal and timely generation of blocks.

When a blockchain node selects a transaction request to participate in the block generation process purely according to the processing fee level, the dependency relationship between transaction requests is not guaranteed, and the space occupation of transaction requests with high processing fees When , block space limits limit the number of transaction requests that a blockchain node can execute, so the processing fee for each individual transaction request increases, but the number of transaction requests that a blockchain node can execute decreases. , the choice of transaction requests by blockchain nodes may still be unreasonable, because the rewards and profits ultimately obtained may not be optimal, i. No effective incentive effect for blockchain nodes. The absurd problem of selecting transaction requests based solely on the amount of processing charges is resolved by taking into account the transaction request's bill of payment information and space occupancy collectively.

Further, based on the above technical solution, the step of determining the candidate factor interval to which the transaction request set belongs includes:
matching a candidate factor interval to which said transaction request set belongs by traversing upper and lower bounds of a factor interval created based on an incentive factor of said transaction request set, said incentive factor being a blockchain node is used to characterize the incentive gained by executing transaction requests in the transaction request set or to characterize the probability that the transaction request set participates in the block generation process;
if not, reconstructing the candidate factor interval to which the transaction request set belongs. That is, candidate factor intervals can change dynamically in response to the generation of transaction request sets.

At S103, the current target factor interval is selected from the candidate factor intervals, and the current target transaction request set participating in the block generation process is selected from the candidate transaction request set corresponding to the current target factor interval.

After determining the candidate factor interval to which the transaction request set belongs, the current target factor interval can first be selected from a plurality of candidate factor intervals based on a preset interval selection strategy, e.g. Candidate factor intervals with the largest lower bounds can be preferentially selected. Next, from among the multiple candidate transaction request sets corresponding to the current target factor interval, select the current target transaction request set based on the set selection strategy, e.g. Preferentially select the set with the largest space footprint of requests as the current target transaction request set. Here, the set selection strategy may be determined by the specific needs for the attributes of the transaction request set in the business process, i.e., the number of transaction requests included in the candidate transaction request set, the transaction request's bill of payment information, the transaction request Any of the factors, such as the space footprint of , the priority of the transaction requests, etc., may be used as selection factors for the current target set of transaction requests based on current business needs.

Moreover, after selecting the current target transaction request set to participate in the block generation process, the method disclosed in the embodiments of the present application may further include the following.

Compute the total space footprint of the current target transaction request set and the target transaction request set selected in the current block generation cycle.

determining at least one new transaction request set based on dependencies among the remaining transaction requests to be selected, if the resulting total space occupancy is less than the block space threshold; Based on this, the operation of determining a new current target transaction request set is executed, that is, the operations of S101-S103 are repeated.

Here, the block space threshold is related to the spatial size of blocks in the blockchain network and may be used to reflect the upper limit of the spatial size of blocks. The remaining selected transaction requests are transaction requests in the blockchain network, excluding the current target transaction request set and the transaction requests in the target transaction request set selected in the current block generation cycle.

After going through at least one circular selection of the target transaction request set, if the finally cumulatively determined transaction request satisfies the block generation condition, the blockchain node executes the selected individual transaction request, and the current Blocks can be generated and added to the blockchain.

According to the technical solution of the embodiment of the present application, in each circular selection process of the target transaction request set, first, a plurality of transaction request sets are obtained according to the dependency relationship between the target transaction requests to be selected, and the candidate factor to which the transaction request set belongs is determined. sorting the transaction request set according to the interval; then selecting a current target factor interval from among a plurality of candidate factor intervals; and selecting the current target transaction request set from the candidate transaction request set corresponding to the current target factor interval. is selected to participate in the block generation process. This solves the problem that the existing scheme divides the dependencies between transaction requests, which causes blockchain nodes to unreasonably select transaction requests to participate in the block generation process, which affects the block generation efficiency. It improves the rationality and selection efficiency of blockchain nodes in selecting transaction requests in the process of block generation, and improves blockout efficiency.

The step of optionally aggregating selected target transaction requests with dependencies in the blockchain network to obtain at least one set of transaction requests based on the above technical solution, comprising:
constructing a directed acyclic graph among the selected transaction requests based on the dependencies between the selected transaction requests in the blockchain network;
and aggregating selected transaction requests with dependencies using a directed acyclic graph to obtain at least one set of transaction requests.

Specifically, each selected transaction request may serve as a node of a directed acyclic graph, and dependencies between selected transaction requests may serve as edges of the directed acyclic graph. By constructing a directed acyclic graph, it is possible to manage the dependencies between each selected transaction request in an orderly manner. can be flexibly changed. Further, the transaction request set includes a leaf transaction request and each non-leaf transaction request upon which the leaf transaction request depends, and the leaf transaction requests in different transaction request sets are different.

In Example 1, the following three sets of transaction requests can be determined, using the dependencies between multiple transaction requests shown in FIG. 2 as an example.
Transaction request set 1: transaction request A→transaction request B→transaction request C;
Transaction Request Set 2: Transaction Request D;
Transaction request set 3: transaction request E→transaction request F→transaction request H and transaction request G→transaction request H.

Here, in transaction request set 1, transaction request A is a leaf transaction request, and transaction request B and transaction request C are non-leaf transaction requests on which the leaf transaction request depends.

In transaction request set 2, transaction request D is an independent transaction request.
In transaction request set 3, transaction request E and transaction request G are leaf transaction requests, transaction request F and transaction request H are non-leaf transaction requests upon which leaf transaction request E depends, and transaction request H is leaf transaction request G. is a dependent non-leaf transaction request.

In Example 2, assuming that the selected transaction requests can correspond to transactions, the following dependencies exist among the transactions: Transaction 2 depends on Transaction 1, Transaction 3 depends on Transaction 2, and so on. , transaction 4 depends on transaction 3. Then, a transaction request set or transaction sequence can be expressed as follows.

Transaction Sequence 1: Transaction 1;
Transaction sequence 2: transaction 2→transaction 1.
Transaction sequence 3: transaction 3→transaction 2→transaction 1.
Transaction sequence 4: transaction 4→transaction 3→transaction 2→transaction 1.
Here, in deal sequence 1, deal 1 is an independent deal.

In deal sequence 2, deal 2 is a leaf deal and deal 1 is a non-leaf deal (also called an ancestor deal).
In trade sequence 3, trade 3 is a leaf trade and trades 2 and 1 are non-leaf trades.
In trade sequence 4, trade 4 is a leaf trade, and trades 3, 2, and 1 are non-leaf trades.

And, as can be seen from the above example, if the same dependency exists among multiple selected transaction requests, each transaction request set will have the earliest dependent transaction request (or the oldest ancestor transaction request). called requests). For example, in the above example, transaction sequence 2-deal sequence 4 all contain the oldest ancestor transaction: transaction1.

After the selection cycle of the current target transaction request set ends, the transaction requests included in the current target transaction request set are removed from the selected target transaction requests in the current blockchain network, and the remaining selected target transaction requests are obtained. It can then be used to reconstruct the directed acyclic graph based on the dependencies between the remaining selected transaction requests and determine a new current set of target transaction requests.

FIG. 3 is a flow chart of another intra-blockchain transaction request processing method disclosed in an embodiment of the present application, which is further optimized and extended based on the above technical scheme, and can be used in any of the above embodiments. may be combined with each of As shown in FIG. 3, the method includes the following steps.

At S301, at least one set of transaction requests is obtained by aggregating selected target transaction requests having dependencies in the blockchain network.
At S302, determine the candidate factor interval to which the transaction request set belongs, said factor interval being used to measure the probability that said transaction request set participates in the block generation process.

Here, an incentive factor for the transaction request set may be determined based on the bill of payment information and space occupancy of the transaction request set in the transaction request set, where the incentive factor also includes the price performance ratio for the transaction request set. Called and used to characterize the rewards a blockchain node gets from executing a set of transaction requests. The candidate factor interval to which the transaction request set belongs is then matched by traversing the upper and lower bounds of the created factor interval based on the transaction request set's incentive factor. If not, reconstruct the candidate factor interval to which the transaction request set belongs. That is, candidate factor intervals can change dynamically as transaction request sets are generated.

At S303, the current factor interval is selected according to the interval value of the candidate factor interval.
For example, the candidate factor interval with the largest upper interval value or lower interval value may be preferentially selected as the current factor interval.

At S304, the current transaction request set is selected from the candidate transaction request sets corresponding to the current factor interval according to the amount of space occupied by the candidate transaction request sets corresponding to the current factor interval.

Specifically, by reordering the space occupancy of the candidate transaction request sets in the candidate transaction request set corresponding to the current factor interval, determining the current transaction request set based on the result of the reordering, e.g. , according to the space occupancy of the candidate transaction request sets, sort from largest to smallest, preferably using the first candidate transaction request set as the current transaction request set. Alternatively, among the candidate transaction request sets corresponding to the current factor interval, a candidate transaction request set whose space occupation amount is greater than the space occupation threshold is determined as the current transaction request set, and the space occupation threshold is flexibly set. The candidate transaction request set with the largest space occupancy may be selected as the current transaction request set, for example, based on a space occupancy threshold.

The space size of each interval on the blockchain is relatively fixed, and by selecting the current transaction request set according to the space occupancy of the candidate transaction request set, candidate transactions with relatively large space occupancy It can achieve preferential selection for the set of requests, make full use of the block space, can reduce the number of selections of transaction requests participating in the block generation process to some extent, and furthermore, the blockchain node can It can save the time cost (computing power) for selecting transaction requests, this can balance node revenue and computing power consumption, and block deploying a consensus mechanism with competing blockouts. For the chain network, the block chain node has enough computing power to compete for the right of bookkeeping, and for this reason, the consumption of computing power when selecting transaction requests is large, so it fails to compete for the right of bookkeeping. You can avoid not doing it. In addition, the number of selected transaction request sets can be reduced, and the total number of transaction requests cumulatively selected can be relatively reduced, so that blockchain nodes consume to generate blocks. The computational power to do so can also be reduced.

At S305, the current transaction request set is verified based on the current transaction request set and the target transaction request set selected in the current block generation cycle.
At S306, the current target factor interval and current target transaction request set are determined based on the verification results.

Specifically, whether the number of transaction request sets cumulatively selected by a blockchain node so far or the number of transaction requests cumulatively selected by a blockchain node exceeds a corresponding number threshold; or The current transaction request set may be verified based on a predetermined verification strategy, such as whether the total space footprint of the transaction request sets cumulatively selected by the blockchain nodes exceeds a block space threshold. Here, the block space threshold is related to the spatial size of blocks in the blockchain network and may be used to reflect the upper limit of the spatial size of blocks.

Illustratively, verifying the current transaction request set based on the current transaction request set and a target transaction request set selected in the current block generation cycle comprises:
calculating the total space footprint of the current transaction request set and the target transaction request set selected in the current block generation cycle;
and verifying the current set of transaction requests based on the relationship between the total space footprint and the block space threshold.

So far, if the number of transaction request sets cumulatively selected by a blockchain node or the number of transaction requests cumulatively selected by a blockchain node does not exceed the corresponding number threshold, or Validation is considered passed, such as when the total space footprint of the cumulatively selected set of transaction requests does not exceed the block space threshold, the current factor interval is used as the current target factor interval, and the current transaction The request set is used as the current target transaction request set. If the verification fails, the current goal factor interval and the current goal transaction based on the remaining candidate transaction request set corresponding to the current goal factor interval or the remaining candidate factor interval until the block generation condition is met. The request set determination operation needs to be performed again. where the remaining candidate transaction request sets corresponding to the current factor interval include the transaction request sets corresponding to the current factor interval other than the transaction request sets that failed validation, and the remaining candidate factor intervals are the current factor Contains candidate factor intervals other than intervals.

According to the technical solution of the embodiment of the present application, in the process of each circular selection of the target transaction request set, the current factor interval is selected according to the interval value of the candidate factor interval to which the transaction request set belongs; From the corresponding candidate transaction request sets, select the current transaction request set based on the space occupancy of the candidate transaction request sets corresponding to the current factor interval, and then based on the transaction request sets cumulatively selected so far. Determine the current target factor interval and the current target transaction request set based on the verification results by verifying the current transaction request set with This solves the problem that the existing scheme divides the dependencies between transaction requests, which causes blockchain nodes to unreasonably select transaction requests to participate in the block generation process, further affecting the block generation efficiency. The solution is to improve the selection efficiency of the block chain node when selecting transaction requests in the block generation process, and ensure the rationality of selecting the target transaction request set in each round selection process. In particular, first determine the candidate factor interval to which the transaction request set belongs based on the bill of payment information and space occupancy of the transaction requests in the transaction request set, and then determine the candidate factor interval that has been cumulatively selected by the blockchain nodes so far. Verify the currently selected transaction request set based on whether the total space occupancy of the current transaction request set exceeds the block space threshold, and determine the block space after fully considering the blockchain node revenue. A fully exploitable effect can be achieved.

Determining a current target factor interval and a current target transaction request set based on the technical solution, preferably based on the verification result.

If verification of the current transaction request set fails, use the current factor interval as the current target factor interval, and determine the current target transaction request set based on the remaining candidate transaction request sets corresponding to the current factor interval. Take action to decide. Here, the remaining candidate transaction request sets include transaction request sets corresponding to the current factor interval other than the transaction request sets that failed validation. Illustratively, the remaining candidate transaction request sets may be considered in order from largest to smallest, depending on the space footprint of the transaction request sets.

Further, based on the verification results, determining a current target factor interval and a current target transaction request set also includes:
If the current target transaction request set cannot be determined from the remaining candidate transaction request sets corresponding to the current factor interval, perform the current target factor interval determination operation based on the remaining candidate factor intervals, and performing a determination operation of the current target transaction request set based on the candidate transaction request set corresponding to the current target factor interval obtained from the current target factor interval, wherein the remaining candidate factor intervals are the candidate factors other than the current factor interval Including intervals. Illustratively, the remaining candidate factor intervals may be considered according to an order of decreasing upper interval value or lower interval value.

That is, in the cyclic determination process of the target transaction request set, it is preferable to determine the current target transaction request set from among the candidate transaction request sets corresponding to the current target factor interval through multiple rounds of selection and verification. , then it is possible to determine the current target transaction request set among the candidate transaction request sets corresponding to the remaining candidate factor intervals, whereby the blockchain node determines the current target transaction request set High selection efficiency can be maintained even when multiple selection passes are required to Also, the transaction request set incentive factor can be used to characterize the incentive a blockchain node obtains by executing a transaction request within the transaction request set. The set of candidate transaction requests corresponding to the candidate factor interval with the largest lower bound value will bring a relatively large return to the blockchain node, and the current target transaction request in order of priority such as the current target factor interval, the remaining candidate factor intervals Sets can be selected. This can ensure the reasonable profit maximization of blockchain nodes and reduce the loss of profit as much as possible.

Based on the above technical scheme, if the incentive factor of the transaction request set is determined according to the bill of payment information and space occupation of the transaction requests in the transaction request set, the incentive factor is the price performance of the transaction request set ratio, and thus FIG. 4 shows, by way of example, schematic diagrams of an ordered graph of price-performance ratios and an ordered graph of candidate transaction request sets, and as a specific limitation of the embodiments of the present application, FIG. should not be interpreted. Here, the ordered graph of the price/performance ratio means that the candidate factor intervals of the transaction request set are rearranged according to the interval values such as the upper limit value and the lower limit value, for example, the candidate factor intervals 1, 2, . . . . . . N or price/performance intervals 1, 2, . . . . . . It means to obtain an ordered graph of intervals containing N, where N is an integer. The candidate factor interval and its corresponding candidate transaction request set are determined according to a key-value relationship, such as using the candidate factor interval as a key and the candidate transaction request set corresponding to the candidate factor interval as a key value. may be stored. Furthermore, a plurality of candidate transaction request sets corresponding to each candidate factor interval N or price/performance ratio interval N are sorted from the largest to the smallest according to the space occupation of each candidate transaction request set to obtain candidate transaction requests An ordered graph N of sets may be obtained. The ordered graph of each candidate transaction request set may also be stored in the form of key-value pairs, e.g., within the same candidate factor interval, keyed by the set sequence or number of each candidate transaction request set, and candidate transaction request set The space footprint of the request set can be stored as a key value. Each time a new candidate factor interval or price/performance ratio interval is created, or the set of candidate transaction requests within an interval is changed, the set of candidate transaction requests currently corresponding to that interval is updated according to the space footprint of the set. A sorted, ordered graph of candidate transaction request sets is obtained.

By comprehensively utilizing the ordered graph of the price-performance ratio and the ordered graph of the candidate transaction request set, it is possible to efficiently manage the transaction requests to be selected in the process of selecting the target transaction request set. It can lay the foundation for efficiently selecting a set of requirements.

FIG. 5 is a schematic diagram of the architecture of transaction request processing within the blockchain disclosed in the embodiments of the present application. As shown in FIG. 5 , during the current block generation cycle, the selected transaction requests may be stored in the blockchain network in the form of a selected transaction request list, and the dependencies between the selected transaction request sets. A directed acyclic graph is constructed based on and at least one transaction request set is determined. A candidate factor interval to which the transaction request set belongs is then determined based on the transaction request set's incentive factor. Then, by determining the current target factor interval using the constructed ordered graph of price-performance ratios and determining the current target transaction request set using the ordered graph of candidate transaction request sets, the blockchain node can improve the efficiency in selecting the transaction request set participating in the block generation process. In addition, with the determination of the current target transaction request set, the directed acyclic graph, the price-performance ordered graph, and the candidate transaction request set ordered graph are applied to the remaining selected target transaction requests in the blockchain network. It can be adaptively changed accordingly.

FIG. 6 is a flow chart of another intra-blockchain transaction request processing method disclosed in an embodiment of the present application, which is further optimized and extended based on the above technical scheme, and can be used in any of the above embodiments. may be combined with each of Specifically, FIG. 6 exemplifies the process of selecting the current target transaction request set in an embodiment of the present application, taking the execution process of a finite number of cycles as an example. should not be construed as a limitation of As shown in FIG. 6, the method may include the following.

At S601, an ordered graph of candidate transaction request sets corresponding to the current best price/performance interval is selected.
At S602, select the candidate transaction request set with the largest space occupation in the ordered graph of candidate transaction request sets.

In addition, in the ordered graph of the candidate transaction request set corresponding to the current best price-performance interval, we reduce the time cost for the blockchain node to select the transaction request, and balance the profit and time cost (computing power). The candidate transaction request set with the largest space occupancy is selected as the current target transaction request set with first priority to secure its own bookkeeping rights. This is because if the candidate transaction request set with the largest price-performance ratio is selected every time in the same price-performance interval, the maximum profit can be guaranteed, but there is a risk that the processing cost will be high. If 100 transactions with a very small space occupation are processed, the total profit is 100, while if the transaction with the largest space occupation is processed, the total profit is 99, but the space occupation is the largest. Processing the cost of large transactions is only 1% of the former in terms of time cost. In a competing blockout scenario, if a blockchain node spends all of its time cost on finding the optimal transaction with the highest return, it may lose its bookkeeping rights, so it is Both need to be balanced to achieve the effect of considering both.

In S603, it is determined whether or not the integrated space occupation amount exceeds the block space threshold.
If YES, step S604 is executed, and if NO, step S607 is executed.

In S604, it is determined whether there is a candidate set of transaction requests with a small space occupation that can be selected in the current ordering graph of candidate transaction request sets.

If YES, step S606 is executed; if NO, step S605 is executed.
At S605, select the ordered graph of the candidate transaction request set corresponding to the second highest price/performance interval.

At S606, select a candidate transaction request set that has a relatively small space occupation in the current candidate transaction request set ordered graph.

Specifically, in the ordered graph of the candidate transaction request set corresponding to the current best price-performance interval, select the candidate transaction request set with the second largest space occupancy, return step S603, and return the cumulative space occupancy exceeds the block space threshold, and circular execution is performed until a candidate transaction request set that can participate in the block generation process is selected. This ensures that the space occupancy of the cumulatively selected set does not exceed the block space threshold.

In S607, it is determined that the candidate transaction request set with the largest space occupation can be added to the block, the candidate transaction request set is deleted, and if the ordered graph of the corresponding candidate transaction request set is empty, the Delete the ordered graph of the corresponding candidate transaction request set and the corresponding price/performance interval.

If the cumulatively selected target transaction request set satisfies the block generation condition after multiple circular selections, for example, the total space occupancy of the cumulatively selected target transaction request set so far is the block space. A threshold is reached, ie, block space can be considered fully utilized, and cumulatively selected transaction requests can be executed to generate blocks.

According to the technical solution of the embodiment of the present application, in the process of selecting the target transaction request set, the ordered graph of the price-performance ratio and the ordered graph of the candidate transaction request set are comprehensively utilized to obtain the target transaction request It not only realizes effective management of From the perspective of profit acquisition, it can effectively guarantee the profit of blockchain nodes that have bookkeeping rights, and it is also an effective incentive strategy for blockchain nodes that actively try to acquire bookkeeping rights.

FIG. 7 is a schematic diagram of the structure of the transaction request processing device in the blockchain disclosed in the embodiment of the present application. It can be applied when selecting effectively and efficiently. The apparatus disclosed in the embodiments of the present application may be implemented in software and/or hardware, and may be integrated on blockchain nodes, which may be implemented on any electronic device with computing power. may be deployed to

As shown in FIG. 7, the transaction request processing device 700 in the blockchain disclosed in the embodiments of the present application may include a transaction request set determination module 701, a candidate factor interval determination module 702, and a transaction request set selection module 703. good.

The transaction request set determination module 701 aggregates selected target transaction requests having dependencies in the blockchain network to obtain at least one transaction request set.

Candidate factor interval determination module 702 determines a candidate factor interval to which a transaction request set belongs, said factor interval being used to measure the probability that said transaction request set participates in the block generation process.

The transaction request set selection module 703 selects a current target factor interval from the candidate factor intervals and selects a current target transaction request set to participate in the block generation process from the candidate transaction request sets corresponding to the current target factor interval. .
Preferably, candidate factor interval determination module 702 includes:
A match unit that matches the candidate factor interval to which the transaction request set belongs by traversing the upper and lower bounds of the created factor interval based on the incentive factor of the transaction request set, wherein the incentive factor is the a match unit used to characterize rewards obtained by executing transaction requests in the transaction request set;
and a reconstruction unit that, if not matched, reconstructs the candidate factor interval to which the transaction request set belongs.

Preferably, the transaction request collection selection module 703 includes:
an interval selection unit for selecting the current factor interval according to the interval value of the candidate factor interval;
a set selection unit for selecting the current transaction request set from the candidate transaction request sets corresponding to the current factor interval according to the space occupation by the candidate transaction request sets corresponding to the current factor interval;
a verification unit for verifying the current transaction request set based on the current transaction request set and a target transaction request set selected in the current block generation cycle;
and a determining unit for determining a current target factor interval and a current target transaction request set based on the verification results.

Preferably, the verification unit comprises:
a calculation subunit for calculating the total space footprint of the current transaction request set and the target transaction request set selected in the current block generation cycle;
a verification sub-unit for verifying the current transaction request set based on the relationship between the total space occupancy and the block space threshold.

Preferably, the determining unit
If the validation against the current transaction request set fails, the current factor interval is taken as the current target factor interval, and the current target transaction request set determination operation is performed based on the remaining candidate transaction request sets corresponding to the current factor interval. comprising a first decision subunit for executing;
wherein the remaining candidate transaction request sets include transaction request sets corresponding to the current factor interval other than the transaction request sets that failed validation;
The first determining sub-unit uses the current factor interval as the current target factor interval and the current transaction request set as the current target transaction request set if the verification against the current transaction request set passes.

Preferably, the determining unit further comprises:
If the current target transaction request set cannot be determined from the remaining candidate transaction request sets corresponding to the current factor interval, perform the current target factor interval determination operation based on the remaining candidate factor intervals, and a second determining subunit for performing a current target transaction request set determination operation based on the candidate transaction request set corresponding to the current target factor interval;
Here, the remaining candidate factor intervals contain candidate factor intervals other than the current factor interval.

Preferably, the set selection unit is specifically used as follows.
Reordering the space occupancy of the candidate transaction request sets from among the candidate transaction request sets corresponding to the current factor interval to determine the current transaction request set based on the results of the reordering; or the current factor interval. Among the candidate transaction request sets corresponding to , a candidate transaction request set whose space occupation amount is greater than the space occupation threshold is determined as the current transaction request set.

Preferably, the devices disclosed in the embodiments of the present application further comprise:
Before the candidate factor interval determination module 702 performs the operation of determining the candidate factor interval to which the transaction request set belongs, the incentive factors of the transaction request set are determined based on the bill of payment information and space occupancy of the transaction requests in the transaction request set. including an incentive factor determination module for determining the

Preferably, the transaction request collection decision module 701 includes:
a directed acyclic graph building unit for building a directed acyclic graph between the selected transaction requests based on the dependencies between the selected transaction requests in the blockchain network;
a transaction request set determination unit for aggregating selected target transaction requests with dependencies using a directed acyclic graph to obtain at least one transaction request set.

Preferably, the transaction request set includes a leaf transaction request and each non-leaf transaction request upon which the leaf transaction request depends, and leaf transaction requests within different transaction request sets are different.

Preferably, a consensus mechanism is deployed in the blockchain network for competing blockouts.

The blockchain transaction request processing device 700 disclosed in the embodiments of the present application can execute any of the blockchain transaction request processing methods disclosed in the embodiments of the present application, and the functional modules and have beneficial effects. What is not described in detail in the apparatus embodiment of the present application can be referred to the description in any method embodiment of the present application.

According to embodiments of the present application, embodiments of the present application also provide an electronic device and a readable storage medium.
As shown in FIG. 8, FIG. 8 is a block diagram of an electronic device for implementing the transaction request processing method in blockchain of an embodiment of the present application. Electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. . Electronic devices can also represent various forms of mobile devices, such as personal digital assistants, cell phones, smart phones, wearable devices, and other similar computing devices. The components, their connections and relationships, and their functionality illustrated herein are intended as examples only and as a limitation to the implementation of the embodiments of the application as described and/or claimed herein. is not intended to be

As shown in Figure 8, the electronic device has one or more processors 801, memory 802, and interfaces, including high speed and low speed interfaces, for connecting the components. The various components are interconnected using different buses and may be implemented on a common motherboard or in other forms as desired. The processor may process instructions for execution within the electronic device, which instructions may be stored in memory or displayed in memory to an external input/output device (e.g., a display device coupled to the interface) to provide a graphical user interface. (Graphical User Interface, GUI) contains instructions for displaying graphical information. In other embodiments, multiple processors and/or multiple buses and multiple memories may be used, along with multiple memories, as desired. Similarly, multiple electronic devices may be connected, each providing some of the required operations, such as a server array, a group of blade servers, or a multi-processor system. One processor 801 is shown in FIG. 8 as an example.

Memory 802 is a non-instantaneous computer-readable storage medium provided by embodiments of the present application. wherein said memory stores instructions executable by said at least one processor to cause said at least one processor to execute a transaction request processing method in a blockchain provided in embodiments of the present application; . The non-instantaneous computer-readable storage medium of the present application stores computer instructions used to cause a computer to perform the transaction request processing methods in a blockchain provided by the embodiments of the present application.

Memory 802 is a non-instantaneous computer-readable storage medium for storing non-instantaneous software programs, non-instantaneous computer-executable programs, and modules, such as programs corresponding to methods for processing transaction requests in a blockchain in embodiments herein. It can be used to store instructions/modules such as transaction request set determination module 701, candidate factor interval determination module 702, and transaction request set selection module 703 shown in FIG. 7 attached. The processor 801 performs various functional applications and data processing of the electronic device by executing non-instantaneous software programs, instructions and modules stored in the memory 802 to implement the blockchain in the method embodiments described above. Implement the transaction request processing method within.

The memory 802 may include a program storage area and a data storage area, where the program storage area may store an operating system, application programs required for at least one function, and the data storage area may be used to operate the electronic device. You may store the data etc. which were produced by. Additionally, memory 802 may include high speed random access memory and may also include non-instantaneous memory such as at least one disk memory device, flash memory device, or other non-instantaneous solid state memory device. good. In some embodiments, memory 802 preferably includes memory remotely located relative to processor 801, and these remote memories are connected via a network to the blockchain of the present embodiments. may be connected to an electronic device for implementing the transaction request processing method of . Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

An electronic device for implementing the transaction request processing method in a blockchain in embodiments of the present application may also include an input device 803 and an output device 804 . The processor 801, the memory 802, the input device 803 and the output device 804 may be connected via a bus or may be connected in other forms, and connection via a bus is taken as an example in FIG. there is

The input device 803 receives input numerical information or character information and key signals related to user settings and functional control of electronic devices for implementing the transaction request processing method in the blockchain in the embodiments of the present application. Input may be generated by input devices such as touch screens, keypads, mice, trackpads, touchpads, indicator sticks, one or more mouse buttons, trackballs, joysticks, and the like. The output device 804 may include a display device, a supplemental lighting device, a haptic feedback device, etc., where the supplemental lighting device is, for example, a Light Emitting Diode (LED), and the haptic feedback device is, for example, For example, a vibration motor. The display device includes, but is not limited to, a liquid crystal display (LCD), an LED display, a plasma display, and the like. In some embodiments, the display device may be a touch screen.

Various embodiments of the systems and techniques described herein may be digital electronic circuit systems, integrated circuit systems, application specific integrated circuits (ASICs), computer hardware, firmware, software, and/or can be implemented in a combination of These various embodiments may include: embodied in one or more computer programs, which are executed and/or interpreted on a programmable system including at least one programmable processor; The programmable processor receives data and instructions from the storage system, at least one input device, and at least one output device, and transmits data and instructions to the storage system, the at least one input device, and the at least one output device. It may be a dedicated or general purpose programmable processor that can be transferred to the device.

These computer programs, also called programs, software, software applications, or code, contain machine instructions for programmable processors and use high-level procedural and/or object-oriented programming languages, and/or assembly/machine language. can be used to implement these computer programs. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, or device used to provide machine instructions and/or data to a programmable processor. and/or apparatus, eg, magnetic disk, optical disk, memory, Programmable Logic Device (PLD), including a machine-readable medium for receiving machine instructions, which are machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and/or data to a programmable processor.

To provide user interaction, the systems and techniques described herein use a display device (e.g., a Cathode Ray Tube (CRT) or LCD monitor) to display information to the user. and a keyboard and pointing device (eg, a mouse or trackball) for a user to provide input to the computer. Other types of devices may also be used to provide interaction with the user, e.g., the feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or There may be haptic feedback, and input from the user may be received in any form, such as acoustic, speech, or haptic input.

The systems and techniques described herein may be computing systems that include back-end components (e.g., data servers), computing systems that include middleware components (e.g., application servers), or computing systems that include front-end components. system (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and techniques described herein), or such may be implemented in a computing system including any combination of back-end components, middleware components, or front-end components. The components of the system may be interconnected through any form or medium of digital data communication, eg, a communication network. Examples of communication networks include Local Area Networks (LANs), Wide Area Networks (WANs), the Internet, blockchain networks, and the like.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. A client-server relationship is created by computer programs running on corresponding computers and having a client-server relationship to each other.

According to the technical solution of the embodiment of the present application, the block generation process according to the circular logic of selecting the current target factor interval and selecting the current target transaction request set from the candidate transaction request set corresponding to the current target factor interval. A target transaction request set participating in is cumulatively determined after at least one circular selection, and finally a block is generated by executing the transaction requests in the cumulatively determined target transaction request set; Here, there is a dependency relationship between the transaction requests in the target transaction request set, which improves the rationality and selection efficiency of transaction request selection by blockchain nodes in the block generation process, and improves the blockout efficiency. be able to.

It should be understood that the order may be changed and steps added/deleted from the various embodiments of the processes described above. For example, as long as the desired result of the technical solution disclosed in this application is achieved, each step described in this application is not limited to this specification, and may be performed in parallel or sequentially. may be performed, and may be performed in a different order.

The above specific embodiments do not constitute a limitation of the protection scope of this disclosure. It should be understood by those skilled in the art that various modifications, combinations, subcombinations and permutations may be made depending on design requirements and other factors. Modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of this disclosure shall fall within the protection scope of this disclosure.

Claims (14)

An intra-blockchain transaction request processing method executed by an intra-blockchain transaction request processing device, comprising:
aggregating selected target transaction requests having dependencies in a blockchain network to obtain at least one set of transaction requests;
determining a candidate factor interval to which the transaction request set belongs based on attributes of the transaction request set, wherein the factor interval is used to measure the probability that the transaction request set participates in a block generation process; and
selecting a current target factor interval from the candidate factor intervals and selecting a current target transaction request set to participate in block generation process from the candidate transaction request set corresponding to the current target factor interval; A transaction request processing method in a blockchain, characterized by: Determining a candidate factor interval to which the transaction request set belongs comprises:
matching a candidate factor interval to which the transaction request set belongs by traversing upper and lower bounds of a created factor interval based on an incentive factor of the transaction request set, wherein the incentive factor is a block chain a step used to characterize the incentive a node obtains from executing a transaction request in said transaction request set;
and if there is no match, reconstructing the candidate factor interval to which the transaction request set belongs. selecting a current target factor interval from the candidate factor intervals and selecting a current target transaction request set to participate in a block generation process from the candidate transaction request set corresponding to the current target factor interval;
selecting a current factor interval according to an interval value of said candidate factor interval;
selecting a current transaction request set from the candidate transaction request sets corresponding to the current factor interval according to the space occupied by the candidate transaction request sets corresponding to the current factor interval;
verifying the current transaction request set based on the current transaction request set and a target transaction request set selected in a current block generation cycle;
and determining the current target factor interval and the current target transaction request set based on the verification results. verifying the current transaction request set based on the current transaction request set and a target transaction request set selected in a current block generation cycle;
calculating the total space footprint of the current transaction request set and a target transaction request set selected in the current block generation cycle;
and verifying the current set of transaction requests based on the relationship between the total space footprint and the block space threshold. determining the current target factor interval and the current target transaction request set based on the verification results;
if the validation against the current set of transaction requests fails, set the current factor interval as the current target factor interval, and determine the current target transaction request based on the remaining candidate transaction request sets corresponding to the current factor interval; including the step of performing a set decision operation;
5. The method of claim 3 or 4, wherein the remaining candidate transaction request sets include transaction request sets corresponding to the current factor interval other than the transaction request sets that failed validation. Determining the current target factor interval and the current target transaction request set based on the verification results also includes:
If the current target transaction request set cannot be determined from the remaining candidate transaction request sets corresponding to the current factor interval, performing the current target factor interval determination operation based on the remaining candidate factor intervals; performing the current target transaction request set determination operation based on the candidate transaction request sets corresponding to the current target factor interval determined in
6. The method of claim 5, wherein the remaining candidate factor intervals include candidate factor intervals other than the current factor interval. selecting a current transaction request set from the candidate transaction request sets corresponding to the current factor interval according to a space occupation by the candidate transaction request sets corresponding to the current factor interval;
reordering the space occupancy of the candidate transaction request sets from among the candidate transaction request sets corresponding to the current factor interval to determine the current transaction request set based on the results of the reordering; or determining, as the current transaction request set, a candidate transaction request set whose space occupancy is greater than a space occupancy threshold from among the candidate transaction request sets corresponding to the current factor interval. 4. The method of claim 3. Before determining the candidate factor interval to which the transaction request set belongs, the method further comprises determining an incentive factor for the transaction request set based on payment instrument information and space occupancy of transaction requests in the transaction request set. 3. The method of claim 2, comprising: aggregating selected target transaction requests having dependencies in the blockchain network to obtain at least one set of transaction requests;
building a directed acyclic graph among the selected transaction requests based on the dependencies between the selected transaction requests in the blockchain network;
and aggregating selected transaction requests with dependencies using the directed acyclic graph to obtain the at least one set of transaction requests. Method. 2. The method of claim 1, wherein a consensus mechanism for competing production of the blocks is deployed in the blockchain network. a transaction request set determination module that aggregates selected target transaction requests having dependencies in a blockchain network to obtain at least one transaction request set;
A candidate factor interval determination module for determining a candidate factor interval to which said transaction request set belongs based on attributes of said transaction request set, said factor interval measuring a probability that said transaction request set participates in a block generation process. a candidate factor interval determination module used to
A transaction request set selection module for selecting a current target factor interval from said candidate factor intervals and selecting a current target transaction request set to participate in a block generation process from said candidate transaction request sets corresponding to said current target factor interval. A transaction request processing device in a blockchain, characterized by comprising: at least one processor;
a memory communicatively connected to the at least one processor;
The memory stores instructions that are executable by the at least one processor, the instructions that the at least one processor executes the transaction request processing method in a blockchain according to any one of claims 1 to 10. An electronic device, characterized in that it is executed by said at least one processor to enable execution. A non-instantaneous computer-readable storage medium storing computer instructions for causing a computer to perform the transaction request processing method in a blockchain according to any one of claims 1-10. A program characterized in that, when executed by a processor in a computer, it implements the transaction request processing method in a blockchain according to any one of claims 1 to 10.

Images