HK40016605A

HK40016605A - System and method for detecting replay attack

Info

Publication number: HK40016605A
Application number: HK62020006349.8A
Authority: HK
Inventors: 谢桂鲁
Original assignee: 创新先进技术有限公司
Filing date: 2018-12-29
Publication date: 2020-09-11

Description

System and method for detecting replay attacks

Technical Field

The application relates generally to a method and apparatus for detecting replay attacks.

Background

Replay attacks (also known as replay attacks, freshness attacks, man-in-the-middle attacks) are a form of network attack in which effective data transmission is maliciously or fraudulently repeated or delayed. This may be performed by the originator sending to the node (e.g., a server) or by an adversary intercepting the data and resending it to the node. For example, a replay attack may be performed as part of a masquerading attack by Internet Protocol (IP) packet replacement. Another way to describe a replay attack is to: the secure protocol is attacked using a replay of messages from different environments to the intended (or original and desired) environment, thereby spoofing the honest nodes that they have successfully completed the protocol run. For example, the protocol may be a blockchain transaction protocol. The blockchain may branch into two or more sub-chains that follow the same address, encryption key, and transaction system. Legitimate transactions on one child chain may be maliciously repeated on another child chain through replay attacks, causing losses to the sender.

Although the blockchain has various advantages over traditional networks, it is still vulnerable to replay attacks. For example, a transaction that sends 20 ethernet coins (ether) from a to B through the blockchain may be repeated by B in a replay attack to continuously consume the balance of a. Replay attack detection is therefore crucial to defend against malicious blockchain operations and to secure personal property.

Disclosure of Invention

Various embodiments of the present application include systems, methods, and non-transitory computer-readable media for detecting replay attacks.

According to one aspect, a computer-implemented method for detecting replay attacks includes: obtaining at least one candidate transaction for addition to the blockchain, the obtained candidate transaction including a timestamp; verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in an identification database; and responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack.

In some embodiments, the candidate transaction includes a timestamp and transaction information. After obtaining at least one candidate transaction and before verifying whether the identity of the candidate transaction is present in the identity database, the method further comprises: a hash value is determined based at least on the timestamp and the transaction information, the hash value serving as an identification.

In some embodiments, the candidate transaction includes a timestamp, transaction information, and a hash value determined based at least on the timestamp and the transaction information, the hash value serving as the identification. After obtaining at least one candidate transaction and before verifying whether the identity of the candidate transaction is present in the identity database, the method further comprises: the identification is verified by verifying the hash value based at least on the timestamp and the transaction information.

In some embodiments, the timestamp is configured by a user terminal initiating the at least one candidate transaction; and obtaining at least one candidate transaction for addition to the blockchain comprises receiving the candidate transaction from the user terminal.

In some embodiments, the timestamps are configured by block link points; and obtaining at least one candidate transaction for addition to the blockchain comprises: receiving at least one initiated transaction from a user terminal; and adding a timestamp to the initiated transaction to obtain at least one candidate transaction.

In some embodiments, the method further comprises: in response to determining that the timestamp is within the verification range and that the identification is not present in the identification database, adding the identification to the identification database.

In some embodiments, the method further comprises: responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, the candidate transaction is added to a cache for storing the candidate transaction.

In some embodiments, the method further comprises: in response to determining that the timestamp is not within the verification range, an error message is returned to the computing device that submitted the candidate transaction.

In some embodiments, the method further comprises: in response to determining that the identification exists in the identification database, determining that the candidate transaction is associated with a replay attack.

In some embodiments, the method further comprises: performing consensus verification, wherein the candidate transaction is included in the consensus verification if the candidate transaction is determined to be unrelated to a replay attack.

In some embodiments, the method further comprises: synchronizing the identification database with one or more other block link points; verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in a synchronization identification database; responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack; and responsive to determining that the identification exists in the synchronized identification database, determining that the candidate transaction is associated with a replay attack.

In some embodiments, prior to obtaining at least one candidate transaction, the method further comprises: the identification database is synchronized with one or more other blockchain nodes.

In some embodiments, the identification database includes information for transactions having timestamps within a recent time period corresponding to the verification range.

In some embodiments, the verification range is based on another timestamp of the latest block of the block chain; and the verification range is included in the originating block of the blockchain.

In some embodiments, the verification range is based on an internal clock of a blockchain node that performs verification of whether the timestamp is within the verification range.

According to another aspect, a system for detecting replay attacks includes 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: obtaining at least one candidate transaction for addition to the blockchain, the obtained candidate transaction including a timestamp; verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in an identification database; and responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack.

According to another aspect, a non-transitory computer-readable storage medium is configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising: obtaining at least one candidate transaction for addition to the blockchain, the obtained candidate transaction including a timestamp; verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in an identification database; and responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack.

The method and function of operation of these and other features of the system, method and non-transitory computer readable medium, and the related elements of structure, and the combination of parts and economies of manufacture, disclosed herein will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part hereof, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention.

Drawings

Certain features of various embodiments of the technology are set forth with particularity in the appended claims. A better understanding of the features and advantages of the technology will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:

FIG. 1 illustrates an exemplary system for detecting replay attacks according to various embodiments.

FIG. 2 illustrates an exemplary transaction with replay attack detection, in accordance with various embodiments.

FIG. 3 illustrates a flow diagram of an exemplary method for detecting replay attacks in accordance with various embodiments.

Fig. 4A illustrates a flow diagram of an exemplary method for detecting replay attacks, in accordance with various embodiments.

Fig. 4B illustrates a flow diagram of an exemplary method for detecting replay attacks in accordance with various embodiments.

FIG. 5 illustrates a block diagram of an exemplary computer system for detecting replay attacks, in accordance with various embodiments.

FIG. 6 illustrates a block diagram of an exemplary computer system for detecting replay attacks, in accordance with various embodiments.

FIG. 7 illustrates a block diagram of an exemplary computer system in which any of the embodiments described herein can be implemented.

Detailed Description

Blockchains may be considered decentralized databases, often referred to as distributed ledgers, because operations are performed by various nodes (e.g., computing devices) in the network. Any information may be written to and stored in or read from the blockchain. A node is, for example, a computing device or mainframe computer system that supports and smoothes out blockchain networks. Each node may provide some or all of the functionality of the blockchain. For example, a node that provides consensus verification may be referred to as a consensus participant node (or consensus node).

In various embodiments, the consensus may be an algorithm for the rules of the network of blockchain nodes to reach a common accepted processing result. For example, block nodes may receive transactions in different orders due to network lag, which may be addressed by consensus. In one example, under a "proof of work" consensus system, block link points may include equipment that applies their hardware or algorithms to verify blocks of a blockchain and miners receiving rewards. Generating the proof of workload may be a random process with little probability, so on average a large number of trial and error are required before a valid proof of workload can be generated. Bitcoin uses a hashed cash (hashcase) workload certification system. In another example, under a "equity/proof of service" consensus system, a block-linked node with a level of voting authority may be referred to as a consensus node/master node/primary node, as opposed to a non-consensus node, which assumes responsibility for transaction verification. The consensus node may generate a new blockchain and make a decision for the blockchain, e.g., set a service cost for the blockchain. The consensus node may be associated with a large amount of cryptocurrency and validate the new transaction based on certain consensus rules agreed upon in common. Based on the rules determining the consensus node, the attestation of the equity/service consensus system may be implemented as a chain-based attestation of the equity/service consensus system, a byzantine fault-tolerant algorithm (BFT) attestation of the equity/service consensus system, or the like. In this context, a full number of nodes, consensus nodes, or other equivalent nodes in the disclosed or another blockchain system may be used as blockchain node verification transactions. For example, a blockchain system may include public blockchains, federation blockchains, private blockchains, and the like.

Unlike the UTXO (unspent transaction output) model, the etherhouse is based on an account/balance model (or referred to as an account-based transaction model), which keeps track of the balance of each account as a global state. In a transaction, the account balance is checked to ensure that it is greater than or equal to the transaction amount spent. An example of how the account/balance model runs in an etherhouse is provided:

1. alice (Alice) harvested 5 ethernet coins by digging. Alice was recorded in the system with 5 ethernet coins.

2. Alice wants to give Bob (Bob)1 ethernet, so the system will first deduct 1 from alice's account, so alice now has 4 ethernet.

3. The system then adds bob's account with 1 ethernet currency. The system knows that bob initially has 2 ethernet coins, so bob's balance is increased to 3 ethernet coins.

Under the account/balance model, the block link points store the latest state of each smart contract in addition to all ethernet transactions. For each ethernet application, the network may keep track of current information or "state," including account random numbers (account nonces), balances of each user, all smart contract codes (e.g., binary codes), storage space (e.g., for storing hash values).

Unlike the UTXO model, which prevents replay attacks or double spending by defining the available balance as the amount not spent in the last transaction, the conventional account/balance model uses an account random number as a mechanism for screening replay attacks. The account random number is a transaction counter in each account for preventing replay attacks. Although both of the following may exist in the account/balance model, the account random number is distinguished from the workload proof random number in the workload proof consensus system, which is a meaningless value in the block that can be adjusted in an attempt to satisfy the workload proof condition under the UTXO model. Although primarily described with reference to an account/balance model (equity/service attestation system), the disclosed systems and methods are not limited to applications under the account/balance model (e.g., an etherhouse system).

Replay attacks are typically used to illicitly capture revenue by double spending some asset. For the double cost to "succeed", the malicious user will typically: sending a transaction to a party, waiting for transaction registration, collecting material from the first transaction in return, quickly sending another transaction (gas price) at a high air price (gas price) and having the second transaction mined first, thus invalidating the first transaction. The second transaction is typically a copy of the first transaction but with some variation (e.g., time, commission price, recipient or other parameter configured by the sender). The second transaction may use the same identification (e.g., hash value) as the first transaction. Since a higher commission price may attract miners to mine the second transaction first, the second transaction mined before the first transaction may allow a malicious user to maintain a return from the first transaction while performing the second transaction, thereby achieving a double cost. The use of account random numbers is intended to eliminate this problem.

When transactions are conducted at an ether house, a serial number is appended to each transaction at the same account as an account random number. Thus, the account random number may also indicate the number of transactions sent from a given account address. The account random number is maintained by the blockchain network (including its nodes). Each node will process transactions from a particular account in a strict order according to the value of its account random number. Thus, failure to increment the value of the account random number correctly may result in different types of errors. For example, assuming the latest account random number is 121, if the account owner sends a new transaction for the same account with an account random number of 121 or less (attempting to reuse the account random number), the node will reject it. Under the same assumption, if the account owner sends a new transaction with an account random number of 123 or higher, the transaction will not be processed until the omission is eliminated, i.e., until the transaction with account random number 122 has been processed.

As described in the background section, replay attack detection is critical to defend against malicious blockchain operations and to secure personal property. Although blockchains facilitate decentralized consensus verification, it is still vulnerable to replay attacks. In particular, the account random number mechanism has certain disadvantages or shortcomings. For example, to initiate a transaction, the user terminal may need to first obtain an account random number from a block-linked point, thereby increasing the communication burden on the block-linked point. As another example, the account random number mechanism is unreliable for many situations as shown below. In case (1), the account sends a first transaction and a subsequent second transaction with the same transaction fee to the same blockchain node. However, if the blockchain node receives the second transaction before the first transaction due to out-of-order network packet transmission, the blockchain node will execute the second transaction and then execute the first transaction, resulting in failure to execute both transactions due to non-compliance with the account random number mechanism. In case (2), the account sends the first transaction and a subsequent second transaction with a higher transaction fee to the same blockchain node. To maximize revenue, the block link points may be programmed to preferentially execute the second transaction and then execute the first transaction, resulting in failure to execute both transactions due to non-compliance with the account random number mechanism. In case (3), the account sends different transactions in parallel from various user terminals, but these transactions will have the same account random number value. As a result, at most one transaction will be successfully processed.

In order to at least alleviate the drawbacks of the prior art, to provide a technical solution to the above technical problem and to improve computer functionality, a system and a method for detecting replay attacks are disclosed. As described below, in various embodiments, a combination of timestamp verification and transaction identification verification may be used in place of the use of account random numbers to enable robust replay attack detection. Thus, malicious transactions can be identified and discarded from honest transactions in a timely manner.

Fig. 1 illustrates an exemplary system 100 for performing various disclosed steps and methods, in accordance with various embodiments. As shown, the blockchain network may include a plurality of blockchain nodes (e.g., node 1, node 2, node 3, node 4, node i, etc.). The blockchain nodes may form a network (e.g., a point-to-point network) in which one blockchain node communicates with another blockchain node. The order and number of blockchain nodes shown are merely exemplary and for simplicity of illustration. The blockchain node may be implemented in a server, a computer, or the like. Each block link point may correspond to one or more physical hardware devices or virtual devices coupled together via various types of communication methods, such as TCP/IP. According to the classification, the block link points may include a full node, a Geth node, a consensus node, and the like.

In various embodiments, user a and user B may use respective devices such as laptops and mobile phones to trigger blockchain nodes to perform transactions, which may or may not involve blockchain contracts (e.g., smart contracts). In one example, user A may want to conduct a transaction with user B by transferring some assets in user A's account to user B's account. User a and user B may initiate, forward or access transactions using respective devices node a and node B (also referred to as user terminals) that have appropriate blockchain software (e.g., cryptographic currency wallets) installed. User a's device node a may be referred to as an initiator node, which initiates a transaction with user B's device node B (referred to as a recipient node). Node a may access the blockchain by communicating with node 1 and node B may access the blockchain by communicating with node 2. Node a, node B, or the like may request that a transaction be added to the blockchain by submitting the transaction to the blockchain through node 1, node 2, or the like. Outside the blockchain, node a and node B may have other communication channels (e.g., not going through regular internet communication of node 1 and node 2). In some embodiments, the blockchain software on node a may be considered the front end of blockchain link point 1, and blockchain node 1 runs the back end of the blockchain software.

Each node in fig. 1 may include a processor and a non-transitory computer-readable storage medium configured with instructions executable by the processor to cause the node (e.g., processor) to perform various operations for detecting replay attacks described herein. Each node may be installed with software (e.g., a transaction program) and/or hardware (e.g., wired, wireless connections) to communicate with other nodes and/or other devices. For example, user devices such as node a and node B may be installed with user side software such as cryptographic currency wallets, and blockchain nodes may be installed with blockchain transaction processing software. Further details of the node hardware and software will be described later with reference to fig. 5-7.

The blockchain nodes may each include or be coupled to a memory. In some embodiments, the memory may store a pool database. The pool database may be accessed by a plurality of block chain nodes in a distributed manner. For example, the pool databases may be stored in the memory of the blockchain nodes, respectively. The pool database may store a plurality of transactions submitted by one or more user devices (e.g., nodes a and B operated by users). In some embodiments for an etherhouse system, after receiving a transaction request for an unconfirmed transaction, the recipient blockchain nexus may perform some preliminary verification of the transaction. For example, referring to fig. 1, node 1 may perform a preliminary verification after receiving a transaction from node a. Once verified, the transaction may be stored in a pool database of the recipient blockchain node, which may also forward the transaction to one or more other blockchain nodes (e.g., node 3, node 4) that repeat the processing done by the recipient node. Once the transactions in the respective pool database reach a certain level, each blockchain node may validate a batch of transactions in the respective pool database according to consensus rules or another method. If the transaction involves a blockchain contract, the blockchain contract may be executed locally at the blockchain link point. A particular blockchain node that successfully validates its batch of transactions (e.g., according to consensus rules) may package the transactions for addition to a local copy of its blockchain and propagate the results to other blockchain nodes. A particular chunk chain node may be a node that first completes a successful authentication, a node that has gained authentication privileges, or a node determined based on another consensus rule. Other blockchain nodes may perform transactions locally (e.g., by performing hash calculations), verify the execution results to each other, and synchronize copies of blockchains with copies of particular blockchain nodes. By updating a local copy of the blockchain, the blockchain nexus can write such information to local memory. If the verification fails at some point, the transaction is denied.

In some embodiments, the initiator node may initiate transaction X of 2 Ethercoins from account 3df53h (Account A) to account 45wqr1 (Account B). Before the transaction, account A has 10 Ether coins and account B has 1 Ether coin. Transaction X may be submitted by an initiator node (e.g., computer, mobile phone) to a blockchain node (e.g., a quorum node). Transaction X may be associated with a timestamp such as: submitting, by the initiator node, a point in time for transaction X through the block link points; the point in time at which the block link point submits transaction X; or the point in time at which transaction X is received by another blockchain node performing consensus verification. Transaction X may be referred to as a candidate transaction before being verified and added to the blockchain. The blockchain node may save candidate transaction X in the pool database along with other candidate transactions. The blockchain node may save an identification (e.g., hash value) of transaction X into an identification database (e.g., hash value table).

In some embodiments, a plurality of blockchain nodes may validate candidate transactions of the pool database according to consensus rules. For example, the block link points may verify that the sending account has sufficient funds, that the sender and recipient have issued the transaction, that the transaction amount is within an allowed range, and so on. With consensus verification, the block nodes may synchronize their identification databases to include all transaction identifications stored in the identification databases. For example, the identification databases may each store transactions for a particular recent time period. For replay attack detection, the block chain node may verify whether the timestamp of the candidate transaction is within the recent time period, and if so, screen the candidate transaction against the replay attack that violates the identification database.

The timestamp and identity verification may be performed once or twice after the consensus verification: before and after consensus verification. If compliance is met, the blockchain nexus may package the validated candidate transactions into a new block for addition to the blockchain. Thus, when transaction X is added to the blockchain, transaction X identifying account a, which transfers 2 ethernet coins to account B, will be identified.

Fig. 3 illustrates exemplary steps 300 for replay attack detection, in accordance with various embodiments. Step 300 may be implemented by one or more components of system 100 of fig. 1 (e.g., node a, node 1, a combination of node a and node 1, node 2, node i). The operations listed below are for reference only. Depending on the implementation, the exemplary steps 300 may include additional, fewer, or alternative steps performed in various orders or in parallel.

In various embodiments, as previously described, a timestamp is added to the transaction, for example, under an account/balance model. In one example, a transaction initiator node (e.g., node a in fig. 1) or an alternative user terminal may add a timestamp (e.g., a timestamp parameter) to the submission of the unconfirmed transaction for validation by the blockchain node. Alternatively, a blockchain node (e.g., node 1 in fig. 1) receiving an unconfirmed transaction may add a timestamp. The time stamp may be accurate to various levels (e.g., milliseconds). As the accuracy of the time stamp increases, the disclosed systems and methods may support more transactions initiated by one account per unit time. For example, if the time stamp is accurate to 10ms, the disclosed systems and methods can support up to about 100 different transactions initiated by the same account recorded on 100 different user terminals, while excluding those transactions intended as replay attacks.

In some embodiments, the authentication scope may be used to overcome at least the disadvantages of account random numbers described above. The verification scope is a time window in which recent transactions are screened for replay attacks. The verification range may be defined relative to a common standard, for example, a time period from the timestamp of the latest chunk of the blockchain after the timestamp of the latest chunk is generally accepted in the blockchain. For example, the latest tile of the chain of tiles may be added at Beijing time 2018, 6/month 8, 08:42:44, and the verification range may be two hours before and/or after that time. The local time of the node (e.g., based on an internal clock) may be used instead prior to consensus verification. Before and after consensus verification, the local time of the node may be used instead if the internal clock of the node substantially conforms to the common standard. The verification range may be long enough to maintain replay attack detection efficiency and short enough to limit data storage requirements. Verification scopes may be included in the origination block (the first block since history) of the block chain to ensure that each block link point agrees and uses the same verification scope. With the scope of authentication, replay attack detection does not require synchronization between the time of the initiator node and the time of the block chain node, nor does it require system time synchronization between different block chain nodes. Also, the block nodes may validate the same candidate transactions at different times and still achieve the same results.

In some embodiments, upon receiving a candidate transaction, the blockchain node may validate a timestamp of the candidate transaction based on the validation range. With successful verification of the timestamp and no replay attack detected, the chunk chain node may also store the identity of the candidate transaction in the verification scope. For example, a block nexus may store a hash value of the validated transaction in a transaction hash value table in memory (e.g., cache) of the block nexus. The cache memory may enable fast data lookup from the transaction hash table, thereby improving overall transaction efficiency (e.g., increasing the number of transactions per second). The stored hash value table may store information for a most recent period of time (e.g., the last two hours) corresponding to the verification range. By using the verification range, the block chaining point no longer needs to search the entire block chain for a replay attack, which usually takes a long time to search from the hard disk, and this time increases as blocks are continuously added to the block chain. In contrast, searching from the cache memory corresponding to the information gathered from the authentication scope may significantly improve the efficiency of replay attack detection. The decomposition of these steps is described below.

At step 301, a blockchain nexus may obtain candidate transactions submitted by an initiator node for validation and addition to the blockchain. At step 302, the block link point may verify the transaction timestamp. If the verification is successful, step 303 is performed and the blockchain node determines if the transaction hash value for the candidate transaction exists in the hash value table. The hash value table may store hash values for all transactions over a time period corresponding to the verification range. If the transaction hash value for the candidate transaction is already in the hash value table, it indicates that the candidate transaction may be associated with a replay attack and that the verification failed. Otherwise, the verification is successful at step 304, and the blockware endpoint saves the transaction hash value to the hash value table at step 305. If the verification in step 302 fails, step 306 is performed and an error message may be returned to the user terminal that submitted the transaction. If the determination in step 303 fails, step 306 is performed and the transaction with the earliest timestamp is considered as the real transaction and all subsequent transactions are considered as potential replay attacks and discarded. The hash value for subsequent transactions may also be purged from the hash value table.

In some embodiments, for a consensus protocol that allows each node to initiate a mine of transactions (verify transactions according to a consensus rule), replay attacks may target various blockchain nodes and the target blockchain node may not detect a threat until transaction verification is performed according to the consensus rule. Therefore, after the block node performs transaction verification according to the consensus rule, the block node can obtain the complete information of the hash table and perform steps 302 to 305 to screen for replay attacks. Thus, steps 302 through 305 may be performed after the block link point performs transaction verification according to the consensus rule. However, steps 302-305 may be performed additionally before the block node performs transaction verification according to the consensus rule. By performing steps 302 through 305 prior to transaction verification, potential replay attacks may be initially cleared. That is, steps 302 through 305 may be performed before and after (1) or after (2) the transaction is validated according to the consensus rule. Whether performed once or twice, steps 302 and 303 may be performed in any order without affecting the results.

Fig. 4A illustrates a flow diagram of an exemplary method 400 for detecting a replay attack according to various embodiments herein. Method 400 may be implemented by one or more components of system 100 of fig. 1 (e.g., node 1, a combination of node a and node 1, node 2. The method 400 may be implemented by one or more blockchain nodes. The method 400 may be implemented by a system or device (e.g., computer, server). A system or device may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the method 400. The operations of method 400 presented below are intended to be illustrative. Depending on the implementation, the exemplary method 400 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 441 includes: at least one candidate transaction for addition to the blockchain is obtained, the obtained candidate transaction including a timestamp. In some embodiments, the blockchain may be based on an account/balance model (e.g., an ethernet system, a BFT system (e.g., a pragmatine fault tolerant (PBFT) system), a HoneyBadger, or a Hashgraph system), but the disclosed system replaces the use of account random numbers (if any) to detect replay attacks.

In some embodiments, the candidate transaction includes a timestamp, transaction information, and a hash value determined based at least on the timestamp and the transaction information, the hash value serving as the identification. After obtaining at least one candidate transaction and before verifying whether the identity of the candidate transaction is present in the identity database, the method further comprises: the identification is verified by verifying the hash value based at least on the timestamp and the transaction information. For example, the candidate transaction may include one or more parameters such as a timestamp, a sender (transaction sender address), a receiver (transaction receiver address), a value (transaction item), data (blockchain contract, if any), transaction payment (e.g., air limit (gas limit), air value (gas value)), a hash value (a hash value that serves as a unique identification of the transaction), and/or other information (e.g., a signature (sender signed proof)). These parameters may be collectively referred to as a transaction structure. The included parameters other than the timestamp (and signature) may be referred to as transaction information. The hash value may be determined (e.g., by a node such as node a that initiated the candidate transaction) based on the transaction information (e.g., by a hash function having the timestamp and the transaction information as inputs). To verify the hash value based at least on the timestamp and the transaction information, the blockchain node (e.g., node 1) that obtained the candidate transaction may recalculate the hash function with the input to check the hash value.

In some embodiments, the candidate transaction includes a timestamp and transaction information. After obtaining at least one candidate transaction and before verifying whether the identity of the candidate transaction is present in the identity database, the method further comprises: a hash value is determined based at least on the timestamp and the transaction information, the hash value serving as an identification. For example, the candidate transaction may include one or more parameters such as a timestamp, sender, recipient, value, data, transaction payment, and/or other information. The included parameters other than the time stamp may be referred to as transaction information. The hash value may be determined (e.g., by a blockchain node such as node 1 receiving the candidate transaction) based on the timestamp and the transaction information (e.g., by a hash function having the timestamp and the transaction information as inputs).

In some embodiments, the timestamp is configured by a user terminal initiating the at least one candidate transaction; and obtaining at least one candidate transaction for addition to the blockchain comprises: a candidate transaction is received from a user terminal. For example, the user terminal may be node a in fig. 1, which sends the candidate transaction to node 1. Node a may have added a timestamp to the candidate transaction before sending it to node 1.

In some embodiments, the timestamps are configured by block link points; and obtaining at least one candidate transaction for addition to the blockchain comprises: receiving at least one initiated transaction from a user terminal; and adding a timestamp to the initiated transaction to obtain at least one candidate transaction. For example, the user terminal may be node a in fig. 1, which sends the candidate transaction to node 1. Node a may not have added a timestamp to the candidate transaction and node 1 may add a timestamp to the received candidate transaction. As the first blockchain node to receive a candidate transaction, node 1 may add a timestamp according to its internal clock or alternate time source. Other blockchain nodes may obtain the timestamp added by node 1 once they later receive the candidate transaction.

Block 442 includes: whether the verification timestamp is within the verification range and whether an identification (e.g., a hash value or a selectable identification) of the candidate transaction is present in an identification database (e.g., a hash value table). The verification of the timestamps and the verification of the identification may be performed in any order. The identification database may be stored in a storage medium. The identification database may be stored in a cache memory.

In some embodiments, the verification range is based on another timestamp of the latest block of the blockchain (e.g., another timestamp universally agreed by the blockchain network + the verification range from the other timestamp); and the verification range is included in the originating block of the blockchain.

In some embodiments, the verification range is based on an internal clock of a blockchain node that performs a verification whether the timestamp is within the verification range.

In some embodiments, the identification database includes information for transactions having timestamps within a recent time period corresponding to the verification range. For example, each blockchain nexus may maintain an identification database to store hash values for candidate transactions received by the blockchain nexus within two hours from the timestamp of the newest block of the blockchain. Blockchain nodes may synchronize their identification databases at each consensus verification to assemble the stored hash values. After each consensus verification, a new chunk may be added to the blockchain, and the timestamp of the latest chunk of the blockchain advanced in time. For example, the latest tile of the tile chain may be added at 5 am on a particular date, and the verification range may be 5 am to 7 am on that particular date. Then, after adding a new block at 7 am, the verification range becomes 7 am to 9 am of the specific date. Thus, the hash values in the identification database may be updated by adding hash values within the verification range and/or removing hash values outside the verification range. Each hash value may be associated with a corresponding timestamp to determine whether the hash value is within or outside of the verification range.

Block 443 includes: responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack.

In some embodiments, the method 400 further comprises: in response to determining that the timestamp is within the verification range and that the identification is not present in the identification database, adding the identification to the identification database.

In some embodiments, the method 400 further comprises: responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, the candidate transaction is added to a cache for storing the candidate transaction. For example, the cache may be a pool database. The cache may also store an identification database (e.g., a hash table).

In some embodiments, the method 400 further comprises: in response to determining that the timestamp is not within the verification range, an error message is returned to the computing device that submitted the candidate transaction. The candidate transaction may or may not be associated with a replay attack, but is still an invalid transaction because it is outside the verification range (e.g., long before the current time). Thus, candidate transactions are rejected for addition to the blockchain.

In some embodiments, the method 400 further comprises: in response to determining that the identification exists in the identification database, determining that the candidate transaction is associated with a replay attack. Thus, candidate transactions are denied being added to the blockchain.

The method 400 may be implemented in various blockchain systems (e.g., an etherhouse system, a PBFT system, a HoneyBadger or Hashgraph system, etc.). In some embodiments, the method further comprises: performing consensus verification, wherein the candidate transaction is included in the consensus verification if the candidate transaction is determined to be unrelated to a replay attack. For example, in an ethernet system, time stamping and identification verification may be performed before a consensus node performs a round of consensus verification. In any of the disclosed blockchain systems, performing consensus verification may not be able to detect replay attacks, whereas the disclosed methods may enable replay attack detection.

In some embodiments, the method 400 further comprises: synchronizing the identification database with one or more other block link points; verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction exists in a synchronized identification database; responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not associated with a replay attack; and responsive to determining that the identification exists in the synchronized identification database, determining that the candidate transaction is associated with a replay attack. For example, in an ethernet system, optionally, the time stamp and identity verification may be performed again after the consensus node performs a round of consensus verification. Through consensus verification, the identity database and/or pool database may be synchronized between block-link points.

In some embodiments, prior to obtaining at least one candidate transaction, the method 400 further comprises: the identification database is synchronized with one or more other blockchain nodes. For example, in a PBFT system, a single blockchain node (e.g., a primary node) may be responsible for initiating consensus verification. After receiving the candidate transaction, a non-primary blockchain node (e.g., backup node) may forward the candidate transaction to the primary node. The primary node may perform method 400 after receiving the candidate transaction and before performing consensus verification. After performing consensus verification, the non-primary nodes may synchronize their candidate transaction lists with the primary node to perform the candidate transactions. Thus, after consensus verification and prior to executing the candidate transaction, the non-primary node may or may not perform method 400.

For another example, in a HoneyBadger or Hashgraph system, each blockchain node may not forward candidate transactions it receives. Each blockchain node may initiate consensus verification of the received candidate transaction. Thus, if the real transaction and replay attack transaction are sent separately to two different blockchain nodes that both perform method 400, both transactions may pass. To detect replay attacks, after performing consensus verification, the block nodes may share candidate transactions that pass consensus verification and then perform the method 400 again. That is, the tile link points in the HoneyBadger or Hashgraph system may synchronize their identification databases and/or their pool databases and perform method 400. By performing the method 400 after consensus verification, the blockchain link point may add a new transaction to the blockchain (e.g., by writing an updated blockchain to local memory).

Fig. 4B illustrates a flow diagram of an exemplary method 450 for detecting replay attacks according to various embodiments herein. Method 450 may be implemented by one or more components of system 100 of fig. 1 (e.g., node 1, a combination of node a and node 1, node 2. Method 450 may be implemented by one or more blockchain nodes. The method 450 may be implemented by a system or device (e.g., computer, server). The system or device may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause the system or device (e.g., the processors) to perform the method 450. The operations of method 450 presented below are intended to be illustrative. Depending on the implementation, the example method 450 may include additional, fewer, or alternative steps performed in various orders or in parallel.

Block 451 includes: at least one candidate transaction for addition to the blockchain is obtained. The obtained candidate transaction may include a timestamp.

Block 452 includes: an identification (e.g., a hash value or a selectable identification) of the candidate transaction is verified as being present in an identification database (e.g., a hash table of a pool database) that includes a plurality of identifications within a verification scope. For example, if the verification range is two hours from the latest block of the identification database, the identification of candidate transactions having corresponding timestamps that are within two hours may be maintained. As new tiles are added to the chain of tiles, the verification range also advances in time. For example, the latest tile of the tile chain may be added at 5 am on a particular date, and the verification range may be 5 am to 7 am on that particular date. Then, after adding a new tile at 7 am, the verification range becomes 7 am to 9 am of the particular date.

Block 453 includes: in response to determining that the identification does not exist in the identification database, determining that the candidate transaction is not associated with a replay attack.

The various terms, embodiments, and examples of method 400 described above may be similarly applied to method 450.

In this manner, the disclosed systems and methods may mitigate or overcome deficiencies in the prior art to enable robust replay attack detection. By replacing the account random number with the disclosed combination of time stamp and identity verification, the user terminal no longer needs to query the block link points for random values. Thus, the communication costs between the user terminal and the block chain node are reduced.

For case (1), the account sends a first transaction and a subsequent second transaction with the same transaction fee to the same blockchain node. However, if the blockchain node receives a second transaction before the first transaction due to out-of-order network packet transmission, the blockchain node will execute the second transaction and then execute the first transaction, resulting in a failure to execute both transactions due to non-compliance with the account nonce mechanism. The disclosed systems and methods may replace the account nonce mechanism with a timestamp and/or identity verification so that valid transactions from the same account may not necessarily be performed in a predefined order. That is, the order in which valid transactions are received from the same account does not prevent successful execution of the transactions.

For case (2), the account sends the first transaction and then a second transaction with a higher transaction fee to the same blockchain node. To maximize revenue, the blockchain nexus may be programmed to preferentially execute the second transaction and then the first transaction, resulting in failure of both transactions to execute due to non-adherence to the account random number mechanism. The disclosed system and method may prevent this problem because, similar to case (1), the order in which valid transactions are received from the same account does not prevent successful execution of the transactions.

In case (3), the account sends different transactions in parallel from various user terminals, but these transactions will have the same account random number value. As a result, at most one transaction will be successfully processed under the account random number mechanism. Because the account random number is discarded, the disclosed systems and methods may prevent this problem and allow for the successful execution of all transactions. Also, as previously described, the accuracy of the timestamp may support the execution of a large number of transactions initiated by the same account that are substantially close in time before a new block is added.

Moreover, screening replay attacks before and after (or immediately after) verifying the candidate transaction according to consensus rules of the blockchain may ease the burden of the original consensus verification including verifying the account random number. The use of a verification range significantly reduces the size of the database to be searched and does not require searching the entire blockchain. Thus, the identification database allows replay attacks to be screened in an efficient and cost-effective manner. Furthermore, the association of timestamps with verification scopes allows multiple transactions to be submitted from the same account in any order without causing interruption of transaction processing. Furthermore, the authentication scope avoids the need for synchronization between the user terminal and the blockchain node, and the blockchain node can authenticate the same transaction at different times to achieve the same authentication result.

The techniques described herein are implemented by one or more special-purpose computing devices. A special-purpose computing device may be a desktop computer system, a server computer system, a portable computer system, a handheld device, a network device, or any other device or combination of devices that contain hardwired and/or program logic to implement the techniques. Computing devices are typically controlled and coordinated by operating system software. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file systems, networking, I/O services, and provide user interface functions (e.g., a graphical user interface ("GUI")), etc.

FIG. 5 illustrates a block diagram of an exemplary computer system 550 for implementing a blockchain contract, in accordance with various embodiments. System 550 may be an exemplary implementation of node 1, a combination of node a and node 1, node 2. The method 400 may be implemented by a computer system 550. The computer system 550 may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause a system or device (e.g., a processor) to perform the method 400. The computer system 550 may include various units/modules corresponding to instructions (e.g., software instructions). In some embodiments, the computer system 550 may include: a first obtaining module 551 configured to obtain at least one candidate transaction for addition to a blockchain, the obtained candidate transaction comprising a timestamp; a first verification module 552 configured to verify whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in an identification database; a first determination module 553 configured to determine that the candidate transaction is not associated with a replay attack in response to determining that the timestamp is within the verification range and that the identification is not present in the identification database.

FIG. 6 illustrates a block diagram of an exemplary computer system 560 for implementing a blockchain contract, in accordance with various embodiments. System 560 may be an exemplary implementation of node 1, a combination of node a and node 1, node 2. The method 450 may be implemented by a computer system 560. The computer system 560 may include one or more processors and one or more non-transitory computer-readable storage media (e.g., one or more memories) coupled to the one or more processors and configured with instructions executable by the one or more processors to cause a system or device (e.g., a processor) to perform the method 450. The computer system 560 may include various units/modules corresponding to instructions (e.g., software instructions). In some embodiments, computer system 560 may include: a second obtaining module 561 configured to obtain at least one candidate transaction for addition to the blockchain; a second verification module 562 configured to verify whether the identity of the candidate transaction is present in an identity database comprising a plurality of identities located within a verification range; a second determination module 563 configured to determine that the candidate transaction is not related to a replay attack in response to determining that the identity does not exist in the identity database.

FIG. 7 is a block diagram that illustrates a computer system 700 upon which any of the embodiments described herein may be implemented. System 700 may be implemented in any node described herein and configured to perform the respective steps for enforcing a blockchain contract. Computer system 700 includes a bus 702 or other communication mechanism for communicating information, and one or more hardware processors 704 coupled with bus 702 for processing information. The hardware processor 704 may be, for example, one or more general-purpose microprocessors.

Computer system 700 also includes a main memory 706, such as a Random Access Memory (RAM), cache memory, and/or other dynamic storage device, coupled to bus 702 for storing information and instructions to be executed by processor 704. Main memory 706 also may be used for storing temporary variables or other intermediate information to be executed by processor(s) 704 during execution of instructions. When stored in a storage medium accessible to processor 704, these instructions cause computer system 700 to appear as a special-purpose machine that is customized to perform the operations specified in the instructions. Computer system 700 also includes a Read Only Memory (ROM)708 or other static storage device coupled to bus 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to bus 702 for storing information and instructions.

Computer system 700 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware and/or program logic that in combination with the computer system causes computer system 700 to become a special-purpose machine or programs computer system 700 to become a special-purpose machine. According to one embodiment, the operations, methods, and processes described herein are performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 706. Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequences of instructions contained in main memory 706 causes processor 704 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

Main memory 706, ROM 708, and/or storage 710 may include non-transitory storage media. The term "non-transitory medium" and similar terms, as used herein, refers to a medium that stores data and/or instructions to cause a machine to operate in a specific manner, the medium not including transient signals. Such non-transitory media may include non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 710. Volatile media includes dynamic memory, such as main memory 706. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions thereof.

Computer system 700 also includes a network interface 718 coupled to bus 702. Network interface 718 provides a two-way data communication coupling to one or more network links connected to one or more local networks. For example, network interface 718 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface 718 may be a Local Area Network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component in communication with the WAN). Wireless links may also be implemented. In any such implementation, network interface 718 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

Computer system 700 can send messages and receive data, including program code, through the network(s), network link and network interface 718. In the Internet example, a server might transmit a requested code for an application program through the Internet, an ISP, local network and network interface 718.

The received code may be executed by processor 704 as it is received, and/or stored in storage device 710, or other non-volatile storage for later execution.

Each of the processes, methods, and algorithms described in the preceding sections may be implemented in code modules executed by one or more computer systems or computer processors comprising computer hardware, and be fully or partially automated. The processes and algorithms may be implemented in part or in whole in application specific circuitry.

The various features and processes described above may be used independently of one another or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of the present disclosure. Additionally, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be performed in other suitable orders. For example, described blocks or states may be performed in an order different than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The exemplary blocks or states may be performed in series, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed exemplary embodiments. The exemplary systems and components described herein may be configured differently than described. For example, elements may be added, removed, or rearranged compared to the disclosed exemplary embodiments.

Various operations of the example methods described herein may be performed, at least in part, by algorithms. The algorithms may be included in program code or instructions stored in a memory (e.g., the non-transitory computer-readable storage medium described above). Such algorithms may include machine learning algorithms. In some embodiments, the machine learning algorithm may not explicitly program the computer to perform a function, but may learn from training data to build a predictive model that performs the function.

Various operations of the example methods described herein may be performed, at least in part, by one or more processors (e.g., via software) that are temporarily configured or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such a processor may constitute a processor-implemented engine that operates to perform one or more operations or functions described herein.

Similarly, the methods described herein may be implemented at least in part by a processor, where a particular processor or processors are examples of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented engines. Further, the one or more processors may also be operable to support performance of related operations in a "cloud computing" environment, or to operate as a "software as a service" (SaaS). For example, at least some of the operations may be performed by a set of computers (e.g., machines including processors), which may be accessed via a network (e.g., the internet) and via one or more appropriate interfaces (e.g., Application Program Interfaces (APIs)).

Some operating performance may be distributed among the processors, not only residing within a single machine, but also being deployed across multiple machines. In some exemplary embodiments, the processor or processor-implemented engine may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other exemplary embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

Throughout the specification, multiple instances may implement a component, an operation, or a structure described as a single instance. While various operations of one or more methods are shown and described as separate operations, one or more of the individual operations may be performed concurrently and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the subject matter herein.

Although the summary of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes may be made to the embodiments without departing from the broader scope of the embodiments of the invention. Such embodiments of the subject matter may be referred to herein, individually or collectively, by the term "invention" merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or concept if more than one is in fact disclosed. The detailed description is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims

1. A computer-implemented method for detecting replay attacks, the method comprising:

obtaining at least one candidate transaction for addition to the blockchain, the obtained candidate transaction including a timestamp;

verifying whether the timestamp is within a verification range and whether the identity of the candidate transaction is present in an identity database; and

determining that the candidate transaction is not associated with a replay attack in response to determining that the timestamp is within the verification range and that the identification is not present in the identification database.

2. The method of claim 1, wherein,

the candidate transaction includes the timestamp and transaction information; and is

After obtaining the at least one candidate transaction and before verifying whether the identification of the candidate transaction is present in the identification database, the method further comprises: determining a hash value based on at least the timestamp and the transaction information, the hash value serving as the identification.

3. The method of claim 1, wherein,

the candidate transaction includes the timestamp, transaction information, and a hash value determined based at least on the timestamp and the transaction information, the hash value serving as the identification; and is

After obtaining the at least one candidate transaction and before verifying whether the identification of the candidate transaction is present in the identification database, the method further comprises: verifying the identification by verifying the hash value based at least on the timestamp and the transaction information.

4. The method of claim 1, wherein,

the timestamp is configured by a user terminal initiating the at least one candidate transaction; and is

Obtaining the at least one candidate transaction for addition to the blockchain, including: receiving the candidate transaction from the user terminal.

5. The method of claim 1, wherein,

the time stamps are configured by block link points; and is

Obtaining the at least one candidate transaction for addition to the blockchain, including:

receiving at least one initiated transaction from a user terminal; and

adding the timestamp to the initiated transaction to obtain the at least one candidate transaction.

6. The method of claim 1, further comprising:

in response to determining that the timestamp is within the verification range and that the identity is not present in the identity database, adding the identity to the identity database.

7. The method of claim 1, further comprising:

in response to determining that the timestamp is within the verification range and that the identification is not present in the identification database, adding the candidate transaction to a cache for storing candidate transactions.

8. The method of claim 1, further comprising:

in response to determining that the timestamp is not within the verification 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 is present in the identification database, determining that the candidate transaction is associated with the replay attack.

10. The method of claim 9, further comprising:

performing consensus verification, wherein the candidate transaction is included in the consensus verification if the candidate transaction is determined to be unrelated to the replay attack.

11. The method of claim 10, further comprising:

synchronizing the identification database with one or more other tile link points;

verifying whether the timestamp is within the verification range and whether the identification of the candidate transaction is present in the synchronized identification database;

responsive to determining that the timestamp is within the verification range and that the identification is not present in the identification database, determining that the candidate transaction is not related to the replay attack; and

determining that the candidate transaction is associated with the replay attack in response to determining that the identification is present in the synchronized identification database.

12. The method of claim 1, further comprising, prior to obtaining the at least one candidate transaction:

synchronizing the identification database with one or more other tile link points.

13. The method of claim 1, wherein,

the identification database includes information for transactions having timestamps within a recent time period corresponding to the verification scope.

14. The method of claim 1, wherein,

the verification range is based on another timestamp of a latest block of the block chain; and is

The verification range is included in an originating block of the block chain.

15. The method of claim 1, wherein:

the verification range is based on an internal clock of a blockchain node that performs verification of whether the timestamp is within the verification range.

16. A system for detecting replay attacks, 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:

17. The system of claim 16, wherein,

the candidate transaction includes the timestamp and transaction information; and

18. The system of claim 16, wherein,

the candidate transaction includes the timestamp, transaction information, and a hash value determined based at least on the timestamp and the transaction information, the hash value serving as the identification; and

19. The system of claim 16, wherein,

the timestamp is configured by a user terminal initiating the at least one candidate transaction; and

20. The system of claim 16, wherein,

the time stamps are configured by block link points; and

receiving at least one initiated transaction from a user terminal; and

21. The system of claim 16, wherein the operations further comprise:

22. The system of claim 16, wherein the operations further comprise:

23. The system of claim 16, wherein the operations further comprise:

24. The system of claim 16, wherein the operations further comprise:

25. The system of claim 24, wherein the operations further comprise:

26. The system of claim 25, wherein the operations further comprise:

27. The system of claim 16, wherein prior to obtaining the at least one candidate transaction, the operations further comprise:

28. The system of claim 16, wherein,

29. The system of claim 16, wherein,

The verification range is included in an originating block of the block chain.

30. The system of claim 16, wherein:

31. A non-transitory computer-readable storage medium configured with instructions executable by one or more processors to cause the one or more processors to perform operations comprising:

verifying whether the timestamp is within a verification range and whether an identification of the candidate transaction is present in an identification database; and

32. The storage medium of claim 31,

33. The storage medium of claim 31,

34. The storage medium of claim 31,

35. The storage medium of claim 31,

the time stamps are configured by block link points; and

obtaining the at least one candidate transaction for addition to the blockchain comprises:

receiving at least one initiated transaction from a user terminal; and

36. The storage medium of claim 31, wherein the operations further comprise:

37. The storage medium of claim 31, wherein the operations further comprise:

38. The storage medium of claim 31, wherein the operations further comprise:

39. The storage medium of claim 31, wherein the operations further comprise:

40. The storage medium of claim 39, wherein the operations further comprise:

41. The storage medium of claim 40, wherein the operations further comprise:

42. The storage medium of claim 31, wherein prior to obtaining the at least one candidate transaction, the operations further comprise:

43. The storage medium of claim 31,

44. The storage medium of claim 31,

The verification range is included in an originating block of the block chain.

45. The storage medium of claim 31,