CN113807963A - Replay attack prevention method for alliance chain transaction under account system - Google Patents
Replay attack prevention method for alliance chain transaction under account systemDownload PDFInfo
- Publication number
- CN113807963A CN113807963ACN202111086264.XACN202111086264ACN113807963ACN 113807963 ACN113807963 ACN 113807963ACN 202111086264 ACN202111086264 ACN 202111086264ACN 113807963 ACN113807963 ACN 113807963A
- Authority
- CN
- China
- Prior art keywords
- transaction
- time
- block
- transaction request
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Technical Field
The application relates to the technical field of block chains, in particular to a replay attack prevention method for alliance chain transaction under an account system.
Background
The blockchain is used as a distributed public accounting system, and the ability of preventing replay attack is an important guarantee for the accounting correctness of the system. In current blockchain products, including public chains and alliance chains, measures against replay attacks are taken to protect against replay attacks of transactions. Replay attacks on transactions are a serious problem, the most intuitive consequence being repeated payments in their accounts by the payer of a transfer transaction without consent. For blockchain products with other operation types besides transfer transaction, such as an etherhouse, if a code in a contract account of the blockchain product is repeatedly called, an exception of a system state will be caused, and for a Hyperridge fabric (open source blockchain distributed account book), a verification entity may be caused to repeatedly perform a wakeup operation coded on a chain, so that the computing resource of the verification entity is consumed, and the data throughput of the system is affected.
In order to implement the function of preventing the replay attack, in the prior art, various solutions are provided, for example, hash values of historical transactions are recorded as a solution, in which the hash value of each transaction is recorded in the system when the system executes the transaction, a hash record of all the historical transactions which have already been executed is maintained at the verification node, when a new transaction is received by a node in a block, the transaction is sent to the verification node for verification, the verification node compares the transaction with the locally stored hash record of the historical transactions, and the verification result is sent back to the node. The idea of the solution is intuitive and easy to understand and implement. However, as the transaction scale increases, the local storage space will increase sharply, and a lot of time is required in the query process, which significantly affects the data throughput of the network, and thus, the method is not suitable for large-scale scenarios and scenarios with high transaction processing throughput.
For another example, by designing the system to be a system naturally having a capability of preventing replay attack, as a solution to prevent replay attack, for example, in a virtual currency transaction process based on an account system model of UTXO, since an input of each transaction is linked to an unspent output (UTXO) of the previous transaction, the system naturally has a capability of preventing replay attack. However, the natural anti-replay capability of such virtual currency transactions relies on the issuance of currency and the transfer of ownership of the currency based thereon, and as the transaction progresses, the UTXOs also form a chain structure so that traceability can be made to see the source of each UTXO. Obviously this approach is not suitable for promotion into a common alliance chain product. Another objective problem is that if a UTXO is verified to be valid by tracing, it will take a lot of time if the UTXO chain is long, and the current solution is to maintain an available UTXO pool locally during the node synchronization process, and when verifying whether the input of a transaction is valid, it can directly perform an inquiry in the UTXO pool, which is a time-to-space method and consumes a lot of local storage resources.
For another example, by constructing a strict transaction sequence as a solution to prevent replay attack, for example, an ethernet adds a variable AccountNonce (account random number) to each transaction, and has a Nonce variable at the client for recording all transactions that have been sent by the account currently, when a transaction is verified to be valid, the transaction is processed by comparing the AccountNonce of the transaction with the Nonce of the client, and then the Nonce of the client is incremented by 1, and when a transaction is repeatedly sent, the transaction is determined to be invalid. In this way, the ether house realizes the capability of preventing replay attack. This solution, by constructing a strict transaction sequence under the account and setting a counter-like component at the client to process the transactions under the account serially, results in that the transactions must be executed strictly in sequence and the fault tolerance is low, if there is a transaction execution failure in the middle, the Nonce of the client will not increase any more, resulting in that all the transactions after the transaction cannot be received by the system because the AccountNonce is greater than the client Nonce.
Disclosure of Invention
In order to improve the replay attack prevention capability of a distributed public accounting system, the application provides a replay attack prevention method for alliance chain transaction under an account system.
The application provides a method for preventing replay attack of alliance chain transaction under an account system, which comprises the following steps:
acquiring a transaction request sent by a client;
acquiring the client time of the transaction request, and if the client time is earlier than a first reference time point T1, rejecting the transaction request;
judging whether the client time is earlier than or equal to a second reference time point T2, and if the client time is earlier than or equal to a second reference time point T2, comparing the transaction corresponding to the transaction request with all transactions in a transaction cache pool P;
if the transaction corresponding to the transaction request exists in the transaction cache pool P, rejecting the transaction request; and if the transaction corresponding to the transaction request does not exist in the transaction cache pool P, packaging the transaction corresponding to the transaction request into the current block, and caching the transaction corresponding to the transaction request into the transaction cache pool P.
Optionally, after the step of obtaining the client time of the transaction request, the method further includes:
if the time of the client is later than or equal to a first reference time point T1, judging that the transaction signature corresponding to the transaction request is correct, and if the transaction signature corresponding to the transaction request is correct, putting the transaction corresponding to the transaction request into a transaction pool; and if the transaction signature corresponding to the transaction request is incorrect, rejecting the transaction request.
Optionally, the step of determining whether the client time is earlier than or equal to a second reference time point T2 further includes:
if the client time is later than a second reference time point T2, continuously keeping the transaction request corresponding to the client time in a transaction pool;
and when the client time is earlier than or equal to the updated second reference time point T2, judging whether the client time is later than or equal to the updated first reference time point T1, and if the client time is later than or equal to the updated first reference time point T1, comparing the transaction corresponding to the corresponding transaction request with all transactions in the transaction cache pool P.
Optionally, n blocks are taken forward by the height m of the current block, and the construction time of the m-n blocks is selected as the first reference time point T1.
Optionally, the method for preventing replay attack of federation chain transaction under an account system further includes:
and acquiring block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests with the block packing time being earlier than or equal to a first reference time point T1 from the transaction cache pool P.
Optionally, the step of packaging the transaction request into the current block further includes:
acquiring the packing time of a previous block, and if the packing time of the previous block is less than or equal to the local time of a packing node of the current block, setting the packing time of the current block as the local time of the packing node of the current block;
and if the packing time of the previous block is greater than the local time of the packing node of the current block, calculating the average block-out time delta K of K blocks before the current block, and delaying the average block-out time delta K in the packing time of the previous block to be used as the packing time of the current block.
Optionally, the step of calculating the average block-out time Δ K of K blocks before the current block specifically includes:
acquiring K block outlet time corresponding to K blocks before the current block, and judging whether the block outlet interval time between any two continuous blocks in the K blocks is greater than the default block outlet interval time;
and if the interval time between two continuous blocks is greater than the default block time interval, replacing the interval time between two continuous blocks by the default block time interval, and calculating the average block output time delta K of the K blocks by the replaced block output interval time.
Optionally, the method includes:
the clock between each node is regularly calibrated, and the clock synchronization between each node is kept;
after the step of packaging the transaction request into a current block, further comprising:
and after receiving the current block generated by the current block packaging node, the replica node compares the construction time of the current block with the local time of the replica node, and if the interval between the construction time of the current block and the local time of the replica node is greater than a first preset threshold, the replica node does not vote for the current block.
Optionally, the method for preventing replay attack of federation chain transaction under an account system further includes:
after the node is down, acquiring a currently confirmed block of the node, searching n blocks from the currently confirmed block forward, and caching transaction requests corresponding to the n blocks into a transaction cache pool P.
Optionally, after the step of obtaining the client time of the transaction request, the method further includes:
and comparing the client time of the transaction request with the local time of the node, and if the interval between the client time of the transaction request and the local time of the node is greater than a second preset time, rejecting the transaction request.
Optionally, in the step of packaging the transaction request into a block, the building time of the block is strictly increased.
According to the technical scheme, the replay attack defense method for the alliance chain transaction under the account system comprises the following steps: acquiring a transaction request sent by a client; acquiring the client time of the transaction request, and if the client time is earlier than a first reference time point T1, rejecting the transaction request; judging whether the client time is earlier than or equal to a second reference time point T2, and if the client time is earlier than or equal to a second reference time point T2, comparing the transaction corresponding to the transaction request with all transactions in a transaction cache pool P; if the transaction corresponding to the transaction request exists in the transaction cache pool P, rejecting the transaction request; and if the transaction corresponding to the transaction request does not exist in the transaction cache pool P, packaging the transaction corresponding to the transaction request into the current block, and caching the transaction corresponding to the transaction request into the transaction cache pool P.
In the practical application process, by designing the sliding time window, only all packaged transactions after the first reference time point T1 need to be recorded, and in the case of a relatively short time window, the transaction records may be cached in the memory, and in the case of a relatively long time window, the transaction records may be considered to be stored in the database. Due to the fact that the stored transaction scale is small, the partial transactions can be placed in the cache under the condition that the time window is not particularly long, the transaction judging speed is extremely high, and the Tps of the system cannot be influenced. And the packaging execution of the transaction is not strictly limited in sequence, and the failure of one transaction does not influence the normal packaging execution of other transactions. And the size of the time window can be dynamically adjusted according to the Tps size of the system, so that various scenes are met. Because only n blocks ahead of the current block need to be cached into the transaction cache pool, the recovery of the transaction cache pool under abnormal conditions such as node downtime is very simple, and the performance of the alliance chain system cannot be influenced.
Drawings
Fig. 1 is a schematic overall flow chart of a replay attack prevention method for federation chain transaction under an account system according to an embodiment of the present application;
fig. 2 is a schematic diagram illustrating a determination principle of the first reference time point T1 according to an embodiment of the present application;
fig. 3 is a schematic diagram illustrating an obtaining principle of the average block-out time Δ K of K blocks before the current block according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present application without making any creative effort, belong to the protection scope of the present application:
fig. 1 is a schematic overall flow chart of a replay attack prevention method for federation chain transaction under an account system according to an embodiment of the present application. The replay attack prevention method for the alliance chain transaction under the account system comprises the steps S101 to S104.
Step S101: and acquiring a transaction request sent by a client.
Step S102: and acquiring the client time of the transaction request, and rejecting the transaction request if the client time is earlier than a first reference time point T1.
Step S103: judging whether the client time is earlier than or equal to a second reference time point T2, and if the client time is earlier than or equal to a second reference time point T2, comparing the transaction corresponding to the transaction request with all transactions in a transaction cache pool P; .
Specifically, the first reference time point T1 is obtained by taking n blocks from the height m of the current block, and selecting the construction time of the m-n block as the first reference time point T1, wherein the second reference time point T2 is the current time point of the node, i.e., the height m of the current block. In the prior art, for whether a transaction is legal in time uplink, a network clock of each node is generally referred to, but in an actual application process, due to reasons such as network delay, if the network clock of each node is selected to calculate the reference time, a time interval instead of an accurate time point is selected as the reference time, so that a transaction request, for example, a transaction request is a transaction of a transaction client time in the time interval corresponding to the reference time, but due to the fact that the network clocks of the nodes are not consistent, the judgment of the same transaction request and different nodes is not consistent.
Referring to fig. 2, a schematic diagram of a determination principle of the first reference time point T1 provided for the embodiment of the present application, for normally identified nodes, each node locally has the same one blockchain copy, and the building time of a block that has landed is determined. Therefore, with the tile height as the reference standard, taking n tiles forward from the height m of the current tile, and selecting the time of the tile construction as the first reference time point T1, it is necessary to buffer the transactions in n-1 tiles forward from the current tile in the transaction buffer pool P. Along with the consensus, the height m of the block to be packed can be continuously increased, and every time m is increased by 1, a new time interval is corresponded.
If the time of the client is later than or equal to a first reference time point T1, judging that the transaction signature corresponding to the transaction request is correct, and if the transaction signature corresponding to the transaction request is correct, putting the transaction corresponding to the transaction request into a transaction pool; and if the transaction signature corresponding to the transaction request is incorrect, rejecting the transaction request.
And the transaction node acquires the transaction request from the transaction pool, judges whether the client time of the transaction request is earlier than or equal to a second reference time point T2 or not, and compares the transaction corresponding to the transaction request with all transactions in the transaction cache pool P if the client time is earlier than or equal to the second reference time point T2.
And if the client time is later than a second reference time point T2, continuously keeping the transaction request corresponding to the client time in a transaction pool.
The method comprises the steps that blocks are continuously generated along with the time, when the high end m of the current block changes once, the corresponding first reference time point T1 and the second reference time point T2 are updated, when the time of a client is earlier than or equal to the updated second reference time point T2, whether the time of the client is later than or equal to the updated first reference time point T1 is judged, if the time of the client is later than or equal to the updated first reference time point T1, transactions corresponding to corresponding transaction requests are compared with all transactions in a transaction cache pool P, and if the transactions corresponding to the transaction requests exist in the transaction cache pool P, the transactions corresponding to the transaction requests need to be removed from the transaction cache pool. It should be noted that the system does not create a new block, the first reference time point T1 is updated once, and correspondingly, the transaction requests smaller than the first reference time point T1 are removed from the transaction pool.
Step S104: if the transaction corresponding to the transaction request exists in the transaction cache pool P, rejecting the transaction request; and if the transaction corresponding to the transaction request does not exist in the transaction cache pool P, packaging the transaction request into the current block, and caching the transaction corresponding to the transaction request into the transaction cache pool P.
In the model corresponding to the method for preventing a replay attack of a transaction provided in the embodiment of the present application, a transaction cache pool P needs to be established for each channel, and the client time of the transaction cache pool P for caching the transaction is at the first reference time point T1, and the transaction is successfully packaged. The first reference time point T1 is used to determine whether a transaction is within the valid receiving time, and all transactions with transaction client time earlier than T1 are determined to be expired transactions.
The specific process is as follows: when the packaging block of the current block needs to package a transaction, firstly, whether the client time of the transaction request is within the valid time is judged, if the client time CT of the transaction request is earlier than T1, the transaction corresponding to the transaction request is considered to exceed the packaging valid time, and the packaging of the transaction is refused. If the client time of the transaction request is within the valid time, that is, CT is later than T1, it is determined whether the transaction corresponding to the transaction request exists in the transaction cache pool P, if so, it indicates that the transaction request has been repeatedly executed after referring to the time point T, packaging of the transaction corresponding to the transaction request is rejected, and if not, packaging of the transaction corresponding to the transaction request into the block is successful.
Further, in this embodiment of the present application, since the height m of the to-be-packaged chunk is continuously increased as the consensus proceeds, and m is increased by 1 every time, so that the first reference time point T1 varies with the height of the to-be-packaged chunk (the current chunk), in order to ensure that the transaction cached in the transaction cache pool P is always within the validity period, in this embodiment of the present application, the method for preventing replay attack on federation chain transaction under the account system further includes: and acquiring block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests with the block packing time being earlier than or equal to a first reference time point T1 from the transaction cache pool P.
Specifically, as the block height increases, each block increase means that the oldest (the block with the smallest height in the cache) block is invalidated, so that the transaction corresponding to the invalidated block is deleted from the transaction cache pool.
In the embodiment of the present application, the transactions cached in the transaction cache pool P should be all transactions executed after the first reference time point T1, that is, all transactions requested after the first reference time point T1 should not be packed in m-n blocks and the previous blocks, that is, it is required to ensure that the first reference time point T1 for establishing the transaction cache pool P can strictly divide the time zone, and the first reference time point T1 at different stages is strictly increased in time, so as to avoid that the first reference time point T1 at the next time is earlier than the first reference time point T1 at the previous time, and thus two conditions are required to be satisfied, where: the building time of a block is strictly increasing; and a second condition: the client time of the transaction request for all transactions packed within a block must be less than the build time for that block.
In this embodiment of the present application, in order to meet the first condition, it is required that the block-out time of each consensus node must be strictly increased, and in an actual application process, when a system has multiple node consensus, because clocks of the nodes are not completely synchronized, if a time interval for node block-out is small, the block-out time may not be strictly increased, and in order to ensure that the block-out time of a node is strictly increased under the condition that multiple node consensus exists, in this embodiment of the present application, the step of packaging the transaction request into the current block further includes steps S201 to S202.
Step S201, obtaining the packing time of the previous block, and if the packing time of the previous block is less than or equal to the local time of the current block packing node, setting the packing time of the current block as the local time of the current block packing node.
Step S202, if the packing time of the previous block is greater than the local time of the current block packing node, calculating an average block-out time Δ K of K blocks before the current block, and delaying the average block-out time Δ K in the packing time of the previous block as the packing time of the current block.
Referring to fig. 3, a schematic diagram of an obtaining principle of the average block output time Δ K of K blocks before the current block provided by the embodiment of the present application is shown, where the average block output time Δ K of K blocks before the current block is obtained by steps S301 to S302.
Step S301, obtaining K block output times corresponding to K blocks before the current block, and determining whether a block output interval time between any two consecutive blocks in the K blocks is greater than an default block output interval time.
Step S302, if the interval time between two consecutive blocks is greater than the default block time interval, replacing the interval time between two consecutive blocks with the default block time interval, and calculating the average block output time Δ K of the K blocks with the replaced block output interval time.
It should be noted that once a block is written into a block, the block construction time belongs to an attribute that cannot be modified in the block, and here, replacing the interval time between two consecutive blocks with a default block time interval does not mean modifying the time of the original block, but only using the default block time interval to calculate the average block time.
Specifically, in order to ensure that the block construction time of the previous block of the current block is not particularly off-spectrum, that is, the error between the local clock of the leader packing node and the clock of other nodes cannot be too large, the following two measures may be taken:
the first measure is as follows: the clock between each node is regularly calibrated, the clock synchronization between each node is maintained, specifically, when the operation and maintenance level redeploys the system, a tool is used for maintaining the clock synchronization between the nodes, the current physical clock synchronization can be accurate to the second level, and therefore, in the practical application process, the second level synchronization can completely meet the design requirement.
And step two: after the step of packaging the transaction request into a current block, further comprising:
after receiving the current block generated by the current block packaging node, the replica node compares the construction time of the current block with the local time of the replica node, and if the interval between the construction time of the current block and the local time of the replica node is greater than a first preset threshold, the replica node does not vote for the current block
Specifically, the size of the first preset threshold may be set according to actual design requirements, in this embodiment of the present application, the first preset threshold is taken for 2 minutes, if the interval between the building time of the current block and the local time of the replica node exceeds the first preset threshold, the block is not voted for, because the node at this time is likely to be a byzantine node, and through the set first preset threshold, the byzantine attack of the malicious node is effectively performed.
For the transaction meeting the first preset threshold, the leader node takes an effective transaction- > leader node from the transaction pool to construct a block, the block construction time- > leader node is set to send the block to the replica node- > the replica node to vote- > the next leader node collects the vote, if the vote exceeds 2/3, the block is identified, the block identification time- > block persistence is set, and the block persistence time is set.
Specifically, in the embodiment of the present application, in order to reduce the error of the average block-out time Δ K of the first K blocks of the current block, it is considered that the node is not transactedThere are no blocks, and if a transaction is sent in two of the K blocks with a long time between them, then the value of ak will be large, and if there are multiple such cases, a larger error will result. As shown in fig. 3, if the block-out time (t) of a certain block is calculatedk-1) And the block-out time (t) of the last blockk-2) Inter block-out time (t) in betweenk-2-tk-1) If the default block output time interval is greater than the default block output time interval, the default block output time interval is used as the block output time interval between the block and the previous block, and it should be noted that, in this embodiment of the present application, the default block output time interval is set to 2 seconds.
For the second condition, because the Leader node needs to perform a judgment when packaging the transaction, only the transaction of which the client time is earlier than the current time can be successfully packaged, and the building time of the block is certainly later than the packaging time, thereby ensuring that the second condition is met.
In the embodiment of the present application, the method for preventing replay attack of federation chain transaction under an account system further includes: and after the node is down, acquiring the current confirmed block of the node, searching n blocks from the current confirmed block forward, and performing the operation. The transaction requests corresponding to the n blocks are cached in the transaction cache pool P, and for the solution of recording all historical transactions, data loss caused by node downtime or physical damage can cause the data to be unusable, and it takes a very long time to reestablish all transaction records. According to the scheme, when the node is down or the data cache data is lost due to physical damage of the hard disk, the transaction cache pool P can be recovered quickly.
In order to prevent the client from tampering the time at will, in the embodiment of the present application. After the step of obtaining the client time of the transaction request, the method further includes: and comparing the client time of the transaction request with the local time of the node, and if the interval between the client time of the transaction request and the local time of the node is greater than a second preset time, rejecting the transaction request. Specifically, in the embodiment of the present application, the second preset time is set to 10 minutes, for example, the local time of the node is 15:00, and the client time of the transaction request that can be received is 14:50 to 15: 10.
According to the replay attack prevention method for the alliance chain transaction under the account system, when a node receives a new transaction request, if the client time of the transaction request is earlier than the first reference time point T1, the fact that the transaction corresponding to the transaction request is packaged in blocks before the first reference time point T1 is shown, but the transaction of the blocks is determined, so that the transaction request is considered to exceed the packaging validity period of the transaction, and the transaction request is rejected. If the client time of the transaction request is later than the first reference time point T1 and the client time of the transaction request is earlier than or equal to the second reference time point T2, the transaction cache pool P is queried for the presence of the transaction, and if the transaction is present, the transaction is declared and packaged, and the transaction request is discarded. If the transaction request does not exist, the transaction corresponding to the transaction request is a valid transaction, the packaging is performed in the latest block, and all transaction requests before the first reference time point T1 by the transaction client time are rejected, because the transaction before the first reference time point T1 is not cached, it cannot be determined whether the transaction has been packaged before the first reference time point T1. Through actual tests in a Newstand new generation alliance chain, under the condition that the block output interval is 2s, the transaction request number cached in the transaction cache pool P is 150, all transactions can be guaranteed to be normally packaged, and the condition that the transactions are rejected because the transaction exceeds the validity period hardly occurs. Certainly, with the advancement of the blockchain technology, the Tps (system throughput) of the federation chain will reach the level of one hundred thousand or even millions in the future, and at this time, the technical solution is still applicable as long as the cache height of the block is increased, for the increase of Tps, the parameter n may be adjusted to perform dynamic adaptation, and other methods have no adjustment capability.
According to the replay attack prevention method for the alliance chain transaction under the account system, through the design of the sliding time window, all packaged transactions only need to be recorded after the first reference time point T1, the transaction records can be cached in the memory under the condition that the time window is short, and the transaction records can be considered to be stored in the database under the condition that the time window is long. Due to the fact that the stored transaction scale is small, the partial transactions can be placed in the cache under the condition that the time window is not particularly long, the transaction judging speed is extremely high, and the Tps of the system cannot be influenced. And the packaging execution of the transaction is not strictly limited in sequence, and the failure of one transaction does not influence the normal packaging execution of other transactions. And the size of the time window can be dynamically adjusted according to the Tps size of the system, so that various scenes are met. As only n blocks from the current block to the transaction cache pool need to be cached, the recovery of the transaction cache pool under abnormal conditions such as node downtime is very simple, and the performance of the alliance chain system cannot be influenced.
Claims (11)
1. A replay attack prevention method for alliance chain transaction under an account system is characterized by comprising the following steps:
acquiring a transaction request sent by a client;
acquiring the client time of the transaction request, and if the client time is earlier than a first reference time point T1, rejecting the transaction request;
judging whether the client time is earlier than or equal to a second reference time point T2, and if the client time is earlier than or equal to a second reference time point T2, comparing the transaction corresponding to the transaction request with all transactions in a transaction cache pool P;
if the transaction corresponding to the transaction request exists in the transaction cache pool P, rejecting the transaction request; and if the transaction corresponding to the transaction request does not exist in the transaction cache pool P, packaging the transaction corresponding to the transaction request into the current block, and caching the transaction corresponding to the transaction request into the transaction cache pool P.
2. The method for preventing replay attack of alliance chain transaction under an account system according to claim 1, wherein: after the step of obtaining the client time of the transaction request, the method further comprises:
if the time of the client is later than or equal to a first reference time point T1, judging that the transaction signature corresponding to the transaction request is correct, and if the transaction signature corresponding to the transaction request is correct, putting the transaction corresponding to the transaction request into a transaction pool; and if the transaction signature corresponding to the transaction request is incorrect, rejecting the transaction request.
3. The method for preventing replay attack of alliance chain transaction under an account system according to claim 2, wherein: the step of determining whether the client time is earlier than or equal to a second reference time point T2 further includes:
if the client time is later than a second reference time point T2, continuously keeping the transaction request corresponding to the client time in a transaction pool;
and when the client time is earlier than or equal to the updated second reference time point T2, judging whether the client time is later than or equal to the updated first reference time point T1, and if the client time is later than or equal to the updated first reference time point T1, comparing the transaction corresponding to the corresponding transaction request with all transactions in the transaction cache pool P.
4. The method for preventing replay attack of alliance chain transaction under an account system according to claim 1, wherein:
the n blocks are taken forward by the height m of the current block, and the construction time of the m-n blocks is selected as the first reference time point T1.
5. The method for preventing replay attack on a federation chain transaction under an account system according to claim 1, wherein the method for preventing replay attack on a federation chain transaction under an account system further comprises:
and acquiring block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests of which the block packing time is earlier than a first reference time point T1 from the transaction cache pool P.
6. The method for preventing replay attack of a federation chain transaction under an account hierarchy of claim 1, wherein the step of packaging the transaction request into a current block further comprises:
acquiring the packing time of a previous block, and if the packing time of the previous block is less than or equal to the local time of a packing node of the current block, setting the packing time of the current block as the local time of the packing node of the current block;
and if the packing time of the previous block is greater than the local time of the packing node of the current block, calculating the average block-out time delta K of K blocks before the current block, and delaying the average block-out time delta K in the packing time of the previous block to be used as the packing time of the current block.
7. The method as claimed in claim 6, wherein the step of calculating the average block-out time Δ K of K blocks before the current block includes:
acquiring K block outlet time corresponding to K blocks before the current block, and judging whether the block outlet interval time between any two continuous blocks in the K blocks is greater than the default block outlet interval time;
and if the interval time between two continuous blocks is greater than the default block-out time interval, replacing the interval time between two continuous blocks by the default block-out time interval, and calculating the average block-out time delta K of the K blocks by the replaced block-out interval time.
8. The method for preventing replay attack of alliance chain transaction under an account system according to claim 1, characterized by comprising:
the clock between each node is regularly calibrated, and the clock synchronization between each node is kept;
after the step of packaging the transaction request into a current block, further comprising:
and after receiving the current block generated by the current block packaging node, the replica node compares the construction time of the current block with the local time of the replica node, and if the interval between the construction time of the current block and the local time of the replica node is greater than a first preset threshold, the replica node does not vote for the current block.
9. The method for preventing replay attack on a federation chain transaction under an account system according to claim 1, wherein the method for preventing replay attack on a federation chain transaction under an account system further comprises:
after the node is down, acquiring a currently confirmed block of the node, searching n blocks from the currently confirmed block forward, and caching transaction requests corresponding to the n blocks into a transaction cache pool P.
10. The method for preventing replay attack of a federation chain transaction under an account hierarchy of claim 1, wherein after the step of obtaining the client time of the transaction request, the method further comprises:
and comparing the client time of the transaction request with the local time of the node, and if the interval between the client time of the transaction request and the local time of the node is greater than a second preset time, rejecting the transaction request.
11. The method for preventing replay attack of a federation chain transaction under an account hierarchy of claim 1, wherein in the step of packaging the transaction request into a block, the building time of the block is strictly increased.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111086264.XACN113807963B (en) | 2021-09-16 | 2021-09-16 | Replay attack prevention method for alliance chain transaction under account system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111086264.XACN113807963B (en) | 2021-09-16 | 2021-09-16 | Replay attack prevention method for alliance chain transaction under account system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113807963Atrue CN113807963A (en) | 2021-12-17 |
| CN113807963B CN113807963B (en) | 2024-05-03 |
Family
ID=78941275
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111086264.XAActiveCN113807963B (en) | 2021-09-16 | 2021-09-16 | Replay attack prevention method for alliance chain transaction under account system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113807963B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030065919A1 (en)* | 2001-04-18 | 2003-04-03 | Albert Roy David | Method and system for identifying a replay attack by an access device to a computer system |
| US20100205662A1 (en)* | 2009-02-09 | 2010-08-12 | International Business Machines Corporation | System and method to support identity theft protection as part of a distributed service oriented ecosystem |
| CN108764870A (en)* | 2018-05-29 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Blockchain-based transaction processing method, device, and electronic equipment |
| CN111200589A (en)* | 2019-12-05 | 2020-05-26 | 北京数字认证股份有限公司 | Data protection method and system for alliance chain |
| US20200220899A1 (en)* | 2019-01-07 | 2020-07-09 | International Business Machines Corporation | Certifying authenticity via dynamic dimensional coordinate scanning and decentralized data storage |
| US10785035B1 (en)* | 2019-04-26 | 2020-09-22 | Alibaba Group Holding Limited | Anti-replay attack authentication protocol |
| CN112258188A (en)* | 2020-12-02 | 2021-01-22 | 支付宝(杭州)信息技术有限公司 | Processing method, device, equipment and system for block chain transaction |
- 2021
- 2021-09-16CNCN202111086264.XApatent/CN113807963B/enactiveActive
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030065919A1 (en)* | 2001-04-18 | 2003-04-03 | Albert Roy David | Method and system for identifying a replay attack by an access device to a computer system |
| US20100205662A1 (en)* | 2009-02-09 | 2010-08-12 | International Business Machines Corporation | System and method to support identity theft protection as part of a distributed service oriented ecosystem |
| CN108764870A (en)* | 2018-05-29 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Blockchain-based transaction processing method, device, and electronic equipment |
| CN111899006A (en)* | 2018-05-29 | 2020-11-06 | 创新先进技术有限公司 | Transaction processing method and device based on block chain and electronic equipment |
| US20200220899A1 (en)* | 2019-01-07 | 2020-07-09 | International Business Machines Corporation | Certifying authenticity via dynamic dimensional coordinate scanning and decentralized data storage |
| US10785035B1 (en)* | 2019-04-26 | 2020-09-22 | Alibaba Group Holding Limited | Anti-replay attack authentication protocol |
| CN111200589A (en)* | 2019-12-05 | 2020-05-26 | 北京数字认证股份有限公司 | Data protection method and system for alliance chain |
| CN112258188A (en)* | 2020-12-02 | 2021-01-22 | 支付宝(杭州)信息技术有限公司 | Processing method, device, equipment and system for block chain transaction |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113807963B (en) | 2024-05-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111045855B (en) | Method, apparatus and computer program product for backing up data | |
| US10681083B2 (en) | System and method for detecting replay attack | |
| US7926103B2 (en) | System and method for preventing replay attacks | |
| KR20200083930A (en) | System and method for detecting replay attack | |
| Dobre et al. | PoWerStore: Proofs of writing for efficient and robust storage | |
| US11151276B1 (en) | Systems and methods for data certificate notarization utilizing bridging from private blockchain to public blockchain | |
| Du et al. | Partitionchain: A scalable and reliable data storage strategy for permissioned blockchain | |
| KR20200083931A (en) | System and method for detecting replay attack | |
| CN114372296A (en) | A blockchain-based user behavior data audit method and system | |
| CN110297831A (en) | A kind of block chain fragment storage method based on threshold secret sharing | |
| CN112184436B (en) | Data synchronization method, electronic device and readable storage medium | |
| CN112835743A (en) | Distributed account book data storage optimization method and device, electronic equipment and medium | |
| CN104778123B (en) | A kind of method and device of detecting system performance | |
| RU2697953C2 (en) | System and method of deciding on data compromising | |
| CN117421157A (en) | Data backup storage method and system based on block chain | |
| WO2020172881A1 (en) | Block generation method and apparatus, computer device and storage medium | |
| CN112948847B (en) | Block chain-based data sharing system and data correctness verification method | |
| CN115865378B (en) | Streaming media real-time certification and verification method based on blockchain | |
| CN113872792B (en) | System, method and computer-readable medium for deduplicating log messages based on adaptive time windows | |
| CN113807963A (en) | Replay attack prevention method for alliance chain transaction under account system | |
| CN115033578A (en) | Method for updating service data, related device and storage medium | |
| US10051004B2 (en) | Evaluation system | |
| Yingchareonthawornchai et al. | Efficient algorithms for predicate detection using hybrid logical clocks | |
| EP2477137A1 (en) | Method for verifying the integrity of a set of data | |
| Dobre et al. | Proofs of writing for robust storage |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |