Transaction storage and block generation method, device and storage medium

Abstract

The present invention provides a transaction storage and block generation method, device and storage medium, the method comprising: obtaining a first transaction; calculating the first block height that should be packaged with the first transaction according to a preconfigured transaction storage rule; storing the first transaction in a first queue to be packaged at the first block height; in response to obtaining the packaging right of a second block at a second block height, generating a second block according to each second transaction in a second queue to be packaged at the second block height and broadcasting it to other blockchain nodes, and obtaining the first transaction to the first queue to be packaged at the first block height and storing the first transaction in the first queue to be packaged at the first block height, and generating a second block according to each second transaction in the second queue to be packaged at the second block height and broadcasting it to other blockchain nodes are performed in parallel. The present application can further improve throughput.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and specifically to a transaction storage 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 storage and block generation method, device and storage medium that further improve the throughput.

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

[0006] Obtaining a first transaction; wherein the first transaction is generated by a client of the user, or generated by the current node;

[0007] Calculating a first block height that should package the first transaction according to a preconfigured transaction storage rule; wherein the transaction storage rule includes first public information of the first transaction, and a difference between the first block height and the current block height is greater than a first value;

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

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

[0010] The following steps are performed for each second transaction: judging whether the second transaction should be packaged at the second block height according to a preconfigured transaction packaging rule: if not, the execution of the second transaction fails; wherein the transaction packaging rule includes the first public information;

[0011] Among them, the steps of obtaining the first transaction and storing the first transaction in the first queue to be packaged at the first block height and the step of generating the second block according to each second transaction in the second queue to be packaged at the second block height and broadcasting it to other blockchain nodes are executed in parallel.

[0012] 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 storage and block generation method provided according to various embodiments of the present invention.

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

[0014] The transaction storage and block generation method, device and storage medium provided by many embodiments of the present invention obtain a first transaction; calculate the first block height at which the first transaction should be packaged according to a preconfigured transaction storage rule; store the first transaction in a first queue to be packaged at the first block height; in response to obtaining the packaging right of a second block at a second block height, generate a second block according to each second transaction in a second queue to be packaged at the second block height and broadcast it to other blockchain nodes, and the step of obtaining the first transaction and storing the first transaction in the first queue to be packaged at the first block height and the step of generating a second block according to each second transaction in the second queue to be packaged at the second block height and broadcasting it to other blockchain nodes are executed in parallel, thereby further improving throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] 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:

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

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

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

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

[0020] 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.

[0021] 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.

[0022] Figure 1 A flowchart of a transaction storage 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 storage and block generation method applicable to a blockchain node, and the method includes:

[0023] S12: Obtain a first transaction; wherein the first transaction is generated by a client of the user, or generated by the current node;

[0024] S14: Calculating the first block height that should package the first transaction according to a preconfigured transaction storage rule; wherein the transaction storage rule includes first public information of the first transaction, and the difference between the first block height and the current block height is greater than a first value;

[0025] S16: storing the first transaction in a first to-be-packaged queue at a first block height;

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

[0027] The following steps are performed for each second transaction: judging whether the second transaction should be packaged at the second block height according to a preconfigured transaction packaging rule: if not, the execution of the second transaction fails; wherein the transaction packaging rule includes the first public information;

[0028] Among them, the steps of obtaining the first transaction and storing the first transaction in the first queue to be packaged at the first block height and the step of generating the second block according to each second transaction in the second queue to be packaged at the second block height and broadcasting it to other blockchain nodes are executed in parallel.

[0029] Specifically, with the first public information being the first full hash of the first transaction, S14 includes “obtaining the first M bits of the first full hash, calculating the first N-ary number according to the first M bits; calculating the third block height; wherein the third block height is the sum of the current block height and the first value plus one; calculating the first remainder of the third block height and the second value; wherein the second value is N to the Mth power; converting the first remainder into a second N-ary number; when the first N-ary number and the second N-ary number are the same, determining the third block height as the first block height; when the first N-ary number and the second N-ary number are different, When the third block height is increased by one to update the third block height, and the first remainder calculated between the third block height and the second value is returned", and, according to the preconfigured transaction packaging rule, it is determined whether the second transaction should be packaged at the second block height: if not, the execution of the second transaction fails, including "obtaining the second M bits of the second full hash of the second transaction, calculating the third N-ary number according to the second M bits; calculating the second remainder between the second block height and the second value; converting the second remainder into a fourth N-ary number; when the third N-ary number is different from the fourth N-ary number, the execution of the second transaction fails" as an example;

[0030] Assume that the current blockchain has nodes N1 to N25, the current node is N1, the first value is 5, M is the first 3, and N is 2; Assume that 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 second block height is 112;

[0031] For tx1:

[0032] N1 executes step S12 to obtain tx1;

[0033] N1 executes step S14 to obtain the first binary number of tx1, which is 000; N1 calculates the third block height, which is 106; N1 calculates the remainder of 106 and 8, which is 2; N1 converts 2 into the second binary number, which is 010;

[0034] If 000 is different from 010, the third block height is updated to 107, and the process returns to the first remainder step of calculating the third block height and the second value;

[0035] Finally, N1 finds block height 112 as the block height where tx1 should be packaged;

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

[0037] For tx2:

[0038] N1 executes step S12 to obtain tx2;

[0039] N1 executes step S14 to obtain the first binary number of tx2, which is 111; N1 calculates the third block height, which is 106; N1 calculates the remainder of 106 and 8, which is 2; N1 converts 2 into the second binary number, which is 010;

[0040] If 111 is different from 010, the third block height is updated to 107, and the process returns to the first remainder step of calculating the third block height and the second value;

[0041] Finally, N1 finds block height 111 as the block height where tx2 should be packaged;

[0042] N1 executes step S16 and stores tx1 in the queue to be packaged at block height 111;

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

[0044] N2~N25 perform the following steps on tx1 and tx3~tx10 respectively:

[0045] Take tx1 as an example;

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

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

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

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

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

[0051] 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 other blockchain nodes fail to execute tx10;

[0052] Among them, steps S12 to S16 are executed in parallel with step S18.

[0053] 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.

[0054] 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.

[0055] In more embodiments, the first public information can also be configured according to actual needs, for example, configured as a transaction hash, to achieve the same technical effect.

[0056] In more embodiments, S14 can also be configured according to actual needs, for example, configured to, for example, convert the first public information of tx1 into a decimal number, and obtain the last digit of the converted decimal number, for example, 9, then store tx1 in the to-be-packaged queue 109, and accordingly, also configure a method of "determining whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rules". At this time, other blockchain nodes should also calculate whether the last digit of the first public information of tx1 converted into a decimal number is the same as the last digit of the second block height; the same technical effect can be achieved.

[0057] 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.

[0058] Preferably, the above method further comprises:

[0059] Send the block data of the second block that has been agreed upon to the central server for storage;

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

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

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

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

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

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

[0066] When receiving the block data of the second 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.

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

[0068] S141: 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;

[0069] S142: When the first transaction is a first-type transaction, a first block height that should be used to package the first transaction is calculated according to a preconfigured transaction storage rule;

[0070] S143: When the first transaction is a second-type transaction, storing the first transaction in an instant packaging queue;

[0071] S18 includes:

[0072] S181: In response to obtaining the packaging right of the second block at the second block height, a second block is generated according to each second transaction in the second to-be-packaged queue at the second block height and a plurality of transactions in the immediate packaging queue.

[0073] Specifically, assume that N1 also receives tx11 and tx12, tx11 is configured with a pre-packaging flag, and tx12 is not configured with a pre-packaging flag;

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

[0075] 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.

[0076] Figure 3 for Figure 1 Another preferred embodiment is shown in the flowchart. Figure 3 As shown, in a preferred embodiment, S14 includes:

[0077] S145: 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;

[0078] S146: When the first transaction is a first-type transaction, a first block height that should be used to package the first transaction is calculated according to a preconfigured transaction storage rule;

[0079] S147: When the first transaction is a second-type transaction, the first transaction is stored in an instant packaging queue; wherein the transactions in the instant packaging queue are queued in descending order of transaction fees;

[0080] S18 includes:

[0081] S182: In response to obtaining the packaging right of the second block at the second block height, a second block is generated according to each second transaction in the second to-be-packaged queue at the second block height and a plurality of transactions in the immediate packaging queue.

[0082] Specifically, assume that the third value is 100AAA; N1 also receives tx13 and tx14, the transaction fee of tx13 is 150AAA, and the transaction fee of tx12 is 1AAA;

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

[0084] 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.

[0085] Preferably, in a preferred embodiment, S14 includes:

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

[0087] S1482: When the above verifications are all passed, the height of the first block in which the first transaction should be packaged is calculated according to the preconfigured transaction storage rule;

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

[0089] S18 includes:

[0090] In response to obtaining the packaging right of the second block at the second block height, the following operations are performed on each second transaction in the second to-be-packaged queue at the second block height:

[0091] S1831: Determine whether there is a third transaction initiator address of a third transaction that 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 second block height is generated:

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

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

[0094] Take tx1 as an example;

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

[0096] Assuming that the above verification of tx1 passes, N1 executes step S1482 to calculate the block height at which tx1 should be packaged according to the preconfigured transaction storage rules;

[0097] Assuming that the transaction initiator address of tx1 is addr(A), N1 executes step S1831 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));

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

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

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

[0101] Further preferably, step S1832 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.

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

[0103] Further preferably, step S1832 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.

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

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

[0106] The following steps are performed for each second transaction: Determine whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule: If not, the failure to execute the second transaction includes:

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

[0108] If yes, the following steps are omitted for each second transaction: judging whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule; if no, executing the second transaction failure step;

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

[0110] Specifically, assuming that the fourth value is 4, the blockchain nodes (N1-N25) pregenerate the Merkleroot (112) of block (112) when the block height is 108;

[0111] When N2-N25 receives block(112), if the Merkle root(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-N25 omits the step of "performing the following steps for each second transaction: determining whether the second transaction should be packaged at the second block height according to the pre-configured transaction packaging rule; if not, the execution of the second transaction fails";

[0112] If merkleroot(112)' is different from merkleroot(112), N2~N25 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 second block height according to the preconfigured transaction packaging rules: if not, execute the second transaction failure".

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

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

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

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

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

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

[0119] The following steps are performed for each second transaction: Determine whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule: If not, the failure to execute the second transaction includes:

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

[0121] If yes, the following steps are omitted for each second transaction: judging whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule; if no, executing the second transaction failure step;

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

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

[0124] 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);

[0125] 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-N25 omit the step of "performing the following steps for each second transaction: judging whether the second transaction should be packaged at the second block height according to the pre-configured transaction packaging rule; if not, the execution of the second transaction fails";

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

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

[0128] Preferably, the transaction sorting method configured for the to-be-packaged queue of each blockchain node is to queue the transactions from early to late in the order of the time they enter the cache pool.

[0129] In more embodiments, the transaction sorting method configured for the queue to be packaged may also be configured according to actual needs.

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

[0131] like Figure 4As 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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 the technical features with similar functions disclosed in the present application (but not limited to) to form a technical solution.

Claims

1. A transaction storage and block generation method, characterized in that: Applicable to a blockchain node, the method comprises: Obtaining a first transaction; wherein the first transaction is generated by a user's client, or generated by a current node; Calculating a first block height that should package the first transaction according to a preconfigured transaction storage rule; wherein the transaction storage rule includes first public information of the first transaction, and a difference between the first block height and the current block height is greater than a first value; Storing the first transaction in a first to-be-packaged queue at the first block height; In response to obtaining the packaging right of the second block at the second block height, the second block is generated according to each second transaction in the second to-be-packaged queue at the second block height and broadcast to other blockchain nodes, so that other blockchain nodes: The following steps are performed for each second transaction: judging whether the second transaction should be packaged at the second block height according to a preconfigured transaction packaging rule: if not, the execution of the second transaction fails; wherein the transaction packaging rule includes the first public information; Among them, the steps of obtaining the first transaction to storing the first transaction in the first queue to be packaged at the first block height and the step of generating the second block according to each second transaction in the second queue to be packaged at the second 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 first full hash of the first transaction, and the calculation of the first block height for packaging the first transaction according to the preconfigured transaction storage rule includes: Obtain the first M bits of the first full hash, and calculate a first N-ary number according to the first M bits; Calculate a third block height; wherein the third block height is the sum of the current block height and the first value plus one; Calculate a first remainder between the third block height and a second value; wherein the second value is N to the Mth power; Converting the first remainder into a second N-ary number; When the first N-ary number is the same as the second N-ary number, determining the third block height as the first block height; When the first N-ary number is different from the second N-ary number, adding one to the third block height to update the third block height, and returning a first remainder of the calculation of the third block height and the second value; The determining whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule: if not, then the execution of the second transaction fails includes: Obtain the second M bits of the second full hash of the second transaction, and calculate a third N-ary number based on the second M bits; Calculate a second remainder of the second block height and the second value; Converting the second remainder into a fourth N-ary number; When the third N-ary number is different from the fourth N-ary number, execution of the second transaction fails.

3. The method according to claim 1, characterized in that The calculating the first block height for packaging the first transaction according to the preconfigured transaction storage rule includes: 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, according to a preconfigured transaction storage rule, a first block height in which the first transaction should be packaged; When the first transaction is the second type of transaction, storing the first transaction in an instant packaging queue; Generating the second block according to each second transaction in the second to-be-packaged queue of the second block height includes: The second block is generated according to each second transaction in the second to-be-packaged queue of the second 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 first block height for packaging the first transaction according to the preconfigured transaction storage rule includes: 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, according to a preconfigured transaction storage rule, a first block height in which the first transaction should be packaged; When the first transaction is the second type of transaction, the first transaction is stored in an instant packaging queue; wherein the transactions in the instant packaging queue are queued in descending order of transaction fees; Generating the second block according to each second transaction in the second to-be-packaged queue of the second block height includes: The second block is generated according to each second transaction in the second to-be-packaged queue of the second 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 first block height for packaging the first transaction according to the preconfigured transaction storage rule includes: Verify whether the signature information of the first transaction is correct, and verify whether the first transaction is executable: When the above verifications are all passed, the height of the first block in which the first transaction should be packaged is calculated according to the preconfigured transaction storage rules; When at least one of the above verifications fails, deleting the first transaction; Generating the second block according to each second transaction in the second to-be-packaged queue of the second block height 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 second block height is generated, whether a third transaction initiator address of a 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 each blockchain node pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the second block height when the difference between the second block height and the current block height is a fourth value, 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 second block height according to the preconfigured transaction packaging rule: if not, then the failure to execute the second transaction includes: Determine whether the second Merkle root of the second block is the same as the first Merkle root: If yes, then omit the following steps for each second transaction: determine whether the second transaction should be packaged at the second block height according to the preconfigured 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 second block height according to the preconfigured transaction packaging rules: 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 each blockchain node pre-generates a first Merkle root according to each second transaction in the second to-be-packaged queue of the second block height when the difference between the second block height and the current block height is a fourth value, wherein the fourth value is not greater than the first value; The generating the second block according to each second transaction in the second to-be-packaged queue of the second block height and broadcasting it to other blockchain nodes includes: Generate the second block according to each second transaction in the second to-be-packaged queue at the second block height; Broadcasting the second Merkle root of the second 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 second block height according to the preconfigured transaction packaging rule: if not, then the failure to execute the second transaction includes: Determine whether the second Merkle root of the second block is the same as the first Merkle root: If yes, then omit the following steps for each second transaction: determine whether the second transaction should be packaged at the second block height according to the preconfigured transaction packaging rule; if no, then execute the second transaction failure step; 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 second block height according to the preconfigured transaction packaging rule: if not, the execution of the second transaction fails.

8. The method according to claim 6 or 7, characterized in that: The transaction sorting method configured for the to-be-packaged queue of each blockchain node is to queue transactions from early to late in the order of the time they enter the cache pool.

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