Transaction screening and block generation method, device and storage medium

Abstract

The present invention provides a transaction screening and block generation method, device and storage medium, the method comprising: calculating the height of each first block that the current node should participate in the consensus according to the preconfigured block consensus rule; calculating whether the first transaction should be stored by the current node according to the preconfigured transaction storage rule matching the block consensus rule: if yes, then calculating the second block height that should package the first transaction according to the preconfigured transaction packaging rule matching the block consensus rule, and storing the first transaction to the first queue to be packaged at the second block height; if no, then deleting the first transaction; in response to obtaining the packaging right of the third block at the third block height, generating a third block according to each second transaction in the second queue to be packaged at the third block height and broadcasting it to other blockchain nodes. The present application further improves throughput.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically to a transaction screening and block generation method, device and storage medium. Background Art

[0002] In the patent application previously filed by the applicant (see CN2019106074995), the throughput is improved by processing transaction checks and block confirmations in parallel.

[0003] In the above mechanism, the specified height information included in the transaction will make tx1 huge, while the size of a block is constant. The above mechanism will reduce the number of transactions that can be stored in a block, and on the other hand reduce the throughput. Summary of the invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a transaction screening and block generation method, device and storage medium that further improve the throughput.

[0005] In a first aspect, the present invention provides a transaction screening and block generation method applicable to a blockchain node, comprising:

[0006] Calculate the height of each first block that the current node should participate in consensus according to the pre-configured block consensus rule; wherein the block consensus rule includes the first public information of the current node;

[0007] receiving a first transaction;

[0008] Calculate whether the first transaction should be stored by the current node according to the preconfigured transaction storage rules that match the block consensus rules:

[0009] If yes, then the second block height in which the first transaction should be packaged is calculated according to a preconfigured transaction packaging rule that matches the block consensus rule; wherein, the transaction storage rule and the transaction packaging rule include the second public information of the first transaction, and the difference between the first block height and the current block height is greater than the first value; and,

[0010] Storing the first transaction in a first to-be-packaged queue at a second block height;

[0011] If not, delete the first transaction;

[0012] In response to obtaining the packaging right of the third block at the third block height, a third block is generated according to each second transaction in the second to-be-packaged queue at the third block height and broadcasted to other blockchain nodes, so that other blockchain nodes:

[0013] When the third block height is the block height that should participate in the consensus, determine whether the third block height is the block height that the current node should participate in the consensus according to the block consensus rules:

[0014] If yes, then the following steps are performed for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, then the execution of the second transaction fails;

[0015] Among them, the steps of receiving the first transaction to deleting the first transaction and the step of generating a third block according to each second transaction in the second to-be-packaged queue at the third block height and broadcasting it to other blockchain nodes are executed in parallel.

[0016] In a second aspect, the present invention also provides a device comprising one or more processors and a memory, wherein the memory contains instructions executable by the one or more processors so that the one or more processors execute the transaction screening and block generation methods provided according to various embodiments of the present invention.

[0017] In a third aspect, the present invention further provides a storage medium storing a computer program, which enables a computer to execute the transaction screening and block generation methods provided according to various embodiments of the present invention.

[0018] The transaction screening and block generation methods, devices and storage media provided by many embodiments of the present invention further improve throughput by calculating the heights of each first block that the current node should participate in the consensus according to a preconfigured block consensus rule; calculating whether the first transaction should be stored by the current node according to a preconfigured transaction storage rule that matches the block consensus rule: if yes, then calculating the second block height that the first transaction should be packaged according to the preconfigured transaction packaging rule that matches the block consensus rule, and storing the first transaction in the first queue to be packaged at the second block height; if no, then deleting the first transaction; in response to obtaining the packaging right of the third block at the third block height, generating a third block according to each second transaction in the second queue to be packaged at the third block height and broadcasting it to other blockchain nodes. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Other features, objects and advantages of the present application will become more apparent by reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0020] Figure 1 A flowchart of a transaction screening and block generation method provided by one embodiment of the present invention.

[0021] Figure 2 for Figure 1 A flow chart of a preferred embodiment is shown.

[0022] Figure 3 for Figure 1 A flow chart of another preferred embodiment is shown.

[0023] Figure 4 A schematic diagram of the structure of a device provided in one embodiment of the present invention. DETAILED DESCRIPTION

[0024] The present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the relevant invention, rather than to limit the invention. It is also necessary to explain that, for ease of description, only the parts related to the invention are shown in the accompanying drawings.

[0025] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0026] Figure 1 A flowchart of a transaction screening and block generation method provided by an embodiment of the present invention. Figure 1 As shown, in this embodiment, the present invention provides a transaction screening and block generation method applicable to a blockchain node, comprising:

[0027] S11: Calculate the heights of the first blocks that the current node should participate in consensus according to the pre-configured block consensus rules; wherein the block consensus rules include the first public information of the current node;

[0028] S12: receiving a first transaction;

[0029] S131: Calculate whether the first transaction should be stored by the current node according to the preconfigured transaction storage rules that match the block consensus rules:

[0030] If yes, then execute step S132: calculate the second block height that should package the first transaction according to the preconfigured transaction packaging rule that matches the block consensus rule; wherein, the transaction storage rule and the transaction packaging rule include the second public information of the first transaction, and the difference between the second block height and the current block height is greater than the first value; and,

[0031] S133: Storing the first transaction in a first to-be-packaged queue at a second block height;

[0032] If not, then execute step S134: delete the first transaction;

[0033] S14: In response to obtaining the packaging right of the third block at the third block height, a third block is generated according to each second transaction in the second to-be-packaged queue at the third block height and broadcasted to other blockchain nodes, so that other blockchain nodes:

[0034] When the third block height is the block height that should participate in the consensus, determine whether the third block height is the block height that the current node should participate in the consensus according to the block consensus rules:

[0035] If yes, then the following steps are performed for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, then the execution of the second transaction fails;

[0036] Among them, the steps of receiving the first transaction to deleting the first transaction and the step of generating a third block according to each second transaction in the second to-be-packaged queue at the third block height and broadcasting it to other blockchain nodes are executed in parallel.

[0037] Specifically, the first public information is the node hash of the current node, and the second public information is the first full hash of the first transaction. S11 includes "obtaining the first M bits of the node hash of the current node, and calculating the first N-ary number according to the first M bits; determining the fourth block heights whose second N-ary number is the same as the first N-ary number as the first block heights; wherein the calculation method of the second N-ary number is: (h mod N^M)===>>>(x2)2, (x2)2=(x1)2, h is the fourth block height, (x1)2 is the first N-ary number, and (x2)2 is the second N-ary number"; and S131 includes "obtaining the second M bits of the first full hash, and calculating the third N-ary number according to the second M bits; determining whether the third N-ary number is the same as the first N-ary number"; and S132 includes "calculating the fifth block height; wherein the calculation method of the fifth block height is: min(h1)mod N^M===>>>(x3)2, min(h1)>current block height+first value+1, min(h1) is the fifth block height, (x3)2 is the third N-ary number; and, the fifth block height is determined as the second block height"; and, judging whether the third block height is the block height that the current node should participate in consensus according to the block consensus rule includes "obtaining the first M bits and calculating the first N-ary number; calculating the fifth N-ary number; wherein the calculation method of the fifth N-ary number is: (h2 mod N^M)===>>>(x5)2, h2 is the third block height, (x5)2 is the fifth N-ary number; determine whether the first N-ary number and the fifth N-ary number are the same"; and, determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule: if not, the failure to execute the second transaction includes "obtaining the third M bits of the second full hash of the second transaction, calculating the sixth N-ary number according to the third M bits; calculating the second remainder of the third block height and the second value; converting the second remainder into the seventh N-ary number; when the sixth N-ary number and the seventh N-ary number are different, the failure to execute the second transaction" as an example;

[0038] Assume that the current blockchain has nodes N1 to N24, the current node is N1, the first value is 5, M is the first 3, and N is 2; the first 3 binary digits of the node hash of N1 to N3 are 000, the first 3 binary digits of the node hash of N4 to N6 are 001, the first 3 binary digits of the node hash of N7 to N9 are 010... The first 3 binary digits of the node hash of N22 to N24 are 111; N1 obtains tx1 and tx2 successively; the first 3 binary digits of the full hash of tx1 are 000, and the first 3 binary digits of the full hash of tx2 are 111; the current block height is 100, and the third block height is 112;

[0039] N1 executes step S11, obtains the first 3 bits of N1's node hash, and calculates the binary number based on the first 3 bits, which is 000; since the remainder of 0, 8, 16, ... and 8 is 0, and the binary number of 0 is 000, 0, 8, 16, ... are the block heights that N1 should participate in the consensus;

[0040] Therefore, 0, 8, 16... are the block heights that N1~N3 should participate in the consensus, 1, 9, 17... are the block heights that N4~N6 should participate in the consensus, and 7, 15, 23... are the block heights that N22~N24 should participate in the consensus.

[0041] For tx1:

[0042] N1 executes step S12 to receive tx1;

[0043] N1 executes step S131 to obtain the first 3 binary digits of the full hash of tx1, which is 000;

[0044] Since both binary numbers are 000, N1 executes step S132 to calculate the block height that should package tx1; the block height should be greater than 106, and the binary number of the remainder of the block height and 8 should also be 000 and closest to 106, so the block height is 112;

[0045] N1 executes step S133 and stores tx1 in the waiting-for-packaging queue at block height 112;

[0046] For tx2:

[0047] N1 executes step S12 to receive tx2;

[0048] N1 executes step S131 to obtain the first 3 binary digits of the full hash of tx2, which is 111;

[0049] Since the two binary numbers are different, N1 executes step S134 and deletes tx2;

[0050] In response to obtaining the packaging right of the block with block height 112, N1 executes step S14, generates block (112) according to each transaction in the queue to be packaged with block height 112, and broadcasts it to N2-N24; assuming that each transaction in the queue to be packaged with block height 112 is tx1, tx3-tx10;

[0051] Since only N2 and N3 should participate in the consensus of block height 112, N2 and N3 obtain the first binary number of N1, which is 000;

[0052] N2 and N3 calculate the fifth binary number, 112 mod 8 = 0, the binary number of 0 is 000;

[0053] Since both binary numbers are 000, N1 should participate in the consensus of 112;

[0054] N2 and N3 perform the following steps on tx1 and tx3 to tx10 respectively:

[0055] Take tx1 as an example;

[0056] Get the first 3 binary digits of the full hash of tx1, which is 000;

[0057] Calculate the remainder of the block height 112 and 8, the remainder is 0;

[0058] The binary number of 0 is also 000;

[0059] Since the two binary numbers are the same, the verification passes and tx1 is executed;

[0060] tx3~tx10 are similar to tx1 and will not be described here;

[0061] Assume that N1 adds tx10 to the queue to be packaged at block height 112, and the first three binary digits of the full hash of tx10 are not 000, then N2 and N3 fail to execute tx10;

[0062] Among them, steps S12 to S134 are executed in parallel with step S14.

[0063] Those skilled in the art should understand that when it is found that the first 3 binary digits of the full hash of tx10 are not 000, other blockchain nodes can record the illegal behavior of N1, for example, increase the number of illegal behaviors of N1 by one to update the number of illegal behaviors; when the number of illegal behaviors of N1 reaches a certain threshold, no block packaged by N1 will be received; further, a reporting transaction reporting N1 can also be generated, and the reporting transaction can include the transaction hash of the transaction packaged by N1 that failed the verification, and when the reporting transaction is successfully executed, N1 will be deducted a certain fine.

[0064] In more embodiments, the first value, M, and N can be configured according to actual needs to obtain the same technical effect. However, those skilled in the art should understand that as the performance of blockchain becomes stronger and stronger, the time required for steps such as block generation and consensus becomes shorter and shorter, and the first value should not be configured as a very small value. When the first value is configured as a very small value, it is easy to cause the problem that tx1 cannot be packaged in time.

[0065] In more embodiments, the first public information and the second public information may also be configured according to actual needs. For example, the first public information may be configured as a node public key, and the second public information may be configured as a transaction hash to achieve the same technical effect.

[0066] In more embodiments, S11 can also be configured according to actual needs, for example, configured to, for example, convert the first public information of N1 into a decimal number, and obtain the last digit of the converted decimal number, for example, 9, then 9, 19, 29... are the block heights that N1 should participate in the consensus; correspondingly, the methods of S131 and S132 should also be configured. At this time, N1 should also calculate whether the last digit of the second public information of tx1 converted into a decimal number is the same as 9; and, if they are the same, find the block height that should package tx1, that is, find the block height with the smallest tail of 9 greater than 106, that is, 109; assuming that block (109) is still generated by N1, and N2 and N3 are still blockchain nodes participating in the 109 consensus, then N2 and N3 still need to verify whether 109 is the block height that N1 should participate in the consensus. If yes, it is also necessary to verify whether the last digit of the decimal of the first three digits of each transaction of block (109) is 9; the same technical effect can be achieved.

[0067] In more embodiments, all blockchain nodes can calculate and save the first N-ary number of each blockchain node in advance, which can speed up the step of "determining whether the third block height is the block height that the current node should participate in consensus according to the block consensus rules".

[0068] Compared with the patent application previously filed by the applicant, the transactions in this application do not include specified height information, and the transactions can be packaged in different blocks in a dispersed manner, further improving the throughput.

[0069] Preferably, the above method further comprises:

[0070] Send the block data of the third block that has been agreed upon to the corresponding central server for storage;

[0071] After a period of time, the block data of the third block that has been agreed upon is deleted.

[0072] At this point, the blockchain node only stores the status data of the third block that has been agreed upon.

[0073] The above embodiment stores the status data and the block data separately, thus solving the problem of slow IO storage.

[0074] Further preferably, storing the first transaction in the first to-be-packaged queue at the second block height includes:

[0075] Storing the first transaction in a first to-be-packaged queue at a second block height;

[0076] When the difference between the second block height and the current block height is not greater than the first value, each transaction in the first queue to be packaged is sent to the corresponding central server, so that the corresponding central server generates a Merkle root according to each transaction in the first queue to be packaged;

[0077] When receiving the block data of the third block, the central server needs to determine whether the Merkle root generated according to each transaction in the second to-be-packaged queue is the same as the Merkle root in the block data: if yes, the block data is stored.

[0078] Figure 2 for Figure 1 A flow chart of a preferred embodiment is shown in FIG. Figure 2 As shown, in a preferred embodiment, S132 includes:

[0079] S1321: Identify, according to the pre-packaging identifier of the first transaction, whether the first transaction is a first-type transaction with a specified block height or a second-type transaction with an unspecified block height;

[0080] S13221: When the first transaction is a first-type transaction, the second block height at which the first transaction should be packaged is calculated according to a preconfigured transaction packaging rule that matches the block consensus rule;

[0081] S13222: When the first transaction is a second-type transaction, store the first transaction in an instant packaging queue;

[0082] S14 includes:

[0083] S141: In response to obtaining the packaging right of the third block of the third block height, a third block is generated according to each second transaction in the second to-be-packaged queue of the third block height, and several transactions in the immediate packaging queue, and broadcasted to other blockchain nodes.

[0084] Specifically, assume that N1 also receives tx11 and tx12, the first three bits of tx11 are 000, and a pre-packaging flag is configured, while tx12 is not configured with a pre-packaging flag;

[0085] Then N1 calculates the block height at which tx11 should be packaged; and N1 stores tx12 in the immediate packaging queue.

[0086] The above embodiments and Figure 1 The difference between the illustrated embodiments is that the above embodiments also include instant packaged transactions, enriching the user experience.

[0087] Figure 3 for Figure 1 Flow chart of another preferred embodiment shown in FIG. Figure 3 As shown, in a preferred embodiment, S132 includes:

[0088] S1325: Identify, based on whether the first handling fee of the first transaction is lower than a third value, whether the first transaction is a first type transaction with a specified block height or a second type transaction with an unspecified block height;

[0089] S13261: When the first transaction is a first-type transaction, the second block height at which the first transaction should be packaged is calculated according to a preconfigured transaction packaging rule that matches the block consensus rule;

[0090] S13262: When the first transaction is a second-type transaction, store the first transaction in an instant packaging queue;

[0091] S14 includes:

[0092] S142: In response to obtaining the packaging right of the third block at the third block height, a third block is generated according to each second transaction in the second to-be-packaged queue at the third block height, and several transactions in the immediate packaging queue, and broadcasted to other blockchain nodes.

[0093] Specifically, assume that the third value is 100AAA; N1 also receives tx13 and tx14, the first 3 digits of tx13 are 000, and the transaction fee is 150AAA, while the transaction fee of tx12 is 1AAA;

[0094] Then N1 calculates the block height at which tx14 should be packaged; and N1 stores tx13 in the immediate packaging queue.

[0095] The above embodiments and Figure 2 The difference between the illustrated embodiments is that, in the above embodiments, transactions do not need to be configured with pre-packaged identifiers, the transaction size is smaller, and the number of transactions that can be stored in a block is increased, further improving the throughput.

[0096] Preferably, in a preferred embodiment, S131 includes:

[0097] S1311: Verify whether the signature information of the first transaction is correct, and verify whether the first transaction is executable:

[0098] S1312: When all the above verifications are passed, calculating whether the first transaction should be stored by the current node according to a preconfigured transaction storage rule that matches the block consensus rule;

[0099] S1313: When at least one of the above verifications fails, deleting the first transaction;

[0100] S14 includes:

[0101] Perform the following operations on each second transaction:

[0102] S1431: Determine whether the third transaction initiator address of the third transaction is the same as the second transaction initiator address of the second transaction in any block generated from the first time the second transaction is added to the second to-be-packaged queue to the time the previous block at the third block height is generated:

[0103] If yes, then execute step S1432: verify whether the second transaction is feasible when executing the second transaction;

[0104] If not, execute step S1433: omit the step of verifying whether the second transaction is feasible when executing the second transaction.

[0105] Take tx1 as an example;

[0106] N1 executes step S1311 to verify whether the signature information of tx1 is correct and whether tx1 is executable:

[0107] Assuming that the above verification of tx1 passes, N1 executes step S1312 to calculate whether tx1 should be stored by the current node according to the preconfigured transaction storage rules that match the block consensus rules;

[0108] Assuming that the transaction initiator address of tx1 is addr(A), N1 executes step S1431 to determine whether there is a third transaction initiator address of the third transaction that is the same as addr(A) in any block generated from the first time tx1 is added to the queue to be packaged to the time block(111) is generated (i.e., block(100) to block(111));

[0109] If the transaction initiator address of each transaction in block (100) to block (111) is not addr (A), N1 executes step S1433 and omits the step of verifying whether tx1 is executable when executing tx1;

[0110] If the transaction initiator address of any transaction in block (100) to block (111) is addr (A), N1 executes step S1432. When executing tx1, it is still necessary to verify whether tx1 is executable.

[0111] The above embodiments can reduce some verification operations and speed up the consensus efficiency of the block.

[0112] Further preferably, step 1432 may also be configured according to actual needs, for example, to determine whether the third transaction is a transaction type that requires a transfer: if yes, verify whether the second transaction is feasible when executing the second transaction; if no, omit the step of verifying whether the second transaction is feasible when executing the second transaction.

[0113] The above embodiments can further reduce some verification operations and further speed up the consensus efficiency of the block.

[0114] Further preferably, step S1432 can also be configured according to actual needs, for example, to determine whether there is a transaction recipient address of the fifth transaction that is the same as the second transaction initiator address of the second transaction in any block generated from the first moment when the second transaction is added to the second queue to be packaged to the generation moment of the previous block at the second block height: if yes, then add the transaction amounts of each fifth transaction to calculate the first total, and add the transaction amounts of each third transaction to calculate the second total, and determine whether the first total is lower than the second total: if yes, then verify whether the second transaction is feasible when executing the second transaction; if no, then omit the step of verifying whether the second transaction is feasible when executing the second transaction.

[0115] The above embodiments can further reduce some verification operations and further speed up the consensus efficiency of the block.

[0116] Preferably, the to-be-packaged queues of each blockchain node are configured with the same transaction sorting method, and when the difference between the third block height and the current block height is a fourth value, each blockchain node participating in the third block height consensus pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the third block height, wherein the fourth value is not greater than the first value;

[0117] The following steps are performed for each second transaction: according to the transaction packaging rule, it is determined whether the second transaction should be packaged at the third block height: if not, the failure to execute the second transaction includes:

[0118] Determine whether the second Merkle root of the third block is the same as the first Merkle root:

[0119] If yes, then omit the following steps for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, then execute the second transaction failure step;

[0120] If not, the following steps are performed for each second transaction: Determine whether the second transaction should be packaged at the third block height according to the transaction packaging rules: If not, the execution of the second transaction fails.

[0121] Specifically, assuming that the fourth value is 4, when the block height is 108, N2 and N3 pre-generate a Merkleroot (112) of the block height 112 according to each second transaction;

[0122] When N2 and N3 receive block(112), if the Merkleroot (112)' of block(112) is the same as merkleroot(112), it means that the transaction and the execution result of the transaction are completely consistent, then N2 and N3 omit the step of "performing the following steps for each second transaction: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule: if not, executing the second transaction failure step";

[0123] If merkleroot(112)' is different from merkleroot(112), N2 and N3 still need to execute the step of "perform the following steps for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rules: if not, execute the second transaction failure step".

[0124] In more embodiments, the fourth value can be configured according to actual needs to achieve the same technical effect.

[0125] The above embodiments further speed up the consensus efficiency of blocks.

[0126] Preferably, the to-be-packaged queues of each blockchain node are configured with the same transaction sorting method, and when the difference between the third block height and the current block height is a fourth value, each blockchain node participating in the third block height consensus pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the third block height, wherein the fourth value is not greater than the first value;

[0127] Generating a third block according to each second transaction in the second to-be-packaged queue at the third block height and broadcasting it to other blockchain nodes includes:

[0128] Generate a third block according to each second transaction in the second to-be-packaged queue at the third block height;

[0129] Broadcasting the second Merkle root of the third block and the second transaction hash list including each second transaction to other blockchain nodes;

[0130] The following steps are performed for each second transaction: according to the transaction packaging rule, it is determined whether the second transaction should be packaged at the third block height: if not, the failure to execute the second transaction includes:

[0131] Determine whether the second Merkle root of the third block is the same as the first Merkle root:

[0132] If yes, the following steps are omitted for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, the execution of the second transaction fails;

[0133] If not, then request the current blockchain node for the second transactions corresponding to the missing second transaction hashes; and,

[0134] The following steps are performed for each requested second transaction: determine whether the requested second transaction should be packaged at the third block height according to the transaction packaging rule: if not, the execution of the requested second transaction fails.

[0135] The difference between the above embodiment and the previous embodiment is that N1 broadcasts not block (112) but the transaction hash list of each transaction of merkleroot (112)' and block (112);

[0136] If the Merkleroot(112)' of block(112) is the same as merkleroot(112), it means that the transaction and the execution result of the transaction are completely consistent, and N2 and N3 omit the step of "performing the following steps for each second transaction: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if not, the execution of the second transaction fails";

[0137] If merkleroot(112)' is different from merkleroot(112), N2 and N3 request the missing second transaction from N1. After receiving the missing second transaction, N2 and N3 perform the following steps for each requested second transaction: Determine whether the requested second transaction should be packaged at the third block height according to the transaction packaging rules: If not, the execution of the requested second transaction fails.

[0138] The above embodiment reduces the amount of data broadcast by N1 and further increases the throughput.

[0139] Preferably, the blockchain includes consensus nodes and non-consensus nodes, wherein the non-consensus nodes do not participate in the block consensus;

[0140] Generating a third block according to each second transaction in the second to-be-packaged queue at the third block height and broadcasting it to other blockchain nodes includes:

[0141] Generate a third block according to each second transaction in the second to-be-packaged queue at the third block height and broadcast it to other consensus nodes;

[0142] The third block is also used by other consensus nodes:

[0143] When the third block height is a block height that should not participate in the consensus, delete the third block;

[0144] The above method further includes:

[0145] The third block reached by consensus is broadcast to consensus nodes and non-consensus nodes that should not participate in the consensus at the third block height.

[0146] In more embodiments, the third block reached by consensus may not be broadcast to non-consensus nodes according to actual needs, so non-consensus nodes do not need to store blocks locally, which is more convenient.

[0147] In more embodiments, it is also possible to configure whether non-consensus nodes need to participate in the screening and broadcasting of transactions according to actual needs; when non-consensus nodes also participate in the screening of transactions, some consensus nodes (for example, N4, N4 is a consensus node whose block height is temporarily lower than the current block height) still want to participate in the generation of the latest block, then N24 can request some to-be-packaged queue information from other consensus nodes, or non-consensus nodes (the first N-ary number of other consensus nodes, or non-consensus nodes should be the same as the first N-ary number of N4); in this way, N4 can generate block (113) according to the requested to-be-packaged queue information of 113 and the block public information of 112 (the block public information of 112 can be obtained from other consensus nodes) when obtaining the packaging right of 113.

[0148] Figure 4 A schematic diagram of the structure of a device provided in one embodiment of the present invention.

[0149] like Figure 4 As shown, as another aspect, the present application also provides a device 400, including one or more central processing units (CPU) 401, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 402 or the program loaded from the storage part 408 to the random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the device 400 are also stored. The CPU 401, the ROM 402, and the RAM 403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0150] The following components are connected to the I / O interface 405: an input section 406 including a keyboard, a mouse, etc.; an output section 407 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN card, a modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the I / O interface 405 as needed. A removable medium 411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 410 as needed, so that a computer program read therefrom is installed into the storage section 408 as needed.

[0151] In particular, according to an embodiment of the present disclosure, the method described in any of the above embodiments can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program tangibly contained on a machine-readable medium, and the computer program includes a program code for executing any of the above methods. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 409, and / or installed from a removable medium 411.

[0152] As another aspect, the present application also provides a computer-readable storage medium, which may be a computer-readable storage medium included in the apparatus of the above embodiment; or a computer-readable storage medium that exists independently and is not assembled into the device. The computer-readable storage medium stores one or more programs, which are used by one or more processors to execute the method described in the present application.

[0153] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be realized by a dedicated hardware-based system that performs a specified function or operation, or can be realized by a combination of dedicated hardware and computer instructions.

[0154] The units or modules involved in the embodiments described in the present application may be implemented by software or by hardware. The units or modules described may also be arranged in a processor. For example, each of the units may be a software program arranged in a computer or a mobile smart device, or may be a separately configured hardware device. The names of these units or modules do not, in some cases, constitute limitations on the units or modules themselves.

[0155] The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the concept of the present application. For example, the above features are replaced with (but not limited to) technical features with similar functions disclosed in the present application.

Claims

1. A transaction screening and block generation method, characterized in that: Applicable to a blockchain node, the method comprises: Calculate the heights of the first blocks that the current node should participate in consensus according to the preconfigured block consensus rules; wherein the block consensus rules include the first public information of the current node; receiving a first transaction; Calculate whether the first transaction should be stored by the current node according to the preconfigured transaction storage rules that match the block consensus rules: If yes, then a second block height at which the first transaction should be packaged is calculated according to a preconfigured transaction packaging rule that matches the block consensus rule; wherein the transaction storage rule and the transaction packaging rule include second public information of the first transaction, and the difference between the second block height and the current block height is greater than a first value; and, Storing the first transaction in a first to-be-packaged queue at the second block height; If no, then delete the first transaction; In response to obtaining the packaging right of the third block at the third block height, the third block is generated according to each second transaction in the second to-be-packaged queue at the third block height and broadcast to other blockchain nodes, so that other blockchain nodes: When the third block height is the block height that should participate in the consensus, determine whether the third block height is the block height that the current node should participate in the consensus according to the block consensus rule: If yes, then the following steps are performed for each of the second transactions: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, then the execution of the second transaction fails; Among them, the steps of receiving the first transaction to deleting the first transaction and the step of generating the third block according to each second transaction in the second to-be-packaged queue of the third block height and broadcasting it to other blockchain nodes are executed in parallel.

2. The method according to claim 1, characterized in that The first public information is a node hash of the current node, the second public information is a first full hash of the first transaction, and the calculation of the heights of each first block that the current node should participate in the consensus according to the preconfigured block consensus rule includes: Obtain the first M bits of the node hash of the current node, and calculate a first N-ary number based on the first M bits; Determine each fourth block height whose second N-ary number is the same as the first N-ary number as the first block height; wherein the second N-ary number is calculated as follows: (h mod N^M) === >>> (x2)2, (x2)2 = (x1)2, h is the fourth block height, (x1)2 is the first N-ary number, and (x2)2 is the second N-ary number; The calculating whether the first transaction should be stored by the current node according to the preconfigured transaction storage rule matching the block consensus rule includes: Obtain the second M bits of the first full hash, and calculate a third N-ary number according to the second M bits; Determine whether the third N-ary number is the same as the first N-ary number; The calculating the second block height at which the first transaction should be packaged according to the preconfigured transaction packaging rule matching the block consensus rule comprises: Calculate the fifth block height; wherein the calculation method of the fifth block height is: min(h1)mod N^M===>>>(x3)2, min(h1)>current block height+first value+1, min(h1) is the fifth block height, (x3)2 is the third N-ary number; and, Determine the fifth block height as the second block height; The step of judging whether the third block height is a block height for which the current node should participate in consensus according to the block consensus rule includes: Obtain the first M digits and calculate the first N-ary number; Calculate a fifth N-ary number; wherein the calculation method of the fifth N-ary number is: (h2 mod N^M) === >>> (x5)2, h2 is the third block height, (x5)2 is the fifth N-ary number; Determine whether the first N-ary number is the same as the fifth N-ary number; The determining, according to the transaction packaging rule, whether the second transaction should be packaged at the third block height: if not, then the execution of the second transaction fails includes: Obtain the third M bits of the second full hash of the second transaction, and calculate a sixth N-ary number according to the third M bits; Calculate a second remainder between the third block height and the second value; Converting the second remainder into a seventh N-ary number; When the sixth N-ary number is different from the seventh N-ary number, execution of the second transaction fails.

3. The method according to claim 1, characterized in that The calculating the second block height at which the first transaction should be packaged according to the preconfigured transaction packaging rule matching the block consensus rule comprises: Identifying, according to the pre-packaged identifier of the first transaction, whether the first transaction is a first-type transaction with a specified block height or a second-type transaction with an unspecified block height; When the first transaction is the first type of transaction, calculating a second block height at which the first transaction should be packaged according to a preconfigured transaction packaging rule that matches the block consensus rule; When the first transaction is the second type of transaction, storing the first transaction in an instant packaging queue; Generating the third block according to each second transaction in the second to-be-packaged queue of the third block height includes: The third block is generated according to each second transaction in the second to-be-packaged queue of the third block height and a number of transactions in the immediate packaging queue.

4. The method according to claim 1, characterized in that: The calculating the second block height at which the first transaction should be packaged according to the preconfigured transaction packaging rule matching the block consensus rule comprises: identifying, according to whether the first handling fee of the first transaction is lower than a third value, whether the first transaction is a first type transaction with a specified block height or a second type transaction with an unspecified block height; When the first transaction is the first type of transaction, calculating a second block height at which the first transaction should be packaged according to a preconfigured transaction packaging rule that matches the block consensus rule; When the first transaction is the second type of transaction, storing the first transaction in an instant packaging queue; Generating the third block according to each second transaction in the second to-be-packaged queue of the third block height includes: The third block is generated according to each second transaction in the second to-be-packaged queue of the third block height and a number of transactions in the immediate packaging queue.

5. The method according to claim 1, characterized in that The calculating the second block height at which the first transaction should be packaged according to the preconfigured transaction packaging rule matching the block consensus rule comprises: Verify whether the signature information of the first transaction is correct, and verify whether the first transaction is executable: When all the above verifications are passed, the second block height at which the first transaction should be packaged is calculated according to a preconfigured transaction packaging rule that matches the block consensus rule; When at least one of the above verifications fails, deleting the first transaction; The generating the third block according to each second transaction in the second to-be-packaged queue of the third block height and broadcasting it to other blockchain nodes includes: The following operations are performed on each of the second transactions: Determine whether, in any block generated from the first moment when the second transaction is added to the second to-be-packaged queue to the moment when a block before the third block height is generated, whether the third transaction initiator address of the third transaction is the same as the second transaction initiator address of the second transaction: If yes, verifying whether the second transaction is feasible when executing the second transaction; If not, the step of verifying whether the second transaction is feasible is omitted when executing the second transaction.

6. The method according to claim 1, characterized in that The to-be-packaged queues of each blockchain node are configured with the same transaction sorting method, and when the difference between the third block height and the current block height is a fourth value, each blockchain node participating in the third block height consensus pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the third block height, wherein the fourth value is not greater than the first value; The following steps are performed on each of the second transactions: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule: if not, then the failure to execute the second transaction includes: Determine whether the second Merkle root of the third block is the same as the first Merkle root: If yes, then omit the following step for each second transaction: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, then execute the second transaction failure step; If not, the following steps are performed for each of the second transactions: determine whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if not, the execution of the second transaction fails.

7. The method according to claim 1, characterized in that The to-be-packaged queues of each blockchain node are configured with the same transaction sorting method, and when the difference between the third block height and the current block height is a fourth value, each blockchain node participating in the third block height consensus pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the third block height, wherein the fourth value is not greater than the first value; The generating the third block according to each second transaction in the second to-be-packaged queue of the third block height and broadcasting it to other blockchain nodes includes: Generate the third block according to each second transaction in the second to-be-packaged queue of the third block height; Broadcasting the second Merkle root of the third block and the second transaction hash list including each of the second transactions to other blockchain nodes; The following steps are performed on each of the second transactions: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule: if not, then the failure to execute the second transaction includes: Determine whether the second Merkle root of the third block is the same as the first Merkle root: If yes, the following steps are omitted for each second transaction: judging whether the second transaction should be packaged at the third block height according to the transaction packaging rule; if no, the execution of the second transaction fails; If not, then requesting the current blockchain node for the second transactions corresponding to the missing second transaction hashes; and, The following steps are performed for each requested second transaction: judging whether the requested second transaction should be packaged at the third block height according to the transaction packaging rule: if not, the execution of the requested second transaction fails.

8. The method according to any one of claims 1 to 7, characterized in that: The blockchain includes consensus nodes and non-consensus nodes, wherein the non-consensus nodes do not participate in the block consensus; The generating the third block according to each second transaction in the second to-be-packaged queue of the third block height and broadcasting it to other blockchain nodes includes: Generate the third block according to each second transaction in the second to-be-packaged queue of the third block height and broadcast it to other consensus nodes; The third block is also used by other consensus nodes to: When the third block height is a block height that should not participate in consensus, deleting the third block; The method further comprises: The third block reached by consensus is broadcasted to consensus nodes and non-consensus nodes that should not participate in the consensus at the third block height.

9. A computer device, characterized in that: The device comprises: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors are caused to perform the method according to any one of claims 1 to 8.

10. A storage medium storing a computer program, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images