A two-phase proof-of-work-based attack prevention method

By employing a two-phase proof-of-work mechanism and dynamically adjusting the difficulty of proof-of-work, the problems of spam requests and spam attacks are solved, improving system security and user experience, and optimizing resource allocation.

CN116743484BActive Publication Date: 2026-03-10SOUTHWESTERN UNIV OF FINANCE & ECONOMICS
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-07-14
Publication Date
2026-03-10

AI Technical Summary

Technical Problem

Existing technologies are insufficient to effectively prevent spam requests and spam attacks, resulting in compromised system stability and security, and a poor user experience.

Method used

A two-stage proof-of-work mechanism is adopted. By setting a first difficulty coefficient D1 and a second difficulty coefficient D2, the difficulty of proof-of-work is dynamically adjusted. Combined with hash function and linear regression model, the system load is predicted to ensure that legitimate requesters can access the system smoothly.

Benefits of technology

It improves system security and stability, optimizes resource allocation, enhances user experience, strengthens system scalability, and reduces the cost of malicious attacks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116743484B_ABST
    Figure CN116743484B_ABST
Patent Text Reader

Abstract

This invention discloses an attack prevention method based on two-phase proof-of-work, comprising the following steps: setting a first difficulty coefficient D1; determining the validity of the requester's first-phase proof-of-work based on the first difficulty coefficient D1 and the message body msgl and number n1 generated by the requester; if invalid, refusing to provide service to the requester; if valid, dynamically adjusting the difficulty of the second-phase proof-of-work according to the system load, requiring the requester to perform the second-phase proof-of-work; and providing the corresponding service to the requester after the requester successfully completes the second-phase proof-of-work. This method avoids attacks on the service provider by the requester through a large number of spam requests and spam messages, improves system security, enhances user experience, optimizes resource allocation, and strengthens system scalability.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of network security, and specifically to an anti-attack method based on two-stage proof-of-work. Background Art

[0002] In network services, the service provider provides various network services or receives emails for the requester. The service provider needs to ensure that its system has a certain defense ability against malicious requests and attacks to maintain the stability and security of the system. Attackers usually disguise themselves as requesters and send a large number of spam requests or messages, burdening the service provider and even causing normal service requests to be unresponsive in some cases. Therefore, in order to enable the requester to access the required services quickly and securely and prevent the service provider from being maliciously attacked, it is necessary to establish a targeted anti-attack mechanism. Summary of the Invention

[0003] In view of the above deficiencies in the prior art, an anti-attack method based on two-stage proof-of-work provided by the present invention can effectively prevent spam requests and spam information attacks.

[0004] In order to achieve the above-mentioned invention purpose, the technical solution adopted by the present invention is as follows:

[0005] Provide an anti-attack method based on two-stage proof-of-work, which includes the following steps:

[0006] S1. Set the first difficulty coefficient D1;

[0007] S2. Obtain the message body msg1 and the number n1 generated by the requester; the message body msg1 includes the requester identity information, the service provider identity information, the timestamp, and the requested service type;

[0008] S3. Calculate and determine whether hash(msg1 + n1) < D1 holds. If so, it is determined that the first-stage workload of the requester is valid, and step S4 is entered; otherwise, the service is refused to be provided to the requester;

[0009] S4. Calculate the second difficulty coefficient D2 according to the requested service type in msg1 and the current load situation, and send the second difficulty coefficient D2 to the requester;

[0010] S5. Determine whether the request message request_message and the number n2 returned by the requester are received within the set time. If so, step S6 is entered; otherwise, it is determined that there is no second-stage workload, and the current second difficulty coefficient D2 is invalidated; the request message request_message includes the request time and the requested service type;

[0011] S6. Calculate and determine whether hash(request_message + n1 + n2) < D2 holds. If it does, provide corresponding services to the requester; otherwise, reject providing services to the requester.

[0012] Further, the method for obtaining the number n1 in step S2 is as follows:

[0013] In response to the first difficulty coefficient D1, the requester selects a number n1 starting from 0 in a step - by - step increasing manner until hash(msg1 + n1) < D1 holds, and then sends the current msg1 and n1 to the service provider; where hash is a hash function, including sha256 and sha512.

[0014] Further, the specific method for calculating the second difficulty coefficient D2 in step S4 is as follows:

[0015] Based on the current system load, predict the system load L_predicted(t_next) in the next time period through a linear regression model; according to the formula:

[0016] D2 = D_base + α * L_predicted(t_next) + γ * cost(request_type)

[0017] Obtain the second difficulty coefficient D2; where D_base is a preset constant; α is a load impact factor; γ is a service cost factor for the request; cost(request_type) represents the cost of the requested service type.

[0018] The beneficial effects of the present invention are as follows: The present invention enables the requester to perform a proof - of - work through the first difficulty coefficient, and then dynamically adjusts the difficulty of the proof - of - work in the second stage according to the system load, avoiding attacks by the requester on the service provider through a large number of garbage requests and garbage information, improving the security of the system, enhancing the user experience, optimizing resource allocation, and strengthening the scalability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a flowchart of this method. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The following describes the specific embodiments of the present invention to facilitate those skilled in the art of this technology to understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those ordinary skilled in the art of this technology, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions made using the concept of the present invention are within the scope of protection.

[0021] As Figure 1As shown, the anti-attack method based on two-stage proof-of-work includes the following steps:

[0022] S1. Set the first difficulty coefficient D1;

[0023] S2. Obtain the message body msg1 and the number n1 generated by the requester; where the message body msg1 includes the requester's identity information, the service provider's identity information, the timestamp, and the requested service type;

[0024] S3. Calculate and determine whether hash(msg1 + n1) < D1 holds. If so, it is determined that the requester's first-stage workload is valid, and proceed to step S4; otherwise, refuse to provide services to the requester;

[0025] S4. Calculate the second difficulty coefficient D2 according to the requested service type in msg1 and the current load condition, and send the second difficulty coefficient D2 to the requester;

[0026] S5. Determine whether the request information request_message and the number n2 returned by the requester are received within the set time. If so, proceed to step S6; otherwise, it is determined that there is no second-stage workload, and the current second difficulty coefficient D2 is invalidated; where the request information request_message includes the request time and the requested service type;

[0027] S6. Calculate and determine whether hash(request_message + n1 + n2) < D2 holds. If so, it is determined that the second-stage workload is valid, and provide the corresponding service to the requester; otherwise, refuse to provide services to the requester.

[0028] The method for obtaining the number n1 in step S2 is as follows: In response to the first difficulty coefficient D1, the requester selects a number n1 in a gradually increasing manner starting from 0 until hash(msg1 + n1) < D1 holds, and then sends the current msg1 and n1 to the service provider; where Hash() is a public hash function, including sha256 and sha512.

[0029] The specific method for calculating the second difficulty coefficient D2 in step S4 is as follows: Based on the current system load, predict the system load L_predicted(t_next) in the next time period through a linear regression model; According to the formula:

[0030] D2 = D_base + α * L_predicted(t_next) + γ * cost(request_type)

[0031] Obtain the second difficulty coefficient D2; where D_base is a preset constant; α is the load impact factor; γ is the service cost factor of the request; cost(request_type) represents the cost of the requested service type.

[0032] In practice, after receiving the returned difficulty coefficient, if the requesting party deems the difficulty coefficient of the second stage (i.e., the second difficulty coefficient D2) too high to be worth continuing, it can abandon the access. Specifically, in the requesting party's client software, the user can set a default acceptable difficulty coefficient D. If D is greater than D2, the software automatically enters the second stage. If D is less than D2, the user is prompted via the user interface whether to accept the proof-of-work requirement for this computational load (which may include the expected average computational cost). If the user accepts, the second stage begins; otherwise, the request is abandoned. This mechanism not only inflicts significant costs on malicious attackers launching denial-of-service attacks but also allows service providers to suppress unnecessary access requests by requiring a high-difficulty proof-of-work, thereby improving system availability during periods of high load.

[0033] After validating the requester's proof-of-work in the first phase, the service provider will require a further dynamic proof-of-work in the second phase, based on the cost of the request type and its own load. In other words, if the service provider is under heavy load, it will require a higher proof-of-work from the requester; if the load is ample, the requirement will be lower. Simultaneously, the proof-of-work is proportional to the cost of the request type to prevent asymmetric denial-of-service attacks. This increases the cost of attacks for attackers, ensuring that genuinely needy users receive better service.

[0034] If the requesting party fails to provide a request message and the number n2 within the set time after successfully proving the first phase of work, the second difficulty coefficient D2 and the validity of the first phase of work will be invalidated. If the requesting party initiates another request at this point, the validity of the first phase of work will need to be re-verified. Although D1 can remain unchanged, the use of timestamps in the first phase of work proof means that if the requesting party directly uses the previously obtained number n1 for the first phase of work proof, it may fail the proof. The addition of timestamps prevents the requesting party from continuously using the previously obtained number n1, thus preventing a one-time solution from being implemented indefinitely.

[0035] After a requester successfully completes the second-phase proof of work for the first time, if the requester initiates another request within a certain period, the service can be provided directly, or the requester can be required to complete the second-phase proof of work again. After this period, the system can choose to complete only the second-phase proof of work or re-complete the first-phase proof of work. This approach improves service responsiveness, prevents attackers from posing as legitimate requesters at the beginning and launching attacks after the initial successful completion of the two-phase proof of work, improves user experience, optimizes resource allocation, and enhances system stability.

[0036] In one embodiment of the present invention, L_predicted(t_next) uses the following linear regression model for prediction:

[0037] L_predicted(t_next)=β0+β1*L_current(t)

[0038] β0 and β1 are coefficients obtained by fitting historical load data. That is, future loads can be predicted by fitting historical load data. The specific method for calculating β0 and β1 is as follows:

[0039] Let the historical load data be (L1, L2, ..., Lt), and the corresponding time points be (t1, t2, ..., tt). Here, t represents the current time, and L represents the system load at the corresponding time point. We want to predict the system load at time point t_next. In a linear regression model, β0 and β1 can be calculated using the following formulas:

[0040] β1=[Σ((ti-mean(t))*(Li-mean(L)))] / Σ((ti-mean(t))^2)

[0041] β0 = mean(L) - β1 * mean(t)

[0042] Where ti represents the i-th time point, Li represents the i-th historical load data, mean(t) and mean(L) represent the average of the historical load data and the corresponding time point, respectively, and Σ represents summation.

[0043] This embodiment uses a simple linear regression model to predict future load based on historical load data. In practice, other factors, such as system characteristics and service provider strategies, can be added to adjust the model and make the predictions more accurate.

[0044] In summary, this method dynamically adjusts the difficulty threshold of the second phase based on the actual load and performance metrics of the service provider, which helps optimize resource allocation and improve the system's scalability and adaptability. By notifying users of the specific difficulty threshold in the second phase, this method allows users to understand the server's congestion level, avoiding repeated attempts without their knowledge and improving the user experience. Furthermore, this method provides the service provider with a higher level of security, effectively resisting malicious attacks such as denial-of-service attacks and spam.

Claims

1. An attack prevention method based on two-stage proof of work, characterized in that, The method comprises the following steps: S1, setting a first difficulty coefficient D1; S2, obtaining a message body msg1 and a number n1 generated by a requester; wherein the message body msg1 comprises requester identity information, service provider identity information, a time stamp and a requested service type; S3, calculating and judging whether hash(msg1+n1)<D1 is true, if yes, it is determined that the first stage workload of the requester is valid, and step S4 is entered; otherwise, the service to the requester is refused; S4, calculating a second difficulty coefficient D2 according to the requested service type in msg1 and the current load condition, and sending the second difficulty coefficient D2 to the requester; S5, judging whether the requester information request_message and the number n2 returned by the requester are received within a set time, if yes, step S6 is entered; otherwise, it is determined that there is no second stage workload, and the current second difficulty coefficient D2 is invalidated; wherein the requester information request_message comprises a requested time and a requested service type; S6, calculating and judging whether hash(request_message+n1+n2)<D2 is true, if yes, the corresponding service is provided to the requester; otherwise, the service to the requester is refused.

2. The attack-resistant method based on two-stage proof-of-work according to claim 1, characterized in that, The method for obtaining the number n1 in step S2 is as follows: In response to the first difficulty coefficient D1, the requester selects a number n1 in a step-by-step increasing manner from 0 until hash(msg1+n1)<D1 is true, and sends the message body msg1 and the number n1 at this time to the service provider; wherein hash is a hash function, including sha256 and sha512.

3. The attack-resistant method based on two-stage proof-of-work according to claim 1, characterized in that, The specific method for calculating the second difficulty coefficient D2 in step S4 is as follows: Based on the current system load, the system load L_predicted(t_next) in the next time period is predicted through a linear regression model; according to the formula: D2=D_base+α*L_predicted(t_next)+γ*cost(request_type) the second difficulty coefficient D2 is obtained; wherein D_base is a preset constant; α is a load influence factor; γ is a requested service cost factor; and cost(request_type) represents the cost of the requested service type.

Citation Information

Patent Citations

  • Identification method and device for denial of service attack

    CN103701794A

  • Voting-based CONSENSUS METHOD

    CN109964446A