CN113807963B - Replay attack prevention method for alliance chain transaction under account system - Google Patents
Replay attack prevention method for alliance chain transaction under account system Download PDFInfo
- Publication number
- CN113807963B CN113807963B CN202111086264.XA CN202111086264A CN113807963B CN 113807963 B CN113807963 B CN 113807963B CN 202111086264 A CN202111086264 A CN 202111086264A CN 113807963 B CN113807963 B CN 113807963B
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 230000002265 prevention Effects 0.000 title claims abstract description 20
- 238000004806 packaging method and process Methods 0.000 claims abstract description 20
- 238000012856 packing Methods 0.000 claims description 39
- 238000010276 construction Methods 0.000 claims description 14
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 230000000903 blocking effect Effects 0.000 claims 8
- 238000013461 design Methods 0.000 abstract description 5
- 230000002159 abnormal effect Effects 0.000 abstract description 4
- 238000010586 diagram Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 238000007599 discharging Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000003139 buffering effect Effects 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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
The application relates to the technical field of blockchains, and provides a replay attack prevention method of alliance chain transaction under an account system, which comprises the steps of obtaining a transaction request sent by a client; acquiring the client time of a transaction request, and rejecting the transaction request if the client time is earlier than a first reference time point T1; when the client time is later than a first reference time point T1 and is earlier than or equal to a second reference time point T2, rejecting the transaction request if the transaction corresponding to the transaction request exists in the transaction cache pool P; and if the transaction corresponding to the transaction request does not exist in the transaction caching 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 caching pool P. Through the design of the sliding time window, the weight judging speed of the transaction is extremely high, various scenes can be met, the transaction caching pool can be quickly recovered for abnormal conditions such as node downtime, and the performance of the alliance chain system cannot be affected.
Description
Technical Field
The application relates to the technical field of blockchains, in particular to a replay attack prevention method for alliance chain transaction under an account system.
Background
Blockchain is used as a distributed public accounting system, and the capability of preventing replay attack is an important guarantee of the accounting correctness of the system. In current blockchain products, including both public and federation chains, some measure against replay attacks is taken to guard against replay attacks of transactions. Replay attacks of transactions are a serious problem, the most intuitive outcome being that they cause the payer of the transfer transaction to repeatedly pay out the balance in his account without consent. For blockchain products with other operation types than transfer transaction, such as ethernet, if the codes in the contract account are called repeatedly, the abnormal state of the system will be caused, and for HYPERLEDGER FABRIC (open source blockchain distributed account book), the verification entity may be caused to repeatedly perform the wake-up operation of the on-chain code, consume the computing resource thereof, and affect the data throughput of the system.
In order to implement the replay attack prevention function, in the prior art, various solutions are provided, for example, a hash value of a historical transaction is recorded as a solution, in which, every time a system executes a transaction, the hash value of the transaction is recorded in the system, by maintaining all the historical transaction hash records already executed at a verification node, when a node in a block receives a new transaction, the transaction is sent to the verification node for verification, the verification node compares the transaction with the locally stored historical transaction hash records, and sends a verification result back to the node. The solution is intuitive in concept and easy to understand and implement. However, as the transaction scale increases, the occupied local storage space increases sharply, and a great deal of time is required in the process of inquiry, so that the data throughput of the network is obviously affected, and the method is not suitable for large-scale scenes with high transaction processing throughput.
As another example, by designing the system as a system that naturally has replay attack prevention capability, as a solution to replay attack prevention, such as in a virtual currency transaction process based on a UTXO-based account system model, replay attack prevention capability is naturally provided because the input of each transaction is associated with the unexpired output (UTXO) of the last transaction. However, the natural anti-replay capability of the virtual currency transaction depends on the currency issuing right and the transfer of the currency ownership based on the virtual currency transaction, and the UTXO also forms a chained structure along with the transaction, so that the source of each UTXO can be traced to view. Obviously, this approach is not suitable for popularization into a generic federation chain product. And another objective problem is that if a UTXO is verified by tracing, a lot of time is consumed under the condition that the UTXO chain is long, and when the current solution is to locally maintain an available UTXO pool in the process of node synchronization, when verifying whether the input of a transaction is valid, the query can be directly made in the UTXO pool, which belongs to the method of changing time in space and consumes more local storage resources.
For another example, by constructing a strict transaction sequence, as a solution for preventing replay attacks, for example, ethernet adds a variable AccountNonce (account random number) to each transaction, and has a Nonce variable at the client for recording all transactions that the account has sent so far, when a transaction is verified as valid, by comparing AccountNonce of the transaction with the Nonce of the client, if so, the transaction is processed, then the Nonce of the client increases by 1, and when a duplicate transaction comes, it is determined as invalid. In this way the ethernet gateway achieves replay attack resistance. This solution, by building a strict sequence of transactions under the account and setting a counter-like component at the client to serially process the transactions under the account, results in the transactions having to be executed strictly in sequence and with low fault tolerance, if there is a failure to execute a transaction in between, the Nonce of the client will not increase any more, resulting in all transactions after the transaction being not received by the system because AccountNonce are larger than the Nonce of the client.
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 transactions under an account system.
The application provides a replay attack prevention method for 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 rejecting the transaction request if the client time is earlier than a first reference time point T1;
Judging whether the time of the client is earlier than or equal to a second reference time point T2, and if the time of the client is earlier than or equal to the 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 caching pool P, packaging the transaction corresponding to the transaction request into a current block, and caching the transaction corresponding to the transaction request into the transaction caching pool P.
Optionally, after the step of obtaining the client time of the transaction request, the method further includes:
If the client time 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 rejecting the transaction request if the transaction signature corresponding to the transaction request is incorrect.
Optionally, in the step of determining whether the client time is earlier than or equal to the second reference time point T2, the method further includes:
if the client time is later than the second reference time point T2, the transaction request corresponding to the client time is continuously reserved 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 all the transactions corresponding to the corresponding transaction request with all the transactions in the transaction cache pool P.
Optionally, n blocks are taken forward with 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 alliance chain transaction under account system further comprises:
And obtaining block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests with the block packing time earlier than or equal to the 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 smaller than or equal to the local time of a current block packing node, setting the packing time of the current block as the local time of the current block packing node;
if the packing time of the last block is greater than the local time of the current block packing node, calculating the average block outlet time delta K of the previous K blocks of the current block, and delaying the average block outlet time delta K on the packing time of the last block to serve as the packing time of the current block.
Optionally, the step of calculating the average block out time Δk of the K previous blocks of the current block specifically includes:
obtaining K block discharging times corresponding to K blocks before a current block, and judging whether the block discharging interval time between any two continuous blocks in the K blocks is larger than a default block discharging interval;
If the interval time between a certain two continuous blocks is larger than the default block outlet time interval, replacing the interval time between the certain two continuous blocks with the default block outlet time interval, and calculating the average block outlet time delta K of the K blocks with the replaced block outlet interval time.
Optionally, the method comprises the following steps:
regularly calibrating clocks among nodes, and keeping the clocks among the nodes synchronous;
After the step of packaging the transaction request into the current block, the method further comprises:
after receiving the current block generated by the current block packaging node, the copy node compares the construction time of the current block with the local time of the copy node, and if the interval between the construction time of the current block and the local time of the copy node is greater than a first preset threshold, the copy node does not vote on the current block.
Optionally, the method for preventing replay attack of alliance chain transaction under account system further comprises:
after the node is down, the current confirmed block of the node is obtained, n blocks are searched forward from the current confirmed block, and transaction requests corresponding to the n blocks are cached to the transaction cache pool P.
Optionally, after the step of obtaining the client time of the transaction request, the method further includes:
Comparing the client time of the transaction request with the node local time, and rejecting the transaction request if the interval between the client time of the transaction request and the node local time is greater than a second preset time.
Optionally, in the step of packaging the transaction request into a block, the construction time of the block is strictly increased.
According to the technical scheme, the replay attack range prevention method for the alliance chain transaction under the account system provided by the embodiment of the application comprises the following steps: acquiring a transaction request sent by a client; 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; 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 the second reference time point T2, comparing all the transactions corresponding to the transaction request with all the transactions in the 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 caching pool P, packaging the transaction corresponding to the transaction request into a current block, and caching the transaction corresponding to the transaction request into the transaction caching pool P.
In the practical application process, through the design of the sliding time window, all packaged transactions after the first reference time point T1 only need to be recorded, under the condition that the time window is relatively short, the transaction records can be cached in the memory, and under the condition that the time window is relatively long, the transaction records can be considered to be stored in the database. Because the stored transaction scale is small, the part of the transaction can be put in the cache under the condition that the time window is not particularly long, so that the weight judging speed of the transaction is extremely high, and the Tps of the system are not influenced. And the packing execution of the transactions is not strictly limited in sequence, and the failure of one transaction does not influence the normal packing 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 satisfied. Because only n blocks forward from the current block need to be cached in the transaction cache pool, the recovery of the transaction cache pool for abnormal conditions such as node downtime is very simple, and the performance of the alliance chain system is not affected.
Drawings
FIG. 1 is a schematic overall flow diagram of a method for preventing replay attacks of alliance chain transactions under an account system according to an embodiment of the present application;
Fig. 2 is a schematic diagram illustrating a determination principle of a first reference time point T1 according to an embodiment of the present application;
Fig. 3 is a schematic diagram of an acquisition principle of an average block-out time Δk of K blocks before a current block according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all embodiments of the application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden on the person of ordinary skill in the art based on the embodiments herein, are within the scope of the present application:
Fig. 1 is a schematic overall flow diagram of a replay attack prevention method for a coalition chain transaction under an account system according to an embodiment of the present application. The embodiment of the application provides a replay attack prevention method for alliance chain transaction under an account system, which comprises the steps S101 to S104.
Step S101: and acquiring a transaction request sent by the 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 time of the client is earlier than or equal to a second reference time point T2, and if the time of the client is earlier than or equal to the 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 n blocks taken forward with the height m of the current block, and the construction time of the mth-n blocks is selected as the first reference time point T1, where 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, whether the transaction is legal in time or not generally refers to the network clock of each node, but in the actual application process, if the network clock of each node is selected to calculate the reference time due to network delay and other reasons, a time interval is selected for the reference time instead of an accurate time point, so that for a certain transaction request, for example, one transaction request is a transaction of the transaction client time in the time interval corresponding to the reference time, but the network clocks of the nodes are inconsistent, so that the judgment of the same transaction request and different nodes is inconsistent.
Referring to fig. 2, a schematic diagram of a determining principle of a first reference time point T1 provided in an embodiment of the present application is shown, where for nodes that are normally commonly known, each node locally has the same blockchain copy, and the construction time of a block that has fallen is determined. Therefore, taking the block height as a reference standard, taking n blocks forward by the height m of the current block, selecting the time of the block construction as a first reference time point T1, and buffering the transactions in n-1 blocks forward from the current block in the transaction buffer pool P. With the proceeding of consensus, the height m of the block to be packed is increased continuously, and each time m is increased by 1, a new time interval is corresponding.
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 rejecting the transaction request if the transaction signature corresponding to the transaction request is incorrect.
The transaction node acquires a transaction request from the transaction pool, judges whether the time of a client of the transaction request is earlier than or equal to a second reference time point T2, and compares the transaction corresponding to the transaction request with all transactions in the transaction cache pool P if the time of the client is earlier than or equal to the second reference time point T2.
And if the client time is later than the second reference time point T2, the transaction request corresponding to the client time is continuously reserved in the transaction pool.
And continuously generating a block along with the time, wherein the current block high end m is changed once, the corresponding first reference time point T1 and the second reference time point T2 are updated, 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, if the client time is later than or equal to the updated first reference time point T1, comparing the corresponding transaction of the corresponding transaction request with all the transactions in the transaction cache pool P, and if the transaction corresponding to the transaction request exists in the transaction cache pool P, eliminating the transaction corresponding to the transaction request from the transaction pool. It should be noted that, the system does not generate a new block, the first reference time T1 is updated once, and the transaction request smaller than the first reference time T1 is removed from the transaction pool correspondingly.
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 caching pool P, packaging the transaction request into a current block, and caching the transaction corresponding to the transaction request into the transaction caching pool P.
In the model corresponding to the transaction replay attack prevention method provided in the embodiment of the present application, a transaction buffer pool P needs to be established for each channel, where the time of a client used for buffering a transaction by the transaction buffer pool P is at a first reference time point T1, and the transaction is successfully packaged. The first reference time T1 is used to determine whether a transaction is within a valid receiving time, and all transactions having a transaction client time earlier than T1 are determined to be out-of-date transactions.
The specific flow is as follows: when the packing block of the current block needs to pack a transaction, firstly judging whether the client time of the transaction request is within the effective time, if the client time CT of the transaction request is earlier than T1, considering that the transaction corresponding to the transaction request exceeds the packed effective time, and refusing to pack the transaction. If the client time of the transaction request is within the effective time, that is, CT is later than T1, judging whether the transaction corresponding to the transaction request exists in the transaction cache pool P, if so, judging that the transaction request is repeatedly executed after the reference time point T, rejecting to package the transaction corresponding to the transaction request, and if not, successfully packaging the transaction corresponding to the transaction request into a block.
Further, in the embodiment of the present application, as the consensus is performed, the height m of the block to be packaged is continuously increased, and each time m is increased by 1, so that the first reference time point T1 is changed along with the height of the block to be packaged (the current block), in order to ensure that the transaction cached in the transaction cache pool P is always within the validity period, in the embodiment of the present application, the replay attack prevention method for the alliance chain transaction under the account system further includes: and obtaining block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests with the block packing time earlier than or equal to the first reference time point T1 from the transaction cache pool P.
Specifically, as the block height increases, each block increases meaning that the oldest (the block with the smallest height in the cache) block fails, so the transaction corresponding to the failed block is deleted from the transaction cache pool.
In the embodiment of the present application, the transactions buffered in the transaction buffer pool P should be all transactions executed after the first reference time point T1, i.e. the transactions of all the client time stamps of the transaction requests after the first reference time point T1 must not be packed in m-n blocks and the preceding blocks, i.e. it is required to ensure that the first reference time point T1 for establishing the transaction buffer pool P can strictly divide the time zone, the first reference time point T1 in different stages is strictly incremental in time, so that the first reference time point T1 of the subsequent time is avoided to be earlier than the first reference time point T1 of the previous time, and two conditions are required to be satisfied: the construction time of the block is strictly increasing; condition II: the client time of the transaction request for all transactions packaged within a block must be less than the build time of the block.
In the embodiment of the present application, in order to meet the first condition, the block-out time of each node of the consensus must be strictly increased, and in the actual application process, when the system has multiple node consensus, because the clocks of the nodes are not completely synchronized, if the time interval of the node block-out is small, the block-out time may not be strictly increased, and in order to ensure that the time of the node block-out is strictly increased in the case that there are multiple node consensus, in the 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.
In step S202, if the packing time of the previous block is greater than the local time of the current block packing node, the average block-out time Δk of the previous K blocks of the current block is calculated, and the average block-out time Δk is delayed on the packing time of the previous block and is used as the packing time of the current block.
Referring to fig. 3, a schematic diagram of obtaining an average block out time Δk of K blocks before a current block according to an embodiment of the present application is shown, where the average block out time Δk of K blocks before the current block is obtained by using steps S301 to S302.
Step S301, obtaining K block-out times corresponding to K blocks before the current block, and judging whether the block-out interval time between any two continuous blocks in the K blocks is larger than a default block-out interval.
In step S302, if the interval time between a certain two consecutive blocks is greater than the default block-out interval, the interval time between the certain two consecutive blocks is replaced with the default block-out interval, and the average block-out time Δk of the K blocks is calculated with the replaced block-out interval time.
It should be noted that, once the building time of a block is written into the block, the building time belongs to an attribute that cannot be modified in the block, and here, replacing the interval time between two consecutive blocks with the default block interval does not mean that the time of the original block is modified, but the average block time is calculated by using the default block interval.
Specifically, in order to ensure that the block construction time of the previous block of the current block is not particularly discrete, that is, the error between the local clock of the leader packaging node and the clocks of other nodes cannot be too large, the following two measures can be taken:
Measure one: the clock among the nodes is calibrated regularly, so that the clock synchronization among the nodes is kept, and particularly, when the operation and maintenance layer redeploys the system, a tool is used for keeping the clock synchronization among the nodes, and the current physical clock synchronization can be accurate to the second level, so that the second level synchronization can completely meet the design requirement in the actual application process.
And a second measure: after the step of packaging the transaction request into the current block, the method further comprises:
After the replica node receives the current block generated by the current block packaging node, comparing 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 value, not voting the current block by the replica node
Specifically, the size of the first preset threshold may be set according to actual design requirements, in the embodiment of the present application, the first preset threshold takes 2 minutes, if the interval between the building time of the current block and the local time of the copy node exceeds the first preset threshold, the block is not voted, because the node at this time is likely to be a bayer pattern node, and the bayer pattern attack of the malicious node is effectively performed through the set first preset threshold.
For transactions meeting a first preset threshold, the leader node takes an effective transaction- > leader node building block from a transaction pool, sets block building time- > leader node sending blocks to replica node- > replica node to vote- > next leader node to collect votes, if the votes exceed 2/3, the block is subjected to consensus, sets block consensus time- > block persistence, and sets block persistence time.
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, considering that the node cannot block when there is no transaction, if the transaction is sent only after a long time interval between two blocks in the K blocks, the value of Δk will be large, and if there are a plurality of such cases, a larger error will be caused. As shown in fig. 3, if the block-out interval time (t k-2-tk-1) between the block-out time (t k-1) of a certain block and the block-out time (t k-2) of a previous block is calculated to be greater than the default block-out time interval, the default block-out time interval is taken as the block-out interval time between the block and the previous block, and it should be noted that, in the embodiment of the present application, the default block-out time interval is set to 2 seconds.
For the second condition, since the Leader node needs to make a judgment when packaging the transaction, only the transaction with the client time earlier than the current time can be successfully packaged, and the building time of the block is certainly later than the packaging time, so that the second condition is ensured to be met.
Because node downtime may occur in the actual working process of the transaction running system, in the embodiment of the present application, the replay attack prevention method for the coalition chain transaction under the account system further includes: after the node is down, the current confirmed block of the node is obtained, n blocks are searched forward from the current confirmed block, and the n blocks are searched forward. The transaction requests corresponding to the n blocks are cached in the transaction cache pool P, and for the solution of recording all the historical transactions, the node is down or the data loss caused by physical damage can cause the situation that the node cannot be used, and the time for reestablishing all the transaction records is very long. According to the scheme, when node downtime occurs or data cache data is lost due to physical damage of the hard disk, the transaction cache pool P can be quickly recovered.
In order to prevent the client from randomly tampering with time, the embodiment of the application is provided. After the step of obtaining the client time of the transaction request, the method further includes: comparing the client time of the transaction request with the node local time, and rejecting the transaction request if the interval between the client time of the transaction request and the node local time is greater than a second preset time. Specifically, in the embodiment of the present application, the second preset time is set to 10 minutes, for example, the node local time is 15:00, and the client time of the transaction request that can be received is 14:50 to 15:10.
In the replay attack prevention method for the alliance chain transaction under the account system provided by the embodiment of the application, 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, it is indicated that the transaction corresponding to the transaction request should be packaged in the block before the first reference time point T1, but the transactions of the blocks are already determined, so that the transaction request is considered to have exceeded the packaging validity period of the transaction, and the transaction request is refused. 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, then it is queried whether the transaction cache pool P exists, if so, the transaction is indicated and packaged, and the transaction request is discarded. If the transaction request does not exist, the transaction corresponding to the transaction request is indicated to be valid, the latest block is packed, and all the transaction requests before the first reference time point T1 are refused by the transaction client time, because the transaction before the first reference time point T1 is not cached, whether the transaction is packed before the first reference time point T1 cannot be judged. The key point of saving the storage space and high efficiency of the scheme is that through the actual test of the new generation alliance chain at NEWSPIRAL, under the condition that the block-out interval is 2s, the number of the transaction requests cached in the transaction cache pool P is 150, so that all transactions can be guaranteed to be packaged normally, and the situation that the transactions are refused due to exceeding the validity period is hardly caused. Of course, with the progress of the blockchain technology, tps (system throughput) of the alliance chain certainly reach the level of hundreds of thousands or even millions in the future, so long as the cache height of the block is increased, the technical scheme is still applicable, the parameter n can be adjusted for dynamic adaptation for increasing Tps, and other methods have no adjustment capability.
According to the replay attack prevention method for the alliance chain transaction under the account system, provided by the embodiment of the application, through the design of the sliding time window, all packaged transactions after the first reference time point T1 are only required to be recorded, the transaction records can be cached in the memory under the condition that the time window is relatively short, and the transaction records can be considered to be stored in the database under the condition that the time window is relatively long. Because the stored transaction scale is small, the part of the transaction can be put in the cache under the condition that the time window is not particularly long, so that the weight judging speed of the transaction is extremely high, and the Tps of the system are not influenced. And the packing execution of the transactions is not strictly limited in sequence, and the failure of one transaction does not influence the normal packing 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 satisfied. Since only n blocks from the current block to the front are required to be cached in the transaction cache pool, the recovery of the transaction cache pool for abnormal conditions such as node downtime is very simple, and the performance of the alliance chain system is not affected.
Claims (9)
1. A replay attack prevention method for a coalition chain transaction under an account system, comprising:
acquiring a transaction request sent by a client;
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;
Judging whether the time of the client is earlier than or equal to a second reference time point T2, and if the time of the client is earlier than or equal to the 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; if no transaction corresponding to the transaction request exists in the transaction caching pool P, packaging the transaction corresponding to the transaction request into a current block, and caching the transaction corresponding to the transaction request into the transaction caching pool P;
Wherein, in the step of packaging the transaction request into the current block, the method further comprises:
Acquiring the packing time of a previous block, and if the packing time of the previous block is smaller than or equal to the local time of a current block packing node, setting the packing time of the current block as the local time of the current block packing node;
If the packing time of the last block is greater than the local time of the current block packing node, K block outlet times corresponding to K blocks in front of the current block are obtained, and whether the block outlet interval time between any two continuous blocks in the K blocks is greater than the default block outlet time interval is judged;
if the interval time between a certain two continuous blocks is larger than the default block outlet time interval, replacing the interval time between the certain two continuous blocks with the default block outlet time interval, calculating the average block outlet time delta K of the K blocks by using the replaced block outlet interval time, and delaying the average block outlet time delta K on the packing time of the last block to be used as the packing time of the current block.
2. The replay attack blocking method for a coalition chain transaction under an account hierarchy according to claim 1, wherein: after the step of obtaining the client time of the transaction request, further comprising:
if the client time 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 rejecting the transaction request if the transaction signature corresponding to the transaction request is incorrect.
3. The replay attack blocking method for a coalition chain transaction under an account hierarchy according to claim 2, wherein: the step of determining whether the client time is earlier than or equal to the second reference time point T2 further includes:
if the client time is later than the second reference time point T2, 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 all the transactions corresponding to the corresponding transaction request with all the transactions in the transaction cache pool P.
4. The replay attack blocking method for a coalition chain transaction under an account hierarchy according to claim 1, wherein:
Taking n blocks forward by the height m of the current block, and selecting the construction time of the m-n blocks as a first reference time point T1.
5. The replay attack blocking method of a coalition chain transaction under an account hierarchy according to claim 1, wherein the replay attack blocking method of a coalition chain transaction under an account hierarchy further comprises:
And obtaining block packing time corresponding to all transaction requests in the transaction cache pool P, and removing the transaction requests with the block packing time earlier than the first reference time point T1 from the transaction cache pool P.
6. The replay attack blocking method of a coalition chain transaction under an account hierarchy according to claim 1, comprising:
regularly calibrating clocks among nodes, and keeping the clocks among the nodes synchronous;
After the step of packaging the transaction request into the current block, the method further comprises:
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 value, the replica node does not vote for the current block.
7. The replay attack blocking method of a coalition chain transaction under an account hierarchy according to claim 1, wherein the replay attack blocking method of a coalition chain transaction under an account hierarchy further comprises:
After the node is down, the current confirmed block of the node is obtained, n blocks are searched forward from the current confirmed block, and transaction requests corresponding to the n blocks are cached to the transaction cache pool P.
8. The method for preventing replay attack from a coalition chain transaction under an account hierarchy according to claim 1, further comprising, after the step of obtaining the client time of the transaction request:
Comparing the client time of the transaction request with the node local time, and rejecting the transaction request if the interval between the client time of the transaction request and the node local time is greater than a second preset time.
9. The method of claim 1, wherein the step of packing the transaction request into chunks increases the time of constructing the chunks.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111086264.XA CN113807963B (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.XA CN113807963B (en) | 2021-09-16 | 2021-09-16 | Replay attack prevention method for alliance chain transaction under account system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113807963A CN113807963A (en) | 2021-12-17 |
| CN113807963B true CN113807963B (en) | 2024-05-03 |
Family
ID=78941275
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111086264.XA Active CN113807963B (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 (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108764870A (en) * | 2018-05-29 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Transaction processing method and device, electronic equipment based on block chain |
| CN111200589A (en) * | 2019-12-05 | 2020-05-26 | 北京数字认证股份有限公司 | Data protection method and system for alliance chain |
| 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 |
Family Cites Families (3)
| 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 |
| US9357384B2 (en) * | 2009-02-09 | 2016-05-31 | International Business Machines Corporation | System and method to support identity theft protection as part of a distributed service oriented ecosystem |
| US10992714B2 (en) * | 2019-01-07 | 2021-04-27 | International Business Machines Corporation | Certifying authenticity via dynamic dimensional coordinate scanning and decentralized data storage |
-
2021
- 2021-09-16 CN CN202111086264.XA patent/CN113807963B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108764870A (en) * | 2018-05-29 | 2018-11-06 | 阿里巴巴集团控股有限公司 | Transaction processing method and device, electronic equipment based on block chain |
| CN111899006A (en) * | 2018-05-29 | 2020-11-06 | 创新先进技术有限公司 | Transaction processing method and device based on block chain and electronic equipment |
| 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 |
|---|---|
| CN113807963A (en) | 2021-12-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7926103B2 (en) | System and method for preventing replay attacks | |
| CN110213038B (en) | Method and system for forming consensus of block chain | |
| Du et al. | Partitionchain: A scalable and reliable data storage strategy for permissioned blockchain | |
| Li et al. | Gosig: Scalable byzantine consensus on adversarial wide area network for blockchains | |
| US20220229829A1 (en) | Real-time data validation using lagging replica databases | |
| CN112184436A (en) | Data synchronization method, electronic device and readable storage medium | |
| CN113807963B (en) | Replay attack prevention method for alliance chain transaction under account system | |
| CN109889519B (en) | Algorithm for avoiding non-cost attack in block chain consensus | |
| CN113326332B (en) | Snapshot synchronization method and device of blockchain | |
| CN111611311B (en) | Method and system for forming decentralised distributed database, electronic device and computer readable storage medium | |
| CN114402352A (en) | Method and apparatus for tracking and measuring a proof of work contribution in a mine | |
| CN110580307B (en) | Processing method and device for fast statistics | |
| WO2020172881A1 (en) | Block generation method and apparatus, computer device and storage medium | |
| CN115297009B (en) | Digital encryption consistency optimization method based on blockchain distributed network | |
| EP2477137A1 (en) | Method for verifying the integrity of a set of data | |
| CN112600698B (en) | Block chain consensus method, system, equipment and medium applied to non-block-out node | |
| CN112583908B (en) | Block chain consensus method, system, equipment and medium applied to block outlet node | |
| Dobre et al. | Proofs of writing for robust storage | |
| Hackfeld | A lightweight BFT consensus protocol for blockchains | |
| CN112487496B (en) | Block chain consensus system | |
| CN110489460B (en) | Optimization method and system for rapid statistics | |
| CN111400328A (en) | Data updating method and device and node server | |
| Chun et al. | Tiered Fault Tolerance for Long-Term Integrity. | |
| CN116151826B (en) | Power transaction terminal trust management method based on blockchain | |
| Kong et al. | Agile store: Experience with quorum-based data replication techniques for adaptive Byzantine fault tolerance |
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 |