Transaction processing method and device based on blockchain, and electronic device

Abstract

One or more embodiments of the present specification provide a transaction processing method and apparatus, and an electronic device based on blockchain, the method may include: receiving a target transaction initiated by a member node device in the blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within the validity period of the transaction; based on the reference time parameter, determining whether the target transaction is a valid transaction within the validity period of the transaction; if it is determined that the target transaction is a valid transaction within the validity period of the transaction, including the target transaction in the generated candidate block.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a transaction processing method and device based on blockchain, and an electronic device. Background Art

[0002] Blockchain technology, also known as distributed ledger technology, is an emerging technology in which several computing devices jointly participate in "bookkeeping" and jointly maintain a complete distributed database. Since blockchain technology is decentralized, open and transparent, each computing device can participate in database records, and data can be quickly synchronized between computing devices, blockchain technology is used to build a decentralized system, and various execution programs are included in the distributed database of the blockchain for automatic execution. It has been widely used in many fields. Summary of the invention

[0003] This specification proposes a transaction processing method based on blockchain, including:

[0004] Receiving a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within a transaction validity period;

[0005] Determining whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0006] If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block.

[0007] Optionally, the reference time parameter is a reference timestamp generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a first numerical value and a second numerical value; the first numerical value is a difference between a creation timestamp of the candidate block and a first threshold; the second numerical value is a sum of a creation timestamp of the candidate block and a second threshold;

[0008] The determining, based on the reference time parameter, whether the target transaction is a valid transaction within the transaction validity period includes:

[0009] comparing the reference timestamp with the first value and the second value respectively;

[0010] If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

[0011] Optionally, before comparing the reference timestamp with the first value and the second value respectively, the method further includes:

[0012] Check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; if so, further compare the reference timestamp with the first value and the second value respectively.

[0013] Optionally, the reference timestamp is a system timestamp when the target transaction is created; or, a reference timestamp specified by a transaction creator.

[0014] Optionally, the first threshold is greater than the second threshold.

[0015] Optionally, the reference time parameter is a reference block height number generated when creating the target transaction; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and a block height number of the candidate block on the blockchain; the third numerical value is a difference between the block height number of the candidate block on the blockchain and a third threshold value;

[0016] The determining, based on the reference time parameter, whether the target transaction is a valid transaction within the transaction validity period includes:

[0017] Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively;

[0018] If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

[0019] Optionally, before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, the method further includes:

[0020] Check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; if so, further compare the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively.

[0021] Optionally, the reference block height number is the maximum block height number in the blockchain when the target transaction is created; or, the reference block height number specified by the transaction creator.

[0022] Optionally, the target transaction also includes a unique identifier of the target transaction;

[0023] If it is determined that the target transaction is a valid transaction within the transaction validity period, including the target transaction in the generated candidate block includes:

[0024] If it is determined that the target transaction is a valid transaction within the transaction validity period, query whether a preset transaction idempotency table stores a transaction idempotency record corresponding to the unique identifier of the target transaction; wherein the transaction idempotency table is used to store transaction idempotency records corresponding to valid transactions within the transaction validity period; if the transaction idempotency record corresponding to the unique identifier of the target transaction is not stored in the transaction idempotency table, the target transaction is included in the candidate block.

[0025] Optionally, the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain;

[0026] Also includes:

[0027] If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

[0028] Optionally, also include:

[0029] Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

[0030] This specification also proposes a transaction processing device based on blockchain, including:

[0031] A receiving module receives a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within a transaction validity period;

[0032] a determination module, which determines whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0033] The collection module collects the target transaction into the generated candidate block if it is determined that the target transaction is a valid transaction within the transaction validity period.

[0034] Optionally, the reference time parameter is a reference timestamp generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a first numerical value and a second numerical value; the first numerical value is a difference between a creation timestamp of the candidate block and a first threshold; the second numerical value is a sum of a creation timestamp of the candidate block and a second threshold;

[0035] The determination module

[0036] comparing the reference timestamp with the first value and the second value respectively;

[0037] If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

[0038] Optionally, the confirmation module further:

[0039] Before comparing the reference timestamp with the first value and the second value respectively, check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; if so, further compare the reference timestamp with the first value and the second value respectively.

[0040] Optionally, the reference timestamp is a system timestamp when the target transaction is created; or, a reference timestamp specified by a transaction creator.

[0041] Optionally, the first threshold is greater than the second threshold.

[0042] Optionally, the reference time parameter is a reference block height number generated when creating the target transaction; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and a block height number of the candidate block on the blockchain; the third numerical value is a difference between the block height number of the candidate block on the blockchain and a third threshold value;

[0043] The determination module:

[0044] Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively;

[0045] If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

[0046] Optionally, the determining module further:

[0047] Before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; if so, further compare the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively.

[0048] Optionally, the reference block height number is the maximum block height number in the blockchain when the target transaction is created; or, the reference block height number specified by the transaction creator.

[0049] Optionally, the target transaction also includes a unique identifier of the target transaction;

[0050] The collection module further:

[0051] If it is determined that the target transaction is a valid transaction within the transaction validity period, query whether a transaction idempotency record corresponding to the unique identifier of the target transaction is stored in a preset transaction idempotency table; wherein the transaction idempotency table is used to store transaction idempotency records corresponding to valid transactions within the transaction validity period;

[0052] If the transaction idempotency table does not store a transaction idempotency record corresponding to the unique identifier of the target transaction, the target transaction is included in the candidate block.

[0053] Optionally, the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain;

[0054] The collection module 303 further:

[0055] If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

[0056] Optionally, the collection module 303 further:

[0057] Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

[0058] This specification also proposes an electronic device, comprising:

[0059] processor;

[0060] memory for storing machine-executable instructions;

[0061] Wherein, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to:

[0062] Receiving a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within a transaction validity period;

[0063] Determining whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0064] If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Figure 1 It is a flowchart of a transaction processing method based on blockchain provided by an exemplary embodiment.

[0066] Figure 2 It is a schematic structural diagram of an electronic device provided by an exemplary embodiment.

[0067] Figure 3 It is a block diagram of a blockchain-based transaction processing device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0068] This specification aims to propose a technical solution for setting a transaction validity period for transactions published to the blockchain to ensure that node devices in the blockchain can only include transactions within the transaction validity period into candidate blocks.

[0069] When implemented, the blockchain operator can uniformly set a transaction validity period for transactions published in the blockchain;

[0070] For example, in actual applications, the validity period of the above-mentioned transaction can specifically be a period of time before the creation time of the candidate block created by the node device in the blockchain (such as a node device acting as an "accounting node") in the current accounting cycle, or a period of time before and after the creation time of the candidate block.

[0071] When a user creates a transaction through a client, he or she can add a reference time parameter to the transaction to determine whether the transaction is a valid transaction within the validity period of the transaction, and then publish the transaction to the blockchain through the node device connected to the client.

[0072] When other node devices in the blockchain receive the transaction, during the verification phase of the transaction, they can verify whether the transaction is a valid transaction within the validity period of the above transaction based on the reference time parameter carried in the transaction; if it is verified that the transaction is a valid transaction within the validity period of the above transaction, the transaction can be included in the candidate block.

[0073] Through the above technical solution, since only valid transactions within the validity period of the above-mentioned transactions can be included in the candidate block as legal transactions, it can prevent illegal node devices in the blockchain from using intercepted expired transactions from a long time ago to launch replay attacks on the blockchain, thereby improving the transaction security level of the blockchain.

[0074] The present specification is described below through specific embodiments and in combination with specific application scenarios.

[0075] Please refer to Figure 1 , Figure 1 A transaction processing method based on blockchain is provided in an embodiment of this specification, and is applied to any node device in the blockchain to perform the following steps:

[0076] Step 102, receiving a target transaction initiated by a member node device in the blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within the transaction validity period;

[0077] Step 104, determining whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0078] Step 106: If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block.

[0079] The blockchain described in this specification may specifically include private chains, public chains, and alliance chains, etc., which are not particularly limited in this specification.

[0080] For example, in one scenario, the blockchain can be a consortium chain consisting of a third-party payment platform server, a domestic bank server, a foreign bank server, and several user node devices as member devices. The operator of the consortium chain can rely on the consortium chain to deploy online services such as cross-border transfers and asset transfers based on the consortium chain.

[0081] The transaction (transfer) described in this specification refers to a piece of data created by a user through a blockchain client and ultimately published to the distributed database of the blockchain.

[0082] Among them, transactions in the blockchain can be divided into narrow transactions and broad transactions. A transaction in the narrow sense refers to a value transfer published by a user to the blockchain; for example, in the traditional Bitcoin blockchain network, a transaction can be a transfer initiated by a user in the blockchain. A transaction in the broad sense refers to a business data with business intent published by a user to the blockchain; for example, an operator can build a consortium chain based on actual business needs, and rely on the consortium chain to deploy some other types of online businesses that are not related to value transfer (for example, rental business, vehicle dispatch business, insurance claims business, credit services, medical services, etc.), and in this type of consortium chain, a transaction can be a business message or business request with business intent published by a user in the consortium chain.

[0083] The above-mentioned target transactions refer to candidate transactions that are selected by the node device that serves as the accounting node in the blockchain from the collected transactions issued by other member node devices and passed legal verification, and need to be packaged and included in the candidate block.

[0084] The above-mentioned transaction validity period refers to the validity period uniformly set by the blockchain operator for transactions published on the blockchain. Transactions within the validity period are considered valid transactions that can be added to the candidate block as legal transactions; conversely, transactions beyond the validity period are considered invalid transactions that cannot be added to the candidate block.

[0085] The transaction validity period may be a time interval set based on the creation time of the candidate block created by the accounting node device in the blockchain in the current accounting cycle; for example, the transaction validity period may be a period of time before the creation time of the candidate block; or a period of time before and after the creation time of the candidate block. For the accounting node, when collecting many transactions issued by other node devices in the blockchain, it can use the transaction validity period to decide which transactions can be added to the generated candidate block as legal transactions.

[0086] The reference time parameter may be a time parameter added to the transaction to determine whether the transaction is a valid transaction within the validity period of the transaction. When verifying the collected transactions, the accounting nodes in the blockchain may refer to the time indicated by the reference time parameter carried in the transaction to determine whether the transaction is a valid transaction within the validity period.

[0087] The reference time parameter may be a physical clock or a logical clock.

[0088] The so-called physical clock refers to the system timestamp read from the system or from a third-party clock server. The logical clock refers to the timestamp in the logical sense. In a distributed system, any self-increasing value that can indicate the order in which events (such as transactions) occur can be used as a logical clock.

[0089] In one implementation, taking the reference time parameter as a physical clock as an example, the reference time parameter may be a reference timestamp added to the transaction. Accordingly, in this case, the transaction validity period may be a numerical interval consisting of the difference between the creation timestamp corresponding to the creation time of the candidate block and the first threshold (first numerical value), and the sum of the creation timestamp of the candidate block and the second threshold (second numerical value).

[0090] For example, suppose the creation timestamp of the candidate block is B ts ; The first threshold is recorded as K1, and the second threshold is recorded as K2. Then, the transaction validity period can be expressed as a numerical interval [B ts -K1, B ts +K2] to indicate.

[0091] The first threshold value indicates the effective duration of the transaction reserved when setting the validity period of the transaction. The second threshold value indicates the clock offset between the system timestamp of the node device that publishes the transaction and the system timestamp of the node device that creates the candidate block. Since the clock offset that can be tolerated in the blockchain network is usually small in practical applications, the second threshold value can be set to a threshold value that is smaller than the first threshold value in order of magnitude when setting the validity period of the transaction.

[0092] For example, in one example, the first threshold may be set to 5 days, and the second threshold may be set to 5 minutes. In this case, transactions published to the blockchain within 5 days before the creation of the candidate block and within 5 minutes after the creation of the candidate block are all valid transactions within the transaction validity period.

[0093] It should be noted that the above reference timestamp can be manually specified by the user when creating a transaction through the client, or can be automatically added by the client;

[0094] For example, in one case, when a user creates a transaction through a client, the client can read the creation time of the transaction from the system, and then automatically add the timestamp corresponding to the creation time as the reference timestamp to the created transaction. In another case, the user can specify a time based on needs within the validity period of the transaction, and then manually add the timestamp corresponding to the time as the reference timestamp to the created transaction.

[0095] Of course, in actual applications, when setting the above-mentioned transaction validity period, the clock offset between the system timestamp of the node device that publishes the transaction and the system timestamp of the node device that creates the candidate block may be ignored. In this case, the above-mentioned transaction validity period can specifically be a numerical interval consisting of the difference between the creation timestamp corresponding to the creation time of the above-mentioned candidate block and the first threshold (first numerical value), and the creation timestamp of the above-mentioned candidate block.

[0096] For example, assuming that the creation timestamp of the candidate block is B ts ; The first threshold is recorded as K1. Then, the transaction validity period can be expressed as a numerical interval [B ts -K1, B ts ] to indicate.

[0097] In another embodiment, taking the reference time parameter as a logical clock as an example, in the P2P network corresponding to the blockchain, the block height of the block in the blockchain can be used as the logical clock. In this case, the reference time parameter can be a reference block height number added to the transaction. The transaction validity period can be a numerical interval consisting of the block height number of the candidate block on the blockchain and the difference between the block height number of the candidate block on the blockchain and the third threshold (third value).

[0098] For example, suppose the block height of the candidate block on the blockchain is B h ; The third threshold is K3. Then, the transaction validity period can be expressed as a numerical interval [B h -K3, B h ] to indicate.

[0099] Among them, the third threshold has the same meaning as the first threshold, which means the reserved transaction validity period when setting the transaction validity period. In the scenario where the block height is used as the logical clock to represent the transaction validity period, the clock offset between the system timestamp of the node device that publishes the transaction and the system timestamp of the node device that creates the candidate block can be ignored. Therefore, the increment interval in the right half of the above expression can be ignored and the threshold used to represent the clock offset can be ignored.

[0100] It should be noted that the above reference block height number can be manually specified by the user when creating a transaction through the client, or can be automatically added by the client;

[0101] For example, in one case, when a user creates a transaction through a client, the client can read the creation time of the transaction from the system, and then further query the maximum block height number on the above blockchain at the creation time, and then automatically add it to the created transaction. In another case, the user can specify a block height based on demand within the validity period of the above transaction, and then use the value corresponding to the block height as the above reference block height number and manually add it to the created transaction.

[0102] Of course, in addition to using the block height of the block in the blockchain as an implementation method of the logical clock, in practical applications, other types of increasing values ​​that can be used to describe the order in which transactions occur can also be used as the above-mentioned logical clock, which will not be listed one by one in this specification.

[0103] In this specification, transactions created by users through the client can be signed based on the private key held by the user and broadcasted in the P2P network of the blockchain through the node device connected to the client. The node device as the accounting node can collect transactions broadcasted by other node devices and store the collected transactions as unconfirmed transactions in the local transaction pool (also called the memory pool).

[0104] Furthermore, the node device acting as an accounting node can create a candidate block within the current accounting cycle and verify the legitimacy of the transactions in the transaction pool, and then can include the transactions that have passed the legitimacy verification as candidate transactions in the created candidate block.

[0105] In practical applications, the verification of transactions in the transaction pool may specifically include the identity verification of the publisher of the transaction and the verification of the transaction content; wherein, the verification of the transaction content may further include the integrity verification of the transaction content.

[0106] In implementation, when signing the above transaction, the transaction can usually be calculated to obtain a content summary (such as a hash value), and then the content summary can be encrypted based on the private key held to obtain a digital signature. After receiving the signed transaction, the node device serving as the accounting node can decrypt the above digital signature based on the private key used when signing the transaction; if the decryption is successful, it means that the identity authentication of the user who issued the transaction has passed, and the transaction is a legal transaction issued by the user.

[0107] Secondly, the node device acting as a bookkeeping node can further recalculate the transaction to obtain a content summary, and then match the recalculated content summary with the original content summary obtained by decrypting the digital signature; if the two match, it means that the integrity verification of the transaction content has passed, and the transaction content of the transaction has not been illegally tampered with during the transaction transmission process.

[0108] In this specification, on the basis of verifying the identity of the publisher and the transaction content of the transactions in the transaction pool, a reference time parameter carried in the transaction can be further introduced to verify whether the transaction in the transaction pool is a valid transaction within the transaction validity period. For transactions in the transaction pool that have passed the identity verification of the publisher and the verification of the transaction content, it is possible to further verify whether the transaction in the transaction pool is a valid transaction within the transaction validity period based on the reference time parameter carried in such transactions.

[0109] In one embodiment shown, it is assumed that the reference time parameter is a reference timestamp added to the transaction, denoted by T ts; The validity period of the above transaction is a creation timestamp B corresponding to the creation time of the above candidate block ts The difference between the first threshold K1 and the creation timestamp B of the candidate block ts and the second threshold value K2, forming a numerical interval [B ts -K1, B ts +K2].

[0110] In this case, the node device as the accounting node can first perform a monotonically increasing check on the creation timestamp of the created candidate block, and check the creation timestamp B in the created candidate block. ts , is it greater than the creation timestamp of the latest block in the blockchain? If so, it indicates that the candidate block meets the monotonically increasing property of the creation timestamp of the blocks on the blockchain, and the candidate block is a legal block.

[0111] When the candidate block passes the monotonically increasing check, the node device acting as the accounting node can further read the reference timestamp T from the transaction. ts , and read the reference timestamp T ts With B ts -K1 and B ts +K2 are compared respectively; if T ts Greater than B ts -K1, and less than B ts +K2, it can be determined that the transaction is a valid transaction within the validity period of the above transaction.

[0112] In one embodiment shown, it is assumed that the reference time parameter is the reference block height number added to the transaction, denoted by T h ; The validity period of the above transaction is a block height number B of the above candidate block on the blockchain h The difference between the third threshold K3 and the block height B of the candidate block on the blockchain h , a numerical interval [B h -K3, B h ].

[0113] In this case, the node device acting as a bookkeeping node can first perform a monotonically increasing check on the block number of the created candidate block to check whether the block number in the created candidate block is greater than the block number of the latest block in the blockchain; if so, it indicates that the candidate block satisfies the monotonically increasing property of the block number of the blocks on the blockchain, and the candidate block is a legal block.

[0114] When the candidate block passes the monotonically increasing check, the node device acting as the accounting node can further read the reference block height number T from the transaction. h, and read the reference block height number T h With B h -K3 and B h Compare them separately; if T h Greater than B h -K3, and less than B h , it can be determined that the transaction is a valid transaction within the validity period of the above transaction.

[0115] In this specification, transactions in the transaction pool that have passed the above-mentioned legality verifications such as the identity verification of the publisher, the verification of the transaction content, and the validity verification of the transaction can be packaged as candidate transactions and included in the created candidate block.

[0116] For example, a node device that serves as a bookkeeping node can select all transactions that have passed the legitimacy check, or based on certain principles (such as transaction priority), filter out some transactions from all transactions that have passed the legitimacy check and add them to the candidate block as candidate transactions.

[0117] In this way, since only valid transactions within the validity period of the above-mentioned transactions can be included in the candidate blocks as legal transactions, some expired transactions from a long time ago will not be included in the candidate blocks for subsequent transaction execution. This can prevent illegal node devices in the blockchain from using intercepted expired transactions from a long time ago to launch replay attacks on the blockchain, thereby improving the transaction security level of the blockchain.

[0118] In this specification, since the transaction execution environment of the node device as the accounting node may be a multi-instance execution environment (for example, the same transaction client enables multiple threads that can initiate transactions at the same time), and in a multi-instance execution environment, the same transaction may be repeatedly submitted by different instances belonging to the same node device, which may cause the transaction execution in the blockchain to have an "idempotence" problem. The so-called "idempotence" problem refers to the negative impact on users after the same transaction is repeatedly executed;

[0119] For example, the "double spending" problem in the Bitcoin network is a typical "idempotence" problem. After a transfer transaction is signed and authorized by the user's private key, it is intercepted by an illegal node. After the transaction is executed, the illegal node can launch a replay attack based on the intercepted transaction and repeatedly execute the transaction in the blockchain, resulting in multiple transfers of the same funds, causing financial losses to users.

[0120] Based on this, in order to avoid repeated execution of transactions in a multi-instance execution environment, the node devices that can serve as accounting nodes in the blockchain can jointly maintain a transaction idempotence table. For example, each node device that serves as a checkout node can jointly maintain a consensus-based transaction idempotence table through the existing consensus mechanism of the blockchain.

[0121] Among them, the transaction idempotence table is specifically an index record table created based on the valid transactions within the validity period of the above-mentioned transaction, which are successfully included in the storage records of the distributed data of the blockchain (i.e., block records), and is used to store the transaction idempotence records corresponding to all valid transactions successfully included in the distributed database of the blockchain.

[0122] That is, the transaction idempotence record stored in the above-mentioned transaction idempotence table is used to indicate that the transaction corresponding to the transaction idempotence record has been successfully packaged into the candidate block, and the candidate block consensus is finally passed as the latest block on the blockchain and successfully added to the distributed database (i.e., distributed ledger) of the blockchain.

[0123] Before a valid transaction is included in a candidate block, the node device acting as a bookkeeping node can also perform an idempotency check on the transaction based on the above-mentioned transaction idempotency table to confirm whether the transaction is a duplicate transaction that has been successfully included in the distributed database of the blockchain.

[0124] In an illustrated embodiment, in addition to the reference time parameter described above, a transaction created by a user through a client may also carry a unique identifier created by the client for the transaction.

[0125] For example, in actual applications, a node device in a blockchain may be a node device configured with multiple instances, each of which has a unique instance ID. In this case, the transaction serial number may specifically be a unique transaction serial number consisting of the instance ID and a generated random number.

[0126] For another example, if the node device in the blockchain is a distributed device that includes multiple devices, each device has a unique device identifier (such as a device ID, or a device IP address, etc.). In this case, the transaction serial number can specifically be a unique transaction serial number consisting of a device identifier and a generated random number.

[0127] The node device as the accounting node, after determining that a collected transaction is a valid transaction within the transaction validity period, can further query whether the transaction idempotency table stores a transaction idempotency record corresponding to the unique identifier of the transaction;

[0128] On the one hand, if the transaction idempotency record stores a transaction idempotency record corresponding to the unique identifier of the transaction, it indicates that the transaction has been successfully included in the distributed database of the blockchain before, and the transaction is a repeated transaction. In this case, the transaction can be directly discarded;

[0129] On the other hand, if the transaction idempotence record corresponding to the unique identifier of the transaction is not stored in the transaction idempotence record, it indicates that the transaction has not been successfully included in the distributed database of the blockchain before. At this time, the above-mentioned node device can include the transaction in the candidate block.

[0130] In this specification, a node device serving as an accounting node, after generating a candidate block, can further broadcast the generated candidate block in the blockchain, and initiate consensus processing of the transactions included in the candidate block in the blockchain based on the consensus algorithm supported by the blockchain to "compete" for accounting rights.

[0131] Among them, the specific type of consensus algorithm supported by the above-mentioned blockchain is not limited in this specification. In practical applications, standard consensus algorithms such as proof-of-work algorithm, PBFT algorithm, etc. can be adopted, and can also be customized by the operator of the blockchain based on actual business needs.

[0132] When the consensus of the candidate blocks is passed, the node device as the accounting node obtains the accounting authority:

[0133] On the one hand, the candidate block can be added to the distributed database (i.e., distributed ledger) of the blockchain as the latest block on the blockchain. At this time, the candidate block will be permanently stored on the blockchain as a block on the blockchain.

[0134] On the other hand, the node device can trigger the execution of the consensus-approved transactions included in the candidate block in the transaction execution environment of the node device based on the transaction content carried in the transaction. For example, these transactions can be used as inputs of smart contracts that have been published on the blockchain, and the transaction execution program code declared in the smart contract (such as some function calls related to transaction execution) is executed to complete the execution of the transaction in the transaction execution environment of the node device.

[0135] In one embodiment shown, when the target transaction is successfully included in the candidate block, and the candidate block consensus is passed and finally used as the latest block in the blockchain, and successfully stored in the distributed database of the blockchain, the target transaction has been successfully stored in the distributed database of the blockchain (that is, the transaction is successfully uploaded to the chain). In this case, a transaction idempotence record corresponding to the unique identifier of the target transaction can also be generated, and then the transaction idempotence record can be inserted into the transaction idempotence table.

[0136] The specific format of the transaction idempotency record is not particularly limited in this specification; for example, in one method, the transaction idempotency record can be a data record containing a unique identifier of the transaction; or, in another method, the unique identifier of the transaction can be directly inserted into the transaction idempotency table as a transaction idempotency record.

[0137] In this way, since the transaction idempotency records in the transaction idempotency table only cover the transaction idempotency records of all "valid transactions" within the validity period of the above transaction, it is not necessary to store the transaction idempotency records of historical transactions before the transaction validity period. Therefore, for the transaction idempotency table, the storage space consumption will not be too large, and there will be no query performance problems due to excessive storage space consumption of the transaction idempotency table.

[0138] For example, for any node device that can serve as a bookkeeping node, since the transaction idempotence table occupies a small amount of storage space, the transaction idempotence table can be directly loaded and maintained in the device's memory without the need to use a third-party storage disk to store the transaction idempotence table. Query actions on the transaction idempotence table can be run directly in the memory, thereby significantly improving query performance.

[0139] In addition, for all valid transactions, only those transactions that do not have transaction idempotence records in the above-mentioned transaction idempotence record table can be successfully included in the candidate block. Therefore, the "idempotence" problem faced by transaction execution in the blockchain can be avoided, and some illegal nodes can be effectively prevented from launching replay attacks using intercepted valid transactions within the validity period of transactions, resulting in the same valid transaction being executed repeatedly.

[0140] Moreover, in the scenario where multiple instances of node devices in the blockchain are configured, or the node device is a distributed device, it can also effectively avoid the problem of repeated execution of the same valid transaction due to the same valid transaction being published in parallel by different instances or different sub-devices in the distributed device.

[0141] In this specification, since the transaction idempotency table is used to maintain the transaction idempotency records corresponding to the "valid transactions" within the validity period of the transaction, in actual applications, each member node device that jointly maintains the transaction idempotency table can periodically perform clearing processing to timely clear the transaction idempotency records of transactions in the transaction idempotency table that are outside the validity period of the transaction;

[0142] For example, taking the transaction validity period as a time interval set based on the creation time of the candidate block created by the accounting node device in the blockchain within the current accounting cycle, since the creation of the candidate block is periodic, the transaction validity period is also a periodic dynamic time period; in this case, the node device can re-determine the transaction validity period when creating a new candidate block in the next accounting cycle, and then actively search for the transaction idempotence record of the transaction outside the re-determined transaction validity period in the transaction idempotence table; for example, it is still possible to determine whether the transaction is outside the re-determined transaction validity period based on the reference time parameter in the transaction, and the specific implementation process will not be repeated.

[0143] Furthermore, the found transaction idempotency records may be deleted to dynamically update and maintain the transaction idempotency records maintained in the transaction idempotency table, thereby ensuring that the transaction idempotency records in the transaction idempotency table are all transaction idempotency records corresponding to valid transactions within the current transaction validity period.

[0144] Corresponding to the above method embodiments, this specification also provides an embodiment of a transaction processing device based on blockchain. The embodiment of the transaction processing device based on blockchain in this specification can be applied to electronic devices. The device embodiment can be implemented through software, or through hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, if Figure 2 The figure is a hardware structure diagram of the electronic device where the blockchain-based transaction processing device of this specification is located, except Figure 2 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0145] Figure 3 It is a block diagram of a transaction processing device based on blockchain shown in an exemplary embodiment of this specification.

[0146] Please refer to Figure 3 The blockchain-based transaction processing device 30 can be applied in the aforementioned Figure 2 The electronic device shown includes: a receiving module 301 , a determining module 302 and a collecting module 303 .

[0147] The receiving module 301 receives a target transaction initiated by a member node device in the blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within the transaction validity period;

[0148] A determination module 302 determines whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0149] The collection module 303 collects the target transaction into the generated candidate block if it is determined that the target transaction is a valid transaction within the transaction validity period.

[0150] In this embodiment, the reference time parameter is a reference timestamp generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a first value and a second value; the first value is the difference between the creation timestamp of the candidate block and a first threshold; the second value is the sum of the creation timestamp of the candidate block and the second threshold;

[0151] The determination module 302:

[0152] comparing the reference timestamp with the first value and the second value respectively;

[0153] If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

[0154] In this embodiment, the confirmation module 302 further:

[0155] Before comparing the reference timestamp with the first value and the second value respectively, check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; if so, further compare the reference timestamp with the first value and the second value respectively.

[0156] In this embodiment, the reference timestamp is a system timestamp when the target transaction is created; or a reference timestamp specified by a transaction creator.

[0157] In this embodiment, the first threshold is greater than the second threshold.

[0158] In this embodiment, the reference time parameter is the reference block height number generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and the block height number of the candidate block on the blockchain; the third numerical value is the difference between the block height number of the candidate block on the blockchain and the third threshold value;

[0159] The determination module 302:

[0160] Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively;

[0161] If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

[0162] In this embodiment, the determining module 302 further:

[0163] Before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; if so, further compare the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively.

[0164] In this embodiment, the reference block height number is the maximum block height number in the blockchain when the target transaction is created; or, the reference block height number specified by the transaction creator.

[0165] In this embodiment, the target transaction also includes a unique identifier of the target transaction;

[0166] The collection module 303 further:

[0167] If it is determined that the target transaction is a valid transaction within the transaction validity period, query whether a transaction idempotency record corresponding to the unique identifier of the target transaction is stored in a preset transaction idempotency table; wherein the transaction idempotency table is used to store transaction idempotency records corresponding to valid transactions within the transaction validity period;

[0168] If the transaction idempotency table does not store a transaction idempotency record corresponding to the unique identifier of the target transaction, the target transaction is included in the candidate block.

[0169] In this embodiment, the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain;

[0170] The collection module 303 further:

[0171] If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

[0172] In this embodiment, the collection module 303 further:

[0173] Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

[0174] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

[0175] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. A person of ordinary skill in the art can understand and implement it without paying creative labor.

[0176] The systems, devices, modules or modules described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0177] Corresponding to the above method embodiment, this specification also provides an embodiment of an electronic device. The electronic device includes: a processor and a memory for storing machine executable instructions; wherein the processor and the memory are usually connected to each other through an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0178] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to:

[0179] Receiving a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is used to determine whether the target transaction is a valid transaction within a transaction validity period;

[0180] Determining whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter;

[0181] If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block.

[0182] In this embodiment, the reference time parameter is a reference timestamp generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a first value and a second value; the first value is the difference between the creation timestamp of the candidate block and a first threshold; the second value is the sum of the creation timestamp of the candidate block and the second threshold;

[0183] By reading and executing machine-executable instructions stored in the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:

[0184] comparing the reference timestamp with the first value and the second value respectively;

[0185] If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

[0186] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to:

[0187] Before comparing the reference timestamp with the first value and the second value respectively, check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; if so, further compare the reference timestamp with the first value and the second value respectively.

[0188] In this embodiment, the reference time parameter is the reference block height number generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and the block height number of the candidate block on the blockchain; the third numerical value is the difference between the block height number of the candidate block on the blockchain and the third threshold value;

[0189] By reading and executing machine-executable instructions stored in the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:

[0190] Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively;

[0191] If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

[0192] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to:

[0193] Before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; if so, further compare the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively.

[0194] In this embodiment, the target transaction also includes a unique identifier of the target transaction;

[0195] By reading and executing machine-executable instructions stored in the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:

[0196] If it is determined that the target transaction is a valid transaction within the transaction validity period, query whether a transaction idempotency record corresponding to the unique identifier of the target transaction is stored in a preset transaction idempotency table; wherein the transaction idempotency table is used to store transaction idempotency records corresponding to valid transactions within the transaction validity period;

[0197] If the transaction idempotency table does not store a transaction idempotency record corresponding to the unique identifier of the target transaction, the target transaction is included in the candidate block.

[0198] In this embodiment, the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain;

[0199] By reading and executing machine-executable instructions stored in the memory corresponding to control logic for blockchain-based transaction processing, the processor is caused to:

[0200] If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

[0201] In this embodiment, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to:

[0202] Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

[0203] Those skilled in the art will readily appreciate other embodiments of the specification after considering the specification and practicing the invention disclosed herein. The specification is intended to cover any variations, uses, or adaptations of the specification that follow the general principles of the specification and include common knowledge or customary techniques in the art that are not disclosed in the specification. The specification and examples are to be considered exemplary only, and the true scope and spirit of the specification are indicated by the following claims.

[0204] It should be understood that the present description is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.

[0205] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A transaction processing method based on blockchain, comprising: Receive a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is a reference timestamp generated when the target transaction is created; Determining whether the target transaction is a valid transaction within a transaction validity period based on the reference time parameter; If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block; Among them, the transaction validity period includes a numerical range consisting of a first numerical value and a second numerical value; the first numerical value is the difference between the creation timestamp of the candidate block and a first threshold; the second numerical value is the sum of the creation timestamp of the candidate block and the second threshold; the first threshold represents the reserved transaction validity period when setting the transaction validity period, and the order of magnitude of the first threshold is greater than the second threshold, and the order of magnitude of the first threshold is in days.

2. The method according to claim 1, The determining, based on the reference time parameter, whether the target transaction is a valid transaction within the transaction validity period includes: comparing the reference timestamp with the first value and the second value respectively; If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

3. The method according to claim 2, before comparing the reference timestamp with the first value and the second value respectively, further comprising: Check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; If yes, the reference timestamp is further compared with the first value and the second value respectively.

4. The method according to claim 1, wherein the reference timestamp is a system timestamp when the target transaction is created; or a reference timestamp specified by a transaction creator.

5. According to the method of claim 1, the second threshold represents the clock offset between the system timestamp of the node device that issues the transaction and the system timestamp of the node device that creates the candidate block.

6. According to the method of claim 1, the reference time parameter is the reference block height number generated when the target transaction is created; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and the block height number of the candidate block on the blockchain; the third numerical value is the difference between the block height number of the candidate block on the blockchain and a third threshold value; The determining, based on the reference time parameter, whether the target transaction is a valid transaction within the transaction validity period includes: Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively; If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

7. The method according to claim 6, before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, further comprising: Check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; If yes, the reference block height number is further compared with the block height number of the candidate block on the blockchain and the third value respectively.

8. According to the method of claim 6, the reference block height number is the maximum block height number in the blockchain when the target transaction is created; or, the reference block height number specified by the transaction creator.

9. The method according to claim 1, wherein the target transaction further includes a unique identifier of the target transaction; If it is determined that the target transaction is a valid transaction within the transaction validity period, including the target transaction in the generated candidate block includes: If it is determined that the target transaction is a valid transaction within the validity period of the transaction, query whether a transaction idempotency record corresponding to the unique identifier of the target transaction is stored in a preset transaction idempotency table; wherein the transaction idempotency table is used to store transaction idempotency records corresponding to valid transactions within the validity period of the transaction; if the transaction idempotency record corresponding to the unique identifier of the target transaction is not stored in the transaction idempotency table, the target transaction is included in the candidate block.

10. According to the method of claim 9, the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain; Also includes: If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

11. The method according to claim 9 or 10, further comprising: Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

12. A transaction processing device based on blockchain, comprising: A receiving module receives a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is a reference timestamp generated when the target transaction is created; A determination module, which determines whether the target transaction is a valid transaction within a transaction validity period based on the reference time parameter; The collection module includes the target transaction into the generated candidate block if it is determined that the target transaction is a valid transaction within the transaction validity period; Among them, the transaction validity period includes a numerical range consisting of a first numerical value and a second numerical value; the first numerical value is the difference between the creation timestamp of the candidate block and a first threshold; the second numerical value is the sum of the creation timestamp of the candidate block and the second threshold; the first threshold represents the reserved transaction validity period when setting the transaction validity period, and the order of magnitude of the first threshold is greater than the second threshold, and the order of magnitude of the first threshold is in days.

13. The device according to claim 12, wherein the determining module: comparing the reference timestamp with the first value and the second value respectively; If the reference timestamp is greater than the first value and less than the second value, it is determined that the target transaction is a valid transaction within the transaction validity period.

14. The apparatus according to claim 13, wherein the determining module further: Before comparing the reference timestamp with the first value and the second value respectively, check whether the creation timestamp of the candidate block is greater than the creation timestamp of the latest block in the blockchain; if so, further compare the reference timestamp with the first value and the second value respectively.

15. The apparatus according to claim 12, wherein the reference timestamp is a system timestamp when the target transaction is created; or a reference timestamp specified by a transaction creator.

16. According to the device of claim 12, the second threshold represents the clock offset between the system timestamp of the node device that publishes the transaction and the system timestamp of the node device that creates the candidate block.

17. The device according to claim 12, wherein the reference time parameter is a reference block height number generated when creating the target transaction; the transaction validity period corresponds to a numerical interval consisting of a third numerical value and a block height number of the candidate block on the blockchain; the third numerical value is a difference between the block height number of the candidate block on the blockchain and a third threshold value; The determination module: Compare the reference block height with the block height of the candidate block on the blockchain and the third value respectively; If the reference block height number is greater than the third value and less than the block height number of the candidate block on the blockchain, the target transaction is determined to be a valid transaction within the transaction validity period.

18. The apparatus according to claim 17, wherein the determining module further: Before comparing the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively, check whether the block number of the candidate block is greater than the block number of the latest block in the blockchain; if so, further compare the reference block height number with the block height number of the candidate block on the blockchain and the third value respectively.

19. The device according to claim 18, wherein the reference block height number is the maximum block height number in the blockchain when the target transaction is created; or, the reference block height number specified by the transaction creator.

20. The device according to claim 12, wherein the target transaction further includes a unique identifier of the target transaction; The collection module further: If it is determined that the target transaction is a valid transaction within the transaction validity period, query whether a transaction idempotency record corresponding to the unique identifier of the target transaction is stored in a preset transaction idempotency table; wherein, The transaction idempotence table is used to store transaction idempotence records corresponding to valid transactions within the transaction validity period; If the transaction idempotency table does not store a transaction idempotency record corresponding to the unique identifier of the target transaction, the target transaction is included in the candidate block.

21. The apparatus according to claim 20, wherein the transaction idempotence record indicates that the transaction corresponding to the transaction idempotence record has been successfully included in the distributed database of the blockchain; The collection module further: If the target transaction is included in the candidate block, and the candidate block consensus is successfully stored in the distributed database of the blockchain, a transaction idempotence record corresponding to the unique identifier of the target transaction is generated, and the transaction idempotence record is inserted into the transaction idempotence table.

22. The device according to claim 20 or 21, wherein the collection module further: Periodically clear the transaction idempotency records of transactions outside the transaction validity period in the transaction idempotency table.

23. An electronic device, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions corresponding to the control logic of blockchain-based transaction processing stored in the memory, the processor is prompted to: Receive a target transaction initiated by a member node device in a blockchain; wherein the target transaction includes a reference time parameter; the reference time parameter is a reference timestamp generated when the target transaction is created; Determining whether the target transaction is a valid transaction within the transaction validity period based on the reference time parameter; If it is determined that the target transaction is a valid transaction within the transaction validity period, the target transaction is included in the generated candidate block; wherein the transaction validity period includes a numerical range consisting of a first numerical value and a second numerical value; the first numerical value is the difference between the creation timestamp of the candidate block and a first threshold; the second numerical value is the sum of the creation timestamp of the candidate block and the second threshold; the first threshold represents the reserved transaction validity period when setting the transaction validity period, and the order of magnitude of the first threshold is greater than the second threshold, and the order of magnitude of the first threshold is in the day level.

Images