System and method for detecting replay attack

1. A computer-implemented method for detecting replay attack without using account nonce, wherein the method is performed by a blockchain node of a blockchain, the method comprising:

pooling a plurality of identifications of a plurality of candidate transactions by synchronizing an identification database of the blockchain node with one or more identification databases of one or more different blockchain nodes of the blockchain or by receiving one or more of the plurality of candidate transactions from the one or more different blockchain nodes, wherein before the pooling, the plurality of candidate transactions were received by the blockchain node and the one or more different blockchain nodes during a time period starting from a time point when a newest block of the blockchain was added to the blockchain;

storing the pooled identifications of the plurality of candidate transactions in the identification database of the blockchain node;

obtaining a candidate transaction for adding to the blockchain, the obtained candidate transaction comprising a timestamp of the candidate transaction, transaction information of the candidate transaction, and an identification of the candidate transaction, wherein the identification of the candidate transaction comprises a first hash value of at least the timestamp of the candidate transaction and the transaction information of the candidate transaction;

generating a second hash value based at least on the timestamp of the candidate transaction and the transaction information of the candidate transaction;

verifying the identification of the candidate transaction by comparing the first hash value with the second hash value;

verifying whether the timestamp of the candidate transaction is within a validation range corresponding to the time period and whether the identification of the candidate transaction exists in the identification database of the blockchain node; and

in response to determining that the timestamp of the candidate transaction is within the validation range and the identification of the candidate transaction does not exist in the identification database of the blockchain node, determining that the candidate transaction is not associated with replay attack.

2. The method of claim 1 , wherein:

the blockchain is based on one or more features of an Ethereum system, a BFT (Byzantine Fault Tolerance) system, a PBFT (Practical Byzantine Fault Tolerance) system, a HoneyBadger system, or a Hashgraph system.

3. The method of claim 1 , further comprising:

removing, from the identification database of the blockchain node, one or more identifications of one or more candidate transactions that are received by any of the blockchain node and the one or more different blockchain nodes outside the validation range.

4. The method of claim 1 , wherein:

obtaining the candidate transaction for adding to the blockchain comprises receiving the candidate transaction from a user terminal, the received candidate transaction comprising the timestamp of the candidate transaction.

5. The method of claim 1 , wherein obtaining the candidate transaction for adding to the blockchain comprises:

receiving, by the blockchain node, a transaction without the timestamp of the candidate transaction from a user terminal; and

adding, by the blockchain node, the timestamp of the candidate transaction to the received transaction to obtain the candidate transaction.

6. The method of claim 1 , further comprising:

in response to determining that the timestamp of the candidate transaction is within the validation range and the identification of the candidate transaction does not exist in the identification database of the blockchain node, adding the identification of the candidate transaction to the identification database of the blockchain node.

7. The method of claim 1 , further comprising:

in response to determining that the timestamp of the candidate transaction is within the validation range and the identification of the candidate transaction does not exist in the identification database of the blockchain node, adding the candidate transaction to a cache.

8. The method of claim 1 , further comprising:

in response to determining that the timestamp of the candidate transaction is not within the validation range, returning an error message to a computing device that submitted the candidate transaction.

9. The method of claim 1 , further comprising:

in response to determining that the identification of the candidate transaction exists in the identification database of the blockchain node, determining that the candidate transaction is associated with replay attack.

10. The method of claim 1 , further comprising:

performing consensus verification on the candidate transaction determined not to be associated with replay attack.

11. The method of claim 1 , wherein the blockchain node is a primary node of a PBFT (Practical Byzantine Fault Tolerance) system.

12. The method of claim 1 , wherein:

a duration of the validation range is a duration between adding two consecutive blocks to the blockchain.

13. The method of claim 1 , wherein:

the validation range is included in a genesis block of the blockchain.

14. The method of claim 1 , wherein:

the time period is based on an internal clock of the blockchain node.

15. A system for detecting replay attack without using account nonce, wherein the system is associated with a blockchain node of a blockchain and the blockchain, the system comprising one or more processors and one or more non-transitory computer-readable memories coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system to perform operations comprising:

pooling a plurality of identifications of a plurality of candidate transactions by synchronizing an identification database of the blockchain node with one or more identification databases of one or more different blockchain nodes of the blockchain or by receiving one or more of the plurality of candidate transactions from the one or more different blockchain nodes, wherein before the pooling, the plurality of candidate transactions were received by the blockchain node and the one or more different blockchain nodes during a time period starting from a time point when a newest block of the blockchain was added to the blockchain;

storing the pooled identifications of the plurality of candidate transactions in the identification database of the blockchain node;

obtaining a candidate transaction for adding to the blockchain, the obtained candidate transaction comprising a timestamp of the candidate transaction, transaction information of the candidate transaction, and an identification of the candidate transaction, wherein the identification of the candidate transaction comprises a first hash value of at least the timestamp of the candidate transaction and the transaction information of the candidate transaction;

generating a second hash value based at least on the timestamp of the candidate transaction and the transaction information of the candidate transaction;

verifying the identification of the candidate transaction by comparing the first hash value with the second hash value;

verifying whether the timestamp of the candidate transaction is within a validation range corresponding to the time period and whether the identification of the candidate transaction exists in the identification database of the blockchain node; and

in response to determining that the timestamp of the candidate transaction is within the validation range and the identification of the candidate transaction does not exist in the identification database of the blockchain node, determining that the candidate transaction is not associated with replay attack.

16. The system of claim 15 , wherein:

obtaining the candidate transaction for adding to the blockchain comprises receiving the candidate transaction from a user terminal, the received candidate transaction comprising the timestamp of the candidate transaction.

17. The system of claim 15 , wherein obtaining the candidate transaction for adding to the blockchain comprises:

receiving a transaction without the timestamp of the candidate transaction from a user terminal; and

adding the timestamp of the candidate transaction to the received transaction to obtain the candidate transaction.

18. A non-transitory computer-readable storage medium for detecting replay attack without using account nonce, the storage medium associated with a blockchain node of a blockchain, the storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising:

pooling a plurality of identifications of a plurality of candidate transactions by synchronizing an identification database of the blockchain node with one or more identification databases of one or more different blockchain nodes of the blockchain or by receiving one or more of the plurality of candidate transactions from the one or more different blockchain nodes, wherein before the pooling, the plurality of candidate transactions were received by the blockchain node and the one or more different blockchain nodes during a time period starting from a time point when a newest block of the blockchain was added to the blockchain;

storing the pooled identifications of the plurality of candidate transactions in the identification database of the blockchain node;

obtaining a candidate transaction for adding to the blockchain, the obtained candidate transaction comprising a timestamp of the candidate transaction, transaction information of the candidate transaction, and an identification of the candidate transaction, wherein the identification of the candidate transaction comprises a first hash value of at least the timestamp of the candidate transaction and the transaction information of the candidate transaction;

generating a second hash value based at least on the timestamp of the candidate transaction and the transaction information of the candidate transaction;

verifying the identification of the candidate transaction by comparing the first hash value with the second hash value;

verifying whether the timestamp of the candidate transaction is within a validation range corresponding to the time period and whether the identification of the candidate transaction exists in the identification database of the blockchain node; and

in response to determining that the timestamp of the candidate transaction is within the validation range and the identification of the candidate transaction does not exist in the identification database of the blockchain node, determining that the candidate transaction is not associated with replay attack.

19. The storage medium of claim 18 , wherein:

obtaining the candidate transaction for adding to the blockchain comprises receiving the candidate transaction from a user terminal, the received candidate transaction comprising the timestamp of the candidate transaction.

20. The storage medium of claim 18 , wherein obtaining the candidate transaction for adding to the blockchain comprises:

receiving a transaction without the timestamp of the candidate transaction from a user terminal; and

adding the timestamp of the candidate transaction to the received transaction to obtain the candidate transaction.