A network security competition dynamic score calculation method based on problem solving proportion

Abstract

The application discloses a network security competition dynamic score calculation method based on problem solving ratio, and belongs to the technical field of information security. The method captures and verifies the submission records of participating teams through a message queue, obtains the number of times of solving the competition problems and the total number of teams submitting the problems in real time, and calculates a problem solving ratio coefficient. An exponential function with a natural constant as a base is adopted to construct a score decay model, a steepness coefficient is configured according to the difficulty of the competition problems, a deviation inflection point parameter is set according to the initial score, and a score decay coefficient is obtained. The decay coefficient is multiplied by the initial score to obtain a real-time dynamic score, and the score variation trend is displayed in a dynamic curve graph. The number of active teams is periodically scanned, the base refresh frequency is adjusted, and the base is locked to ensure stable scoring during the competition sprint period.

Description

Technical Field

[0001] This application belongs to the field of information security technology, specifically involving a method for calculating dynamic scores in cybersecurity competitions based on the proportion of questions solved. Background Technology

[0002] With the rapid development of information security technology, cybersecurity competitions have become an important way to select and evaluate high-end security technology talents. They play an irreplaceable role in practical exercises and the construction of cyberspace defense systems. Modern competition models emphasize the simulation of complex attack and defense scenarios, requiring the evaluation system to reflect the contestants' technical problem-solving capabilities and the progress of the competition in real time.

[0003] The dynamic scoring mechanism, as a key component of the evaluation system, has its core value in ensuring the objectivity of the competition evaluation by using a data feedback mechanism to recalibrate the difficulty of the questions.

[0004] Among them, the dynamic score calculation method based on the scale of problem solving is the current mainstream scoring logic. It aims to adjust the weight of the problem in real time by dynamically changing the number of people solving the problem. The core of this technology is to establish a mapping relationship between the problem solving status and the score, so that the final score can accurately anchor the actual difficulty of solving the problem. An effective dynamic score model should be able to smoothly handle the score fluctuations at different problem solving stages and provide contestants with hierarchical competitive feedback.

[0005] However, existing dynamic scoring algorithms generally adopt a simple score reduction logic based on the reciprocal of the number of solvers, which causes the score to drop too quickly in the early stage when there are few solvers, seriously affecting the fair competition among top players.

[0006] Meanwhile, traditional linear score reduction models lack sufficient convergence stability as the problem-solving scale increases, and the scores often drop rapidly to the minimum limit point, causing the scores of problem-solving teams to converge in the middle and later stages and failing to reflect differences in skill levels.

[0007] Furthermore, existing technologies lack a non-linear adjustment mechanism that can simulate the difficulty curve of human cognition, and cannot flexibly configure attenuation parameters according to the expected challenge of a specific problem. This results in a rigid logic for score changes, making it easy for score fluctuations to become disconnected from the actual difficulty of solving the problem.

[0008] Therefore, a dynamic score calculation method for cybersecurity competitions based on the proportion of questions solved is desired. Summary of the Invention

[0009] To address the aforementioned technical problems, this application provides a method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio, employing the following technical solution: A method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio, comprising the following steps: S1. Capture the competition problem Flag submission records of participating teams through the message queue, call the preset Flag verification service to determine the correctness of the submission records, and retrieve the solution count variable n and the total cardinality variable N of each problem in real time. The total cardinality variable N is the total number of active teams in the current competition whose status field is marked as active and whose login count records have reached at least 2.

[0010] S2. Based on the number of solutions variable n and the total base variable N, calculate the ratio of the number of solutions variable n to the total base variable N as the solution ratio coefficient. Use the solution ratio coefficient as the core driving factor for score decay. Construct a score decay model using an exponential function with the natural constant as the base. The score decay model uses the solution ratio coefficient as the input variable and the steepness coefficient and offset inflection point parameter as model adjustment parameters, and outputs the score decay coefficient.

[0011] S3. Set the value of the steepness coefficient according to the difficulty level of the competition question. Set the first steepness coefficient value range for basic difficulty competition questions and the second steepness coefficient value range for high difficulty competition questions. Configure the offset inflection point parameter according to the initial score of the competition question.

[0012] S4. Multiply the score decay coefficient by the initial score of the question to calculate the real-time dynamic score of the question, and display the score change trend of each question in real time through a dynamic curve graph on the front-end interface of the competition.

[0013] S5. Periodically perform a global activity scan to count the number of currently active teams, and dynamically adjust the refresh frequency of the total base variable N based on the number of active teams.

[0014] Preferably, in step S3, the minimum value of the first steepness coefficient range is not less than 10 and the maximum value is not greater than 15, and the minimum value of the second steepness coefficient range is not less than 25 and the maximum value is not greater than 40.

[0015] The numerical range of the offset inflection point parameter mentioned in step S2 is a minimum value of not less than 0.05 and a maximum value of not more than 0.25.

[0016] When the initial maximum score of a problem exceeds the preset threshold of 2000 points, the system automatically reduces the value of the offset inflection point parameter, so that the score enters the decay stage at a lower problem-solving ratio.

[0017] Preferably, it also includes a parameter intelligent prediction step: A parameter prediction model is constructed using a long short-term memory neural network. The input layer of the long short-term memory neural network includes the category to which the competition question belongs, the size of the competition question attachments, the number of lines of code in the competition question, and the preset difficulty level. The category to which the competition question belongs is encoded using one-hot encoding. The size of the competition question attachments is normalized in kilobytes. The number of lines of code in the competition question is normalized. The preset difficulty level is an integer from 1 to 5.

[0018] The output layer of the long short-term memory neural network outputs the predicted steepness coefficient and offset inflection point parameters.

[0019] The Long Short-Term Memory Neural Network uses the historical problem-solving ratio curves and the distribution data of the participants as training datasets for model training.

[0020] Preferably, in step S4, when calculating the real-time dynamic score, a cross-platform fixed-point decimal algorithm is used to expand the score to an integer multiple before performing the calculation and then restore the original dimension, thereby eliminating the score calculation deviation caused by the difference in floating-point arithmetic between different operating systems.

[0021] After the mapping calculation process is completed, the rounding function is called to perform an up-rounding operation on the calculation result, ensuring that the team that solves the problem first maintains a scoring advantage over the team that solves the problem later.

[0022] Preferably, it also includes a tie-sorting step: When multiple teams have the same total score, a time weight factor is introduced as the ranking basis. The time weight factor is calculated based on the timestamp of the team's last correct Flag submission. The team with the earlier timestamp receives a higher ranking weight, ensuring that the team that solves the problem first has a ranking advantage in the case of a tie.

[0023] Preferably, it also includes steps for monitoring abnormal problem-solving behavior: The system analyzes the rate of change of the solution ratio for each problem relative to time in real time. When the change in the solution ratio exceeds the preset 0.05 ratio threshold within a preset 5-minute monitoring period, the system triggers an abnormal behavior warning.

[0024] By analyzing the source IP addresses of the submission requests from participating teams, concentrated submission behavior under the same subnet is identified. When the time interval between solving problems is lower than the minimum expected logical time threshold corresponding to the problem, the corresponding batch of problem-solving records are temporarily placed in the queue to be verified and not immediately included in the number of solutions variable n. They are officially included and the score is updated after the multi-factor risk control model completes the security evaluation.

[0025] The minimum expected logical time threshold is configured differently according to the type of competition question. It is set to 60 seconds for basic Web-type questions and 300 seconds for high-difficulty Pwn-type questions.

[0026] Preferably, the periodic execution of the global activity scan in step S5 is a preset fixed duration. When the competition enters the final 30-minute sprint stage, the sprint calibration operator is activated to lock the value of the total base variable N, and teams newly submitted during the sprint stage are no longer included in the total base variable N, ensuring the stability of the scoring logic during the sprint stage.

[0027] Preferably, the multi-factor risk control model comprehensively considers three dimensions—the problem-solving time interval, the degree of IP address clustering, and the historical submission behavior pattern—to calculate a risk score for each batch of problem-solving records in the queue to be verified. The weight coefficient of the problem-solving time interval factor is 0.4, the weight coefficient of the IP address clustering factor is 0.35, and the weight coefficient of the historical submission behavior pattern factor is 0.25.

[0028] When the risk score is below the preset safety threshold of 60 points, a safety evaluation is output, the problem-solving records in the pending verification queue are transferred to the formal problem-solving record table, and a score update is triggered. When the risk score is above the preset safety threshold of 60 points, it is marked as abnormal behavior, and an early warning signal is pushed to the administrator terminal.

[0029] Preferably, the calculation results of the real-time dynamic score adopt a persistence strategy that combines incremental updates and full alignment: When a score changes, the difference is first written to the question score hash table in the Redis cache to complete the incremental update operation. A scheduled task synchronizes the incremental update results in Redis to the relational database in batches at fixed time intervals. The leaderboard query interface reads the real-time score from Redis first. The database is used for historical data archiving and final score calculation.

[0030] Preferably, the message queue adopts a distributed message queue system to achieve high-concurrency capture and peak shaving of submission records.

[0031] The backend monitoring module adopts a layered processing architecture, including a data capture submodule and a statistical aggregation submodule deployed in multiple container instances. The data capture submodule is responsible for initially filtering and verifying the requests submitted by participating teams from different geographical locations, and forwarding the verified messages to the statistical aggregation submodule.

[0032] The statistical aggregation submodule uses a distributed lock mechanism to incrementally accumulate the global solution count variable n.

[0033] The hierarchical processing architecture supports more than 10,000 participating teams submitting flag strings online simultaneously.

[0034] In summary, this application includes at least one of the following beneficial technical effects: 1. This application overcomes the problem of excessively rapid score drop in the early stage by introducing an exponential score decay model driven by the problem-solving ratio. It utilizes an S-shaped decay curve constructed by a logistic regression function, along with flexible configuration of steepness coefficient and offset inflection point parameters, to achieve a gradual decay of scores in the low problem-solving ratio range. This effectively protects the scoring advantage of top players and achieves a smooth transition in the mid-to-late stage, avoiding a cliff-like drop in scores or premature convergence to the lowest point.

[0035] 2. This application significantly improves the matching degree between score changes and the actual difficulty of the competition problems through a nonlinear mapping mechanism. The steepness coefficient is set according to the difference in difficulty level of the competition problems, and the offset inflection point parameter is dynamically adjusted in combination with the initial score. This allows high-difficulty competition problems to maintain high scores even after a few teams have solved them, while basic problems decay rapidly. In addition, a long short-term memory neural network is introduced to train on historical data to intelligently recommend the optimal decay parameters for new competition problems, reducing human experience errors and enhancing the objectivity and adaptability of the scoring system.

[0036] 3. This application enhances the stability and fairness of dynamic score calculation at the system implementation level. By adopting a cross-platform fixed-point decimal algorithm, it eliminates the differences in floating-point arithmetic and ensures score consistency. Combined with incremental caching and asynchronous persistence strategies, it supports ultra-large-scale concurrent scenarios. At the same time, through monitoring the change rate of the problem-solving ratio, IP aggregation identification, and multi-factor risk control models, it effectively prevents flag leakage or collusion cheating. Furthermore, it locks the scoring base during the competition sprint stage, ensuring the stability and fairness of the later scoring. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall core calculation process of this invention.

[0038] Figure 2 This is a schematic diagram of the calculation process for the score decay model of this invention.

[0039] Figure 3 This is a schematic diagram of the intelligent parameter prediction process of the present invention.

[0040] Figure 4 This is a schematic diagram of the abnormal problem-solving behavior monitoring process of the present invention.

[0041] Figure 5 This is a schematic diagram of the score persistence and sprint period calibration process of the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, please refer to... Figures 1 to 5 The present invention will be further described in detail below with reference to specific embodiments.

[0043] In the technical implementation of the cybersecurity competition scoring system, this invention discloses a dynamic score calculation method for cybersecurity competitions based on the problem-solving ratio. This method is completed through the cooperation of multiple functional components in a distributed computing environment. The method is first executed by a backend monitoring module, which is configured in the application logic layer of the competition platform and maintains bidirectional communication with the real-time transaction logs in the database.

[0044] For this invention, step S1, collecting real-time competition data, is implemented as follows: In step S101, the backend monitoring module of the competition platform uses a distributed message queue to capture submission records.

[0045] Whenever a participating team submits a flag string (Flag) via the front-end page, the application logic layer receives the submission request. The application logic layer encapsulates the submission request into a message body, which contains the team's unique identifier, the competition identifier, the submission timestamp, and the original Flag text.

[0046] The team's unique identifier is used to distinguish different participating teams, usually a team ID or username; the problem identifier is used to identify which specific problem the submission is for; the submission timestamp records the precise moment the submission occurred, with millisecond-level precision; and the Flag is the string submitted by the participating team that is yet to be verified.

[0047] After the application logic layer completes the encapsulation, it does not immediately process the flag verification, but instead pushes the message body to the message queue for temporary storage, thereby achieving asynchronous decoupling of submission reception and business processing.

[0048] In step S102, the application logic layer pushes the encapsulated message body to a high-throughput distributed message queue.

[0049] Distributed message queues can be Kafka or RabbitMQ. These message queues have persistent storage and sequential consumption capabilities, which can play a role in peak shaving and valley filling in high-concurrency scenarios. The backend monitoring module acts as a consumer of the message queue, pulling message bodies from the message queue in the order in which messages arrive.

[0050] For each message body retrieved, the backend monitoring module first extracts the original Flag text and calls the Flag verification service to check if the Flag is correct. If the verification passes, the backend monitoring module retrieves the current number of solutions variable n for that specific competition problem in real time. The number of solutions variable n represents the total number of participating teams that have successfully submitted the correct flag string.

[0051] When retrieving the solution count variable n, the backend monitoring module reads the current count value of the problem from the high-speed cache Redis to avoid the performance overhead caused by directly querying the database. The verification failure message body is directly discarded or recorded in the failure log and does not participate in the subsequent scoring process.

[0052] Step S103: When the problem-solving record table in the database undergoes an incremental change, the backend monitoring module captures the update event of the solution count variable n through a database trigger or asynchronous listening service.

[0053] A database trigger is a stored procedure that is automatically executed after an insert operation occurs in the record table. This database trigger is triggered before the database transaction is committed, and writes the change information to a dedicated change log table. The asynchronous listening service then uses a database binary log parsing component such as Canal or Debezium to parse the MySQL binlog in real time and extract the insert operation record from it.

[0054] Both methods can achieve real-time perception of changes in the number of solutions. After the backend monitoring module adopts either method, it can immediately know the change in the value of n. The end-to-end delay of the entire data acquisition link from submission to backend perception is controlled within 50 milliseconds, ensuring the timeliness of score calculation in a high-concurrency environment.

[0055] In step S104, the backend monitoring module simultaneously retrieves the total number of participants N. The total number of participants N represents the total number of participating teams that are eligible to score in the competition. Unlike the number of solutions n, the value of N changes less frequently and usually remains relatively stable throughout the competition.

[0056] The background monitoring module reads the current value of N from the Redis cache. This value is updated by the periodic scanning task in step S108. The acquisition of N and n are performed in parallel without blocking each other, ensuring that both parameters are in the latest state when calculating the problem-solving ratio coefficient r.

[0057] If there is no N value in Redis or the N value is empty, the backend monitoring module will fall back to directly querying the team metadata table to get the number of active teams, and write the query result to Redis for later use.

[0058] The specific implementation process of obtaining and caching the total cardinality variable N in step S1 is as follows: In step S105, the backend monitoring module uses the backend management function to count in real time the number of teams whose status field is marked as active and whose login count records have reached at least 2 times in the current event.

[0059] The specific statistical method is as follows: the backend monitoring module sends a structured query language query request to the team metadata table. The query conditions are set to the status field being equal to the activation value and the login count field being greater than or equal to 2. Each record in the team metadata table corresponds to a participating team. The status field is used to identify the team's participation status, and the activation value means that the team has completed registration confirmation and has not been banned.

[0060] The login count field records the number of times the team has successfully logged in on the competition platform, incrementing with each login attempt. Setting the login count to at least 2 is intended to exclude invalid accounts that have only registered but never actually logged in, and also to filter out edge cases where the login is interrupted after only one attempt due to network interruptions.

[0061] The number of records returned by the query is the total number of active teams in the current event, and this value is used as the basis for determining the total cardinality variable N.

[0062] The above statistical method eliminates invalid accounts that did not actually participate after registration or whose network connection was interrupted by querying the status field and login count field in the team metadata table, thereby eliminating the interference of invalid accounts on the accuracy of the problem-solving ratio coefficient calculation.

[0063] In step S106, the backend monitoring module maintains a real-time status cache in the high-speed in-memory database Redis. This cache is used to store the number of times each problem is solved. Redis, as a memory-based key-value storage system, has sub-millisecond read and write latency and high concurrency processing capabilities. In Redis, the backend monitoring module creates an independent key-value pair for each problem. The key name is formed by concatenating the problem identifier with a fixed prefix.

[0064] All competition counters are stored in the same Redis database instance for centralized management and fast access.

[0065] Step S107: Whenever the distributed message queue returns a successful flag string verification result, the backend monitoring module performs an atomic increment operation on the corresponding problem-solving count counter stored in Redis to ensure the accuracy of the counting data in a high-concurrency environment.

[0066] Atomic increment operations are implemented using the INCR command provided by Redis. This command performs three steps on the server side: reading, incrementing, and writing back. The entire process is not affected by other concurrent requests, thus ensuring that even if multiple verification results arrive at the same time, the final result of the counter will not be lost or double-accumulated.

[0067] After executing the INCR command, Redis will return the new value after auto-incrementing. The backend monitoring module can directly use this new value as the updated solution count variable n, without needing to initiate an additional query request.

[0068] The atomic operation mechanism described above avoids the counting errors caused by concurrency contention in traditional read, modify, and write modes. Step S108: For the maintenance of the total cardinality variable N of all participants, the backend monitoring module periodically performs a global activity scan every 60 seconds to count the number of currently active teams and update the total cardinality variable N stored in Redis with the scan results.

[0069] The backend monitoring module starts an independent background timer, which triggers a scan task every 60 seconds. The scan task executes the statistical logic described in step S105, that is, it initiates a query to the team metadata table, filters team records with an active status field and a login count field greater than or equal to 2, and counts the query results to obtain the total number of currently active teams.

[0070] Subsequently, the backend monitoring module uses the Redis SET command to write the count value into a predefined key name, such as contest:total:active, overwriting the previously stored old value. The 60-second cycle setting balances the sensitivity of N value changes with system overhead, because the number of active teams usually does not fluctuate drastically in a short period of time. Updating once per minute is sufficient to ensure the calculation accuracy of the problem-solving ratio coefficient r, while avoiding excessively frequent database queries that could put pressure on the main business of the competition platform.

[0071] If a database connection fails or a query times out during a scan, the backend monitoring module retains the N value obtained from the previous successful scan and records the exception log for maintenance personnel to investigate, ensuring that the N value does not become null due to a single scan failure.

[0072] For this invention, step S2, calculating the problem-solving ratio coefficient, is specifically implemented as follows: Step S201: After obtaining the solution count variable n and the total base variable N, the calculation engine uses the solution count variable n as the numerator and the total base variable N as the denominator, and obtains the real-time problem-solving ratio coefficient r through high-precision floating-point division.

[0073] High-precision floating-point division uses double-precision floating-point format, namely 64-bit floating-point numbers according to the IEEE 754 standard. Its effective digital precision is approximately 15 decimal digits, which can ensure that the calculation error of the scaling factor is controlled within a very small range. The expression for division is r=n / N. When n and N are both integers, the result is automatically converted to a floating-point number.

[0074] If the values ​​of n and N are large, the result of the division may be a very small decimal. The high-precision floating-point format can accurately represent such values ​​without underflow.

[0075] Step S202: The real-time problem-solving ratio coefficient r is used to reflect the popularity of a specific problem across the entire competition and the actual difficulty of the problem. When the value of r is close to 0, it indicates that very few teams have solved the problem and the problem is difficult. The corresponding dynamic score should be maintained at a high level. When the value of r is close to 1, it indicates that most participating teams have solved the problem and the problem is difficult. The dynamic score should be reduced to a low level.

[0076] The value of this coefficient is strictly limited to a preset normalized closed interval between 0 and 1. If the result is slightly less than 0 or slightly greater than 1 due to floating-point precision issues during the calculation process, the calculation engine will clamp it to the boundary value of 0 or 1 to ensure that the input of the subsequent nonlinear mapping stage is always within the effective domain.

[0077] In step S203, during the division operation, if the total base variable N becomes a specific null value or the value 0 due to network fluctuations or initialization anomalies, the calculation engine of the present invention automatically determines the real-time problem-solving ratio coefficient r as a preset initial value of 0, thereby avoiding the logical anomaly of division by zero in the division operation.

[0078] Specifically, before performing the division r=n / N, the calculation engine first checks the validity of the denominator N. If N equals 0 or N is empty, the division operation is skipped and r is directly assigned the value 0. This preset initial value of 0 corresponds to a problem-solving ratio of 0%, which means that there are currently no valid participating teams or no teams have solved the problem. At this time, the decay coefficient f(r) will approach 0, and the dynamic score will remain near the initial highest score.

[0079] This anomaly handling mechanism ensures that the scoring system can still operate stably in the event of network fluctuations or incomplete data initialization, and will not cause the entire score calculation process to be interrupted due to arithmetic anomalies.

[0080] In step S204, the real-time problem-solving ratio coefficient r, after normalization and anomaly calibration, is used as the sole independent variable and passed to the nonlinear mapping stage in the subsequent step S3 to reflect the dynamic change in the difficulty of the competition problem as the number of people who solve it increases.

[0081] Used to reflect the dynamic changes in the difficulty of the competition problem as the number of people who solve it increases. Since r has been strictly limited to a closed interval between 0 and 1 and has undergone division by zero protection, the subsequent nonlinear mapping function can always receive a valid and legal input value, ensuring the computability and stability of the score decay model.

[0082] Regarding the present invention, step S3 involves constructing a decay model based on the sigmoid growth curve, the specific implementation process of which is as follows: Step S301: In this invention, the logistic regression function is introduced as the core mathematical model for score decay. The logistic regression function is an S-shaped sigmoid growth curve, in which the function value gradually increases from 0 to 1 as the independent variable increases, passing through a rapidly rising transition zone in the middle.

[0083] By using the pre-set steepness coefficient k and offset inflection point parameter μ, a nonlinear mapping is performed on the real-time problem-solving ratio coefficient r calculated in step S2 to calculate the attenuation coefficient f(r) within the preset value range of 0 to 1.

[0084] The attenuation coefficient f(r) means that when f(r) is close to 0, it means that the score should be maintained at a high level and has not yet been significantly attenuated; when f(r) is close to 1, it means that the score has been attenuated to a low level. The entire mapping process transforms the problem-solving ratio into a smooth nonlinear attenuation factor.

[0085] Step S302: The steepness coefficient k is used to control the degree of drastic decrease in score. The larger the value of k, the steeper the slope of the logistic regression curve near the inflection point, and the faster the score decreases; the smaller the value of k, the flatter the curve, and the slower the score decreases. Its value range is set between 5 and 50. The lower limit of 5 corresponds to a very flat score decrease curve, and the upper limit of 50 corresponds to a steep score decrease curve close to a step function.

[0086] The offset inflection point parameter μ is used to determine the critical point where the score decreases the fastest, which is the symmetrical center point of the logistic regression sigmoid growth curve. At r=μ, the slope of the curve is the largest, and the rate of score decrease reaches its peak. The value of the offset inflection point parameter μ is usually set between 0.05 and 0.25. The lower limit of 0.05 means that the score starts to decrease rapidly when only 5% of the teams solve the problem, and the upper limit of 0.25 means that the score will only enter the rapid decline channel when the proportion of teams that solve the problem reaches 25%.

[0087] The smaller the μ value, the shorter the protection period for high-ranking scores and the earlier the score decay begins; the larger the μ value, the longer the protection period for high-ranking scores and the longer the advantage of the team that solves the problem first is maintained.

[0088] Step S303, the attenuation coefficient f(r) is calculated based on the negative exponent of the natural constant base e, and the specific calculation formula is as follows:

[0089] Where e is the natural constant, k is the steepness coefficient, r is the real-time problem-solving ratio coefficient, and μ is the offset inflection point parameter.

[0090] In step S304, in this mathematical model, the logistic regression function, through its sigmoid growth physical characteristic, exhibits extremely slow growth when the real-time problem-solving ratio coefficient r is within the range of 0 to μ. This means that when the problem-solving ratio gradually increases from 0 but has not yet reached the offset inflection point parameter μ, the decay coefficient f(r) remains close to 0, and the dynamic score correspondingly remains close to the initial maximum score.

[0091] This feature provides a high-level protection period for the first and top solvers in the early stages of the competition, ensuring that the basic value of the problem does not depreciate rapidly due to the solution by a few teams, thus encouraging participating teams to prioritize tackling the more difficult problems.

[0092] In step S305, when the real-time problem-solving ratio coefficient r approaches the offset inflection point parameter μ, the slope of the logistic regression function reaches its maximum value, generating a rapid decay gradient. At this time, for every unit increase in the problem-solving ratio, the increment of the decay coefficient f(r) increases significantly, and the dynamic score decreases rapidly.

[0093] This rapid decay phase reflects the rapid spread of the perceived difficulty of the problem after a certain percentage of participants have solved it. In other words, once enough participating teams have mastered the solution to the problem, its differentiating power gradually decreases, and subsequent solvers should no longer receive similar score rewards to those who solved it earlier.

[0094] Step S306: When the real-time problem-solving ratio coefficient r exceeds the offset inflection point parameter μ and gradually moves away from it, the logistic regression function enters the asymptotic region, and its slope gradually decreases and approaches zero, producing a stable long-tail effect. At this time, even if the problem-solving ratio continues to increase, the decay coefficient f(r) only approaches 1 by a very small amount, the rate of decrease of the dynamic score slows down and eventually converges to the minimum guaranteed score.

[0095] This long-tail effect ensures that the competition retains a basic score range even after the majority of teams have solved the problems, preventing the scores from dropping to zero. At the same time, it prevents the scores of teams solving problems in the middle and later stages from being excessively lowered due to a large number of subsequent solutions, thus maintaining a reasonable level of differentiation.

[0096] The differentiated configuration of the steepness coefficient and the offset inflection point parameter in step S3 of this invention is specifically implemented as follows: Step S307: This invention pre-sets different steepness coefficients k for competition questions of different difficulty levels. The value of the steepness coefficient k determines the steepness of the score decay curve. The larger the value of k, the steeper the decay curve is near the inflection point, and the faster the score decreases; the smaller the value of k, the flatter the decay curve, and the slower the score decreases. The specific configuration method is as follows: For the first category of difficulty problems, including basic Web problems, miscellaneous Misc problems, and relatively easy Reverse engineering problems, the steepness coefficient k is set within the first preset value range of 10 to 15. These problems are usually solved by a large number of people who are evenly distributed. Using a smaller k value can create a smoother score reduction trajectory, so that the score decreases gradually during the problem-solving process, avoiding excessive fluctuations in score that could affect the competition experience.

[0097] For the second category of challenges, including Pwn-type binary vulnerability exploitation challenges, Crypto-type deep cryptographic analysis challenges, and high-difficulty challenges in the Reverse engineering category, the steepness coefficient k is set within the second preset value range of 25 to 40. These challenges have a high technical threshold and usually demonstrate extremely high technical value when solved by a very small number of participating teams.

[0098] Using a larger k value can make the score decay curve very steep near the inflection point. Once the number of people who solve the problem increases slightly, the dynamic score will drop rapidly, thus preventing later participating teams from obtaining disproportionately high scores compared to those who solved the problem earlier through collaboration or information sharing. This ensures that the score distribution of high-difficulty problems can truly reflect the differences in the technical level of each team.

[0099] Thus, the above steps completed the differentiated configuration of steepness coefficients for competition questions of different difficulty levels. By adjusting the steepness of the score reduction curve, the score decay rate of basic and high-difficulty questions was matched with their actual challenge level.

[0100] In step S308, the present invention dynamically adjusts the offset inflection point parameter μ according to the expected scale of the event and the average ability level of the participants.

[0101] In large-scale competitions at the provincial level or above, the offset inflection point parameter μ is set at around 0.1.

[0102] In small-scale training matches at the school or enterprise level, the offset inflection point parameter μ is adjusted to around 0.2.

[0103] In step S309, the offset inflection point parameter μ is controlled within a preset proportional threshold range. That is, when the number of people solving the problem reaches a specific proportional range of the total number of people, the dynamic score of the competition enters a rapid decay phase.

[0104] Specifically, the value of μ determines the starting position of the rapid decline in score, and the purpose of setting the proportional threshold range is to control the triggering time of the rapid decay phase.

[0105] When the μ value is small, for example, set to 0.05, it means that when the proportion of teams solving the problem reaches 5%, the dynamic score of the competition enters a rapid decline channel, and the score decay starts earlier; when the μ value is large, for example, set to 0.25, it means that when the proportion of teams solving the problem reaches 25%, the score begins to decline rapidly, and the high score protection period is longer.

[0106] By adjusting the specific value of μ within the preset threshold range of 0.05 to 0.25, sufficient score advantage period can be reserved for the top contestants, allowing those who solve the problem first to obtain higher score rewards. At the same time, the scoring rhythm of the middle and later contestants can be scientifically constrained to prevent their scores from falling into the low convergence range too early.

[0107] For this invention, step S4, mapping dynamic scores, is specifically implemented as follows: Step S401, the present invention sets the initial maximum score S for the competition question. max and the minimum guaranteed score S min The initial highest score S max Set at 1000 points, with a minimum guaranteed score of S. min Set to 100 points.

[0108] Step S402: Apply the attenuation coefficient f(r) calculated in step 3 to the initial maximum score S. max With the minimum guaranteed score S min The difference interval is used to calculate the instantaneous dynamic score S using a linear transformation formula. current The specific calculation formula is as follows: ; Where S current S is a real-time dynamic score. min To guarantee the minimum score, S max Let f(r) be the initial maximum score, and f(r) be the attenuation coefficient calculated in step 3.

[0109] Step S403: Under this linear transformation logic, when the attenuation coefficient f(r) approaches the preset minimum value 0, the instantaneous dynamic score S... current Approaching the initial maximum score S max .

[0110] When the attenuation coefficient f(r) approaches the preset maximum value of 1, the instantaneous dynamic score S current Converging to the minimum guaranteed score S min .

[0111] Step S404: By setting the above interval, it is ensured that the competition problem still retains a basic score space after a large number of participating teams have solved it, so as to avoid the score from dropping to zero. The minimum score of 100 points ensures that even if all participating teams solve the competition problem, the solver can still receive a certain score reward, thereby maintaining the enthusiasm of participating teams to continue solving the problem.

[0112] In step S405, the mapping calculation process is completed in the floating-point arithmetic unit, and the final calculation result is converted into an integer score by rounding up.

[0113] The score obtained after the calculation may contain a decimal part. For example, if the calculation result is 823.456 points, this invention calls the rounding function to perform an up-rounding operation on the floating-point number, that is, regardless of the size of the decimal part, it is rounded to positive infinity. After rounding up, 823.456 points becomes 824 points, ensuring that the final score presented to the participating teams is an integer.

[0114] The reason for rounding up instead of rounding to the nearest whole number is to avoid situations where the score difference between the first and second solvers becomes too small or even reverses due to discarding the decimal part. Rounding up can slightly increase the score advantage of the first solver.

[0115] For this invention, step S5, synchronously updating the score record, is implemented as follows: Step S501: When the backend monitoring module detects a new correct flag string submission behavior that causes a change in the solution count variable n, a full update mechanism is triggered.

[0116] Specifically, after the backend monitoring module learns of a successful submission through the message queue consumption process in step S102, it immediately obtains the updated solution count variable n corresponding to the competition problem. The backend monitoring module then determines whether the value of n has increased compared to the solution count when the dynamic score of the competition problem was calculated last time.

[0117] If the value of n increases, it means that a new participating team has solved the problem, and the real-time dynamic score of the problem needs to be recalculated because the problem-solving ratio coefficient r=n / N has changed. If the value of n does not change, for example, due to duplicate submission or verification failure, the update will not be triggered.

[0118] In step S502, the dynamic score calculation engine immediately re-executes steps S201 to S204, steps S301 to S306, and steps S401 to S405 to recalculate the real-time dynamic score of the affected problem under the current problem-solving scale.

[0119] The recalculation is performed strictly in the order described above: first, calculate the problem-solving ratio coefficient r based on the current n and N; then, calculate the decay coefficient f(r) based on the logistic regression function; and finally, calculate the new real-time dynamic score based on the linear mapping formula.

[0120] The entire recalculation process is completed within the same transaction context, ensuring that no new commit requests will be responded to before the calculation is completed, thus avoiding race conditions that could cause the score calculation order to be disordered.

[0121] Once the calculation is complete, the new dynamic score will be used for the synchronized update of team scores in subsequent steps S503 to S506.

[0122] Step S503, the full update mechanism includes transactional operations on the score association table in the database. The score association table is used to store the score records of each participating team on each competition question. The table contains fields such as team identifier, competition question identifier, score value and submission timestamp.

[0123] When the score of a certain problem decreases by a predetermined amount, the calculation engine of this invention uses a batch processing statement to uniformly and synchronously adjust the scores of all participating teams that have solved the problem. The batch processing statement uses the UPDATE command of the structured query language to update all records that meet the conditions at once. Its WHERE condition is set to the problem identifier being equal to the current problem and the score being equal to the old score. The SET clause updates the score to the new score.

[0124] The predetermined range refers to the difference between the old and new scores. Since the dynamic score decreases monotonically as the proportion of questions solved increases, the magnitude of each decrease depends on the size of the increase in the proportion of questions solved, which may range from a few points to several tens of points.

[0125] In step S504, the database management system uses the ACID transaction properties to ensure the consistency of score updates. ACID is an abbreviation for Atomicity, Consistency, Isolation and Durability. Atomicity ensures that score update operations either all succeed or none fail, and there will be no situation where some records are updated successfully while others fail.

[0126] Isolation guarantees that during the score update process, other concurrent query requests will not read data in the intermediate state. Durability guarantees that once the update is committed, the data is permanently saved.

[0127] Specifically, before executing the batch UPDATE statement, the computing engine first starts a database transaction. After executing the update operation, it checks whether the number of affected rows matches the expected number of teams that have solved the problem. If they match, the transaction is committed to make the update effective. If an error occurs or the number of affected rows does not match, the transaction is rolled back, restoring the database to the state before the update. That is, either all participating teams that have solved the problem will have their corresponding score difference deducted at the same time, or all will be rolled back to the state before the update.

[0128] In step S505, the score update action simultaneously triggers the leaderboard re-ranking algorithm. The leaderboard re-ranking algorithm runs automatically after each score update, recalculates the total score of all participating teams, and generates a new ranking order from high to low based on the total score. This re-ranking algorithm introduces a time weight factor as the basis for tie-breaking.

[0129] The time weight factor is numerically equal to the timestamp of the last correct flag string submitted by each participating team. This timestamp has been recorded in the message body of step S101. When multiple participating teams have the same total score, the leaderboard re-ranking algorithm prioritizes comparing the timestamps of each team. The team with the smaller timestamp value indicates that it completed the last correct submission earlier and ranks higher in the leaderboard.

[0130] This mechanism ensures that in the event of multiple teams having the same score due to dynamic score adjustments, the team that solves the problem first can still maintain its ranking advantage and will not lose its first-mover advantage due to synchronized score adjustments.

[0131] Step S506: When multiple participating teams have the same total score, the leaderboard re-ranking algorithm prioritizes sorting by the timestamp of the last correct flag string submitted by each participating team. Specifically, after calculating the total score of all teams, the leaderboard re-ranking algorithm first sorts them from highest to lowest total score, with the team with the highest total score at the top.

[0132] When two or more teams have the same total score, the algorithm no longer relies on the total score for differentiation, but instead switches to the second sorting dimension, which is to compare the timestamp of each team's last correct flag string submission. This timestamp comes from the submission timestamp recorded in the message body of step S101, with an accuracy of milliseconds. The smaller the timestamp value, the earlier the team completed its last correct submission.

[0133] This application ranks teams with smaller timestamps before teams with larger timestamps. If two teams have the same total score and the timestamp of their last submission is also exactly the same, they are further sorted according to the lexicographical order of their team unique identifiers to ensure that the ranking is deterministic and unique.

[0134] Using the above sorting rules, the leaderboard re-ranking algorithm generates the final ranking list and updates the ranking results in real time to the competition's front-end interface for participants to view.

[0135] The specific implementation process of the abnormal problem-solving behavior monitoring steps of this invention is as follows: Step S601: The backend monitoring module of the present invention analyzes the rate of change of the real-time problem-solving ratio coefficient r over time, i.e., calculates dr / dt. This rate of change reflects how fast the problem-solving ratio coefficient increases per unit time. A positive value indicates that the problem-solving ratio is increasing, a negative value indicates that the problem-solving ratio is decreasing, and the larger the absolute value, the more drastic the change. In step S602, the backend monitoring module compares the change amplitude Δr within the preset monitoring time period with the preset ratio threshold. The preset monitoring time period is set to 5 minutes, and the preset ratio threshold is set to 0.05. The 5-minute time window is determined based on the time scale of normal problem-solving behavior in cybersecurity competitions and the sensitivity requirements for anomaly detection.

[0136] Historical data shows that the normal problem-solving diffusion process usually completes the major changes within 10 to 30 minutes. A 5-minute window can capture significant changes in the problem-solving ratio, while avoiding the detection sluggishness caused by an excessively long window or the misjudgment of normal fluctuations caused by an excessively short window.

[0137] Furthermore, this window effectively balances detection sensitivity and false alarm rate in practical applications, and has been verified as an optimal value through multiple tests. At the same time, the 5-minute window has good adaptability to questions of different difficulty levels. It will not produce false alarms for normal solutions to high-difficulty questions due to being too short, nor will it miss abnormal behavior in basic questions due to being too long.

[0138] The 0.05 percentage point threshold, or 5 percentage points change in the problem-solving rate, was determined based on statistical analysis of normal problem-solving speed and the boundary between abnormal and normal speeds. Based on statistical analysis of historical data from multiple cybersecurity competitions, the conclusion is that the percentage of people who can solve a problem within 5 minutes usually increases by no more than 5 percentage points under normal circumstances. This conclusion is derived from statistical regression analysis of dozens of competitions and thousands of problems.

[0139] When the success rate of solving problems increases by more than 5 percentage points within 5 minutes, it indicates an abnormally rapid increase in problem-solving speed. Combined with other monitoring factors such as IP address aggregation, this can accurately distinguish suspected cheating behavior from normal problem-solving spread. The 5 percentage point threshold can effectively exclude normal fluctuations while also detecting abnormally accelerated behavior.

[0140] This threshold is a relative proportion, independent of the total number of participating teams, and therefore applicable to competitions of different sizes. Whether it's a small competition with a few hundred participants or a large competition with tens of thousands, a 5 percentage point change in the problem-solving ratio has the same statistical significance, ensuring the universality and portability of the monitoring method.

[0141] Step S603: When the change range Δr of the real-time problem-solving ratio coefficient r exceeds the preset ratio threshold of 0.05 within a preset monitoring time period of 5 minutes, and the backend monitoring module detects that there is no significant external traffic inflow within the corresponding time period, the present invention automatically determines it as a suspected flag string leakage or abnormal collusion behavior.

[0142] In step S604, the backend monitoring module pushes an immediate warning signal to the administrator terminal via the WebSocket real-time communication protocol, indicating abnormal problem-solving behavior. WebSocket is a full-duplex communication protocol that can establish a persistent connection between the client and the server, and supports the server to actively push messages to the client. Compared with the traditional HTTP polling method, it has lower latency.

[0143] After identifying suspected abnormal behavior, the backend monitoring module constructs a JSON-formatted alert message containing the competition problem identifier, the time of the anomaly, the current problem-solving ratio coefficient r, and the change range Δr. The alert message is then sent to all logged-in administrator terminals via a WebSocket connection.

[0144] After receiving the message, the administrator terminal displays the warning content in the form of a pop-up window or notification bar and issues an audio prompt to ensure that the warning information is delivered to the administrator within milliseconds.

[0145] In step S605, the backend monitoring module automatically marks the suspected abnormal competition question as an abnormal state in the management backend, and executes the score locking command to temporarily freeze the score update logic of the competition question. That is, a status field is added to the competition question information table in the database. Under normal conditions, the value of this field is 0, and under abnormal conditions, the value of this field is set to 1.

[0146] The score locking instruction is implemented by setting a lock flag in memory, which is bound to the competition question identifier. When the lock flag is true, the full update mechanism in step S501, after determining that the competition question is in a locked state, directly skips the score recalculation process in step S502, and all subsequent correct submissions for the competition question will no longer trigger score changes.

[0147] Once locked, the score for the problem remains at the value before the anomaly occurred, and the scores of teams that have solved the problem on the leaderboard also remain unchanged.

[0148] Step S606: The frozen problem score remains at the previous score state before the anomaly occurred and will not change with the submission of new solutions until the administrator completes manual review and unlocks the problem. After receiving the warning signal, the administrator logs into the management backend to view the anomaly details, including the specific information of the solution record and the IP address aggregation. After manual review confirms whether there is flag leakage or collusion, the administrator clicks the unlock button through the management backend interface.

[0149] Upon receiving the release command, this application will restore the status field of the competition information table in the database to 0, clear the lock flag in memory, and restore the normal score update logic for the competition. If manual review confirms cheating, the administrator can choose to maintain the lock or manually adjust the scores of the relevant teams before releasing the lock. The specific implementation process of the historical difficulty fitting step for this invention is as follows: Step S701: Establish a structured database containing more than 100 historical problem-solving records, store the problem-solving ratio change curves of similar types of problems in previous competitions and the distribution data of participating players. The problem-solving ratio change curves record the proportion of the number of teams that have solved the problem to the total number of active teams at different time points from the first time the problem is solved, and are sampled once per minute.

[0150] The database uses MySQL or PostgreSQL, and the table structure includes fields such as competition identifier, competition type, solution ratio time series, timestamp, and competition scale.

[0151] Step S702: Utilize a Long Short-Term Memory (LSTM) neural network to perform deep feature extraction and difficulty modeling on historical data. The input layer receives four features: the category to which the competition belongs is encoded using one-hot encoding (Web category is 1, 0, 0, 0); the size of the competition attachments is normalized to kilobytes; the number of lines of code in the competition is normalized; and the preset difficulty level is an integer from 1 to 5.

[0152] The neural network consists of an input layer, two LSTM hidden layers, and an output layer. The first hidden layer has 64 LSTM units, and the second hidden layer has 32 LSTM units. Each LSTM unit contains three gating structures: a forget gate, an input gate, and an output gate.

[0153] The forget gate uses the sigmoid function to determine the proportion of the cell state from the previous time step to be retained, the input gate controls the amount of current input information added to the cell state, and the output gate determines the proportion of the current cell state output to the hidden state.

[0154] In step S703, the three gates work together to selectively remember or forget information from different time steps, extracting deep feature patterns from the changing problem-solving ratios of different difficulty problems.

[0155] When the output value of the forget gate is close to 1, more historical information is retained, which is suitable for basic problems with a slow change in the proportion of solutions. When the output value is close to 0, historical information is discarded, which is suitable for high-difficulty problems with a drastic change in the proportion of solutions. The proportion of solutions to basic problems shows an exponential growth pattern of rapid increase followed by saturation, while the proportion of solutions to high-difficulty problems shows a step-like pattern of slow rise after a long period of low plateau.

[0156] The output layer of the neural network outputs the predicted steepness coefficient k and the offset inflection point parameter μ, which are used for initialization of new competition problems.

[0157] Step S704: The output layer of the long short-term memory neural network outputs the recommended steepness coefficient k and offset inflection point parameter μ. The output layer adopts a fully connected layer structure with 2 neurons, which correspond to the two output values ​​of steepness coefficient k and offset inflection point parameter μ, respectively.

[0158] The output layer uses a linear activation function and does not restrict the range of output values. However, when using it later, k will be limited to a reasonable range of 5 to 50, and μ will be limited to a reasonable range of 0.05 to 0.25. The steepness coefficient k is used to control the degree of decline of the dynamic score decay curve of the new question. The larger the value of k, the steeper the curve and the faster the score decreases. The offset inflection point parameter μ is used to determine the trigger ratio critical point of rapid score decay of the new question. The smaller the value of μ, the earlier the score decay starts.

[0159] During training, the network learns a non-linear mapping from input features to optimal parameters by minimizing the mean squared error loss function between the predicted output and the true label. The formula for calculating the mean squared error loss function is as follows: ; Where M is the total number of training samples, i is the sample index, and k is the number of training samples. i and μ i The true label value of the sample represents the optimal parameters used in the actual competition for this problem. and The predicted value output by the neural network is L. During training, the neural network continuously adjusts the network weights through the backpropagation algorithm, so that the loss function L gradually decreases and converges to the minimum value.

[0160] In step S705, the present invention uses the neural network model trained above to automatically recommend initial settings for the steepness coefficient k and the offset inflection point parameter μ for newly created competition problems, thereby reducing the human experience error of the competition organizer in the parameter configuration process.

[0161] When creating a new competition problem, the competition organizer inputs feature values ​​such as the category of the problem, the size of the problem attachments, the number of lines of code in the problem, and the preset difficulty level. The system normalizes these feature values ​​and inputs them into a pre-trained long short-term memory neural network. After forward propagation, the network outputs recommended values ​​of k and μ.

[0162] Organizers can accept the recommended value directly or make fine adjustments based on actual needs. This automatic recommendation mechanism enables organizers without extensive experience to configure reasonable dynamic score decay parameters for competition questions, lowering the threshold for parameter configuration while ensuring the consistency of score decay patterns across different competition questions.

[0163] The specific implementation process of the score display steps for this invention is as follows: Step S801: In the competition front-end interface, the present invention displays the score change trend of each question in real time through a dynamic curve graph. The dynamic curve graph is rendered using Canvas technology or SVG scalable vector graphics technology. Canvas technology dynamically draws graphics through scripts, which is suitable for scenarios with frequent data updates. SVG technology is based on XML to describe vector graphics, and does not lose quality when scaled, making it suitable for chart displays that require interactive operations.

[0164] The horizontal axis of the dynamic curve represents the number of people who solved the problem or the proportion of people who solved the problem, ranging from 0 to the total number of participating teams or the proportion of 1; the vertical axis represents the dynamic score, ranging from the minimum guaranteed score of 100 points to the initial maximum score of 1000 points.

[0165] Step S802: The horizontal axis position corresponding to the current number of solutions variable n is marked in real time in the dynamic curve graph, so that the contestants can intuitively understand the position of the number of people who have solved the current problem in the overall score decay curve. When the value of n changes, the front-end interface obtains the current value of n and the corresponding dynamic score from the back-end through an asynchronous request, and marks the coordinate point on the curve graph with a highlighted dot or a vertical reference line.

[0166] The x-axis of the marker represents the number of people solving the problem (n) or the percentage of people solving the problem (r = n / N), and the y-axis represents the current real-time dynamic score (S). current As the value of n increases, the marker point moves to the right along the curve, and the contestants can clearly observe the dynamic process of the score decreasing as the number of people solving the problem increases.

[0167] In step S803, through the dynamic curve graph, the contestants can predict the expected score gain of the problem after submitting the correct flag string, as well as the potential for subsequent score reduction due to the increase in the number of solvers. When the contestant hovers the mouse over any position to the right of the current mark point on the curve graph, the front-end interface automatically displays the corresponding score and solving ratio at that position.

[0168] Based on this, contestants can determine how many points they can get if they submit the correct flag string now; and how low the scores of subsequent solvers will drop after the problem is solved by more teams.

[0169] This visualization mechanism enhances the game-like nature of the competition, allowing participants to dynamically adjust their problem-solving strategies based on the current score trends, prioritizing the tackle of problems that still have high point values. The engineering deployment architecture and ultra-large-scale concurrent processing of this invention are specifically implemented as follows: Step S901: In a specific engineering deployment, this method is applied to a distributed network security competition system.

[0170] The architecture of this distributed network security competition system includes a load balancing layer, an application logic layer, and a data persistence layer. The load balancing layer uses Nginx to distribute requests. Nginx distributes a large number of concurrent submissions from participating teams to multiple application server instances in the backend according to the load balancing strategy, avoiding single point of overload.

[0171] The application logic layer uses a dynamic score calculation engine written in Go. Go has high concurrency processing capabilities and low memory consumption, making it suitable for handling intensive calculation tasks in competition scenarios.

[0172] The data persistence layer uses a MySQL master-slave cluster to store business data. The master database is responsible for handling write operations, and the slave database is responsible for handling read operations, thereby distributing the database pressure. At the same time, Redis is used to store the computation intermediate state. Redis, as an in-memory database, provides sub-millisecond read and write latency.

[0173] In step S902, the dynamic score calculation engine is deployed in the application logic layer. It obtains real-time ratio data through direct interaction with the high-speed cache database Redis, limiting the computational complexity to the O(1) level and ensuring system stability in high-concurrency submission scenarios.

[0174] The computational complexity of O(1) means that no matter how the number of participating teams increases, the time required to calculate the score each time remains constant and will not increase linearly with the increase in the number of participants or the number of problems solved.

[0175] In terms of specific implementation, each time the computing engine executes steps S201 to S204, S301 to S306, and S401 to S405, it only needs to read the n and N values ​​stored in Redis and perform a fixed number of arithmetic operations. The entire process does not involve complex database queries or traversal operations, thus maintaining a stable response time in high-concurrency scenarios.

[0176] In step S903, when collecting real-time competition data, in order to cope with ultra-large-scale concurrency, the backend monitoring module is divided into a data capture submodule and a statistical aggregation submodule. The data capture submodule is deployed in multiple container instances and is responsible for the initial filtering and verification of the submission requests from participating teams in different geographical locations or network shards.

[0177] Each container instance runs independently, sharing statelessly with each other, and requests are distributed across the instances via a load balancer. After receiving the flag strings submitted by the participating teams, the data capture submodule first performs format validation, checking whether the flag strings meet the expected length and character set specifications, filtering out obviously invalid submission requests, and reducing unnecessary load in subsequent processing stages.

[0178] Requests that pass the initial verification are marked with a receiving timestamp and then forwarded to the statistics aggregation submodule for further processing.

[0179] In step S904, the data capture submodule adds a unified timestamp to the verified messages and sends them to the statistics aggregation submodule.

[0180] The statistical aggregation submodule uses a distributed lock mechanism to incrementally accumulate the value of the global solution count variable n.

[0181] Step S905: The above-mentioned hierarchical processing mode can support more than 10,000 participating teams to submit flag strings online at the same time.

[0182] By employing multi-instance deployment and a distributed lock mechanism, the system was able to handle submissions from over 10,000 teams simultaneously online, providing reliable technical support for the engineering application of dynamic score calculation methods in large-scale cybersecurity competitions.

[0183] The specific implementation process of this invention, including the sprint-stage calibration operator, the offset inflection point linkage mechanism based on question scores, and the cross-platform fixed-point decimal algorithm, is as follows: In step S1001, the present invention adds a calibration operator when calculating the problem-solving ratio coefficient r.

[0184] When the competition enters the final 30-minute sprint or leaderboard sealing period, the total base variable N is locked to the instantaneous value at the leaderboard sealing moment, and no longer fluctuates with the activation of zombie accounts, thus ensuring the absolute stability of the scoring logic during the sprint phase.

[0185] The trigger conditions for the sprint period or the closing period are automatically determined by the competition system based on the preset competition timeline. The system has a "competition duration" parameter in the background management configuration. When the remaining competition time is less than or equal to 30 minutes, the system automatically activates the sprint period calibration operator.

[0186] Meanwhile, the system also supports manually triggering the leaderboard closure mode. Competition administrators can switch the competition status to leaderboard closure with one click through the operation interface. At this time, regardless of how much time is left, it is considered to have entered the sprint period, and the total base variable N is immediately locked.

[0187] The preset duration of 30 minutes for the start of the sprint phase is determined based on the rhythm characteristics of cybersecurity competitions and the analysis of participant behavior.

[0188] In most cybersecurity competitions, the last 30 minutes are the period when participating teams submit a backlog of flags, resulting in the most dramatic fluctuations in the leaderboard. Statistics show that over 65% of score changes occur in the last 30 minutes of the competition. If the total base variable N is allowed to fluctuate due to new team activations during this stage, it will lead to inaccurate calculation of the solution ratio coefficient r, giving teams submitting later an unreasonable score advantage and undermining the fairness of the competition.

[0189] Therefore, setting 30 minutes as the threshold can effectively ensure the fairness of the ranking in the sprint stage without affecting the stability of the scoring in the early stages. This duration can also be configured by the competition organizers according to the scale of the event. For example, in a very large-scale competition, it can be appropriately extended to 45 minutes or 60 minutes. The above step S1001, by locking the total base variable during the sprint period, avoids interference from the problem-solving ratio coefficient caused by fluctuations in invalid accounts, thus ensuring the stability and fairness of scoring in the later stages of the competition.

[0190] In step S1002, when constructing the attenuation model, this invention introduces a linkage mechanism based on the question score for setting the offset inflection point parameter μ.

[0191] When the initial highest score S max If the score exceeds 2000, this invention determines that the competition question is an extremely difficult question.

[0192] In step S1003, under the aforementioned extremely difficult problem, the present invention automatically moves the offset inflection point parameter μ to the left, that is, reduces the value of the offset inflection point parameter μ.

[0193] This ensures that even if only a very small number of participating teams solve the problem, such as when only 2% of the total participating teams solve it, the dynamic score of the problem will begin to decrease slowly. This is to prevent the score from remaining at an extremely high level for a long period of time, which would lead to an overflow of points for those who solve the problem later.

[0194] In step S1004, for the score mapping step, the present invention adopts a fixed-point decimal algorithm to ensure the consistency of accuracy in cross-platform calculation.

[0195] Due to differences in floating-point number processing logic across different operating systems, such as the implementation differences of the IEEE 754 standard, slight deviations in scores may occur. In this invention, before performing the formula calculation, all scores are multiplied by 1000 to convert them into fixed-point integers, and after the calculation is completed, they are divided by 1000 and rounded down.

[0196] Through the above step S1004, the present invention eliminates the impact of differences in floating-point arithmetic precision between different platforms on the score calculation results, ensuring the consistency of score calculation across platforms.

[0197] The specific implementation process of this invention, including the sprint-stage calibration operator, the offset inflection point linkage mechanism based on question scores, and the cross-platform fixed-point decimal algorithm, is as follows: In step S1001, the present invention adds a calibration operator when calculating the problem-solving ratio coefficient r.

[0198] When the competition enters the final 30-minute sprint or leaderboard sealing period, the total base variable N is locked to the instantaneous value at the leaderboard sealing moment, and no longer fluctuates with the activation of zombie accounts, thus ensuring the absolute stability of the scoring logic during the sprint phase.

[0199] The above step S1001, by locking the total base variable during the sprint period, avoids interference from the problem-solving ratio coefficient caused by fluctuations in invalid accounts, thus ensuring the stability and fairness of scoring in the later stages of the competition.

[0200] In step S1002, when constructing the attenuation model, this invention introduces a linkage mechanism based on the question score for setting the offset inflection point parameter μ.

[0201] When the initial highest score S max If the score exceeds 2000, this invention determines that the competition question is an extremely difficult question.

[0202] In step S1003, under the aforementioned extremely difficult problem, the present invention automatically moves the offset inflection point parameter μ to the left, that is, reduces the value of the offset inflection point parameter μ.

[0203] This ensures that even if only a very small number of participating teams solve the problem, such as when only 2% of the total participating teams solve it, the dynamic score of the problem will begin to decrease slowly. This is to prevent the score from remaining at an extremely high level for a long period of time, which would lead to an overflow of points for those who solve the problem later.

[0204] In step S1004, for the score mapping step, the present invention adopts a fixed-point decimal algorithm to ensure the consistency of accuracy in cross-platform calculation.

[0205] Due to differences in floating-point number processing logic across different operating systems, such as the implementation differences of the IEEE 754 standard, slight deviations in scores may occur. In this invention, before performing the formula calculation, all scores are multiplied by 1000 to convert them into fixed-point integers, and after the calculation is completed, they are divided by 1000 and rounded down.

[0206] Through the above step S1004, the present invention eliminates the impact of differences in floating-point arithmetic precision between different platforms on the score calculation results, ensuring the consistency of score calculation across platforms.

[0207] The specific implementation process of this invention, including the sprint-stage calibration operator, the offset inflection point linkage mechanism based on question scores, and the cross-platform fixed-point decimal algorithm, is as follows: In step S1001, the present invention adds a calibration operator when calculating the problem-solving ratio coefficient r.

[0208] When the competition enters the final 30-minute sprint or leaderboard sealing period, the total base variable N is locked to the instantaneous value at the leaderboard sealing moment, and no longer fluctuates with the activation of zombie accounts, thus ensuring the absolute stability of the scoring logic during the sprint phase.

[0209] The above step S1001, by locking the total base variable during the sprint period, avoids interference from the problem-solving ratio coefficient caused by fluctuations in invalid accounts, thus ensuring the stability and fairness of scoring in the later stages of the competition.

[0210] In step S1002, when constructing the attenuation model, this invention introduces a linkage mechanism based on the question score for setting the offset inflection point parameter μ.

[0211] When the initial highest score S max If the score exceeds 2000, this invention determines that the competition question is an extremely difficult question.

[0212] In step S1003, under the aforementioned extremely difficult problem, the present invention automatically moves the offset inflection point parameter μ to the left, that is, reduces the value of the offset inflection point parameter μ.

[0213] This ensures that even if only a very small number of participating teams solve the problem, such as when only 2% of the total participating teams solve it, the dynamic score of the problem will begin to decrease slowly. This is to prevent the score from remaining at an extremely high level for a long period of time, which would lead to an overflow of points for those who solve the problem later.

[0214] In step S1004, for the score mapping step, the present invention adopts a fixed-point decimal algorithm to ensure the consistency of accuracy in cross-platform calculation.

[0215] Due to differences in floating-point number processing logic across different operating systems, such as the implementation differences of the IEEE 754 standard, slight deviations in scores may occur. In this invention, before performing the formula calculation, all scores are multiplied by 1000 to convert them into fixed-point integers, and after the calculation is completed, they are divided by 1000 and rounded down.

[0216] Through the above step S1004, the present invention eliminates the impact of differences in floating-point arithmetic precision between different platforms on the score calculation results, ensuring the consistency of score calculation across platforms.

[0217] The specific implementation process of the dynamic score calculation method for cybersecurity competitions based on the problem-solving ratio disclosed in this invention, including its incremental update and full alignment persistence strategy and abnormal behavior monitoring based on IP address geographical features, is as follows: In step S1101, the present invention employs a strategy that combines incremental updates and full alignment when synchronously updating score records.

[0218] Whenever the number of solutions n increases by 1, the calculation engine of this invention calculates the current real-time dynamic score S. current Dynamic score S of the previous state old The difference ΔS, where ΔS = S current -S old .

[0219] In step S1102, the present invention first writes the difference ΔS to the question score hash table in the Redis cache to complete the incremental update operation. The Redis hash table uses the question identifier as the field name and the cumulative score change of the question as the field value.

[0220] Incremental updates only write the score change caused by the increase in the number of people who solved the problem, without overwriting or modifying the team's score details. Therefore, the write operation is very lightweight, with a latency of less than 1 millisecond. When the front-end leaderboard is displayed, the cumulative change of each problem is first read from Redis, and then the current total score is calculated by combining it with the benchmark value in MySQL.

[0221] Step S1103: Then, a low-priority background coroutine is started to asynchronously synchronize the incremental update results to the score details table in the MySQL database. The background coroutine is executed when system resources are idle, without affecting the score calculation and leaderboard refresh speed of the main process. During synchronization, a batch write method is used, accumulating multiple incremental records and then submitting them to MySQL at once to reduce the number of database interactions.

[0222] If network jitter or database unavailability occurs during synchronization, the coroutine will automatically retry until the data is successfully written, ensuring that incremental updates are not lost in the end.

[0223] In step S1104, during abnormal behavior monitoring, this invention not only analyzes the rate of change of the real-time problem-solving ratio coefficient r (dr / dt), but also combines the geographical characteristics of the contestants' IP addresses for comprehensive judgment. The geographical characteristics of the IP addresses include the network segment to which the IP belongs, the geographical location, and the number of teams that solved the same problem within the same subnet. This application identifies teams with the same first three segments of their IP addresses by parsing the source IP address of the requests submitted by the participating teams, and classifies them into the same subnet group.

[0224] Step S1105: When a large number of participating teams that solve the same problem within a short period of time have their IP addresses concentrated in the same subnet, and the time interval between solving the problem is less than the shortest expected logical time Min for that problem. Time When this occurs, the present invention automatically places the batch of problem-solving records into a queue to be verified, with a minimum expected logical time of Min. Time This refers to the shortest reasonable time required for a normal participating team to read the problem, analyze it, write a solution script, and submit the correct flag. The Min time varies depending on the type of problem.Time Unlike other types of challenges, basic Web-related questions are typically given 60 seconds, while advanced Pwn-related questions are given 300 seconds.

[0225] For basic Web-related questions, Min Time The time limit is usually set at 60 seconds, based on the following considerations: Web-related basic questions typically test common vulnerability types, such as SQL injection, command injection, file upload, and simple cross-site scripting attacks.

[0226] For a participant with basic cybersecurity skills, the solution process includes: opening the challenge webpage takes about 5 to 10 seconds; manually inputting or using tools such as Burp Suite to make simple parameter modifications and tests takes about 20 to 30 seconds; after verifying the existence of the vulnerability, writing a script or directly using a tool to submit the flag takes about 10 seconds; and the entire process can be completed in 45 to 60 seconds if all goes smoothly.

[0227] Therefore, using 60 seconds as a threshold can cover most normal problem-solving behaviors. If a team submits continuously within a time interval far less than 60 seconds, such as multiple teams submitting the correct Flag within 20 seconds, there is a high probability of Flag sharing or group cheating, because even automated scripts need a basic response and processing time from obtaining problem information to completing the attack.

[0228] For high-difficulty Pwn-type problems, Min Time The time limit is usually set at 300 seconds, based on the following considerations: Pwn challenges mainly test the ability to exploit binary vulnerabilities, involving complex techniques such as reverse engineering, stack overflow, heap overflow, and format strings.

[0229] The normal solution process takes much longer than the Web challenge. Participants first need to use decompilation tools such as IDA Pro to perform static analysis on the binary file, which usually takes 60 to 120 seconds. Then, they need to use dynamic debugging tools such as gdb to verify the triggering conditions and controllability of the vulnerability, which takes about 60 to 120 seconds. Next, they need to write an exploit script, which involves the precise construction of return addresses, stack layouts, ROP chains, etc., which takes about 60 to 120 seconds. Finally, they need to perform multiple debugging sessions and the final exploit, which takes about 30 seconds.

[0230] A skilled participant, under ideal circumstances, typically needs 180 to 300 seconds to complete all the above steps. Therefore, setting 300 seconds as the threshold effectively identifies cheating. If the time interval between solutions is significantly shorter than this value, such as multiple teams submitting within 10 seconds, it indicates that the Flag may have been leaked or that multiple people have colluded. The system will temporarily store such suspicious submissions for further investigation, thus effectively maintaining the fairness of the competition. If the time interval between solving problems is shorter than this threshold, it indicates that there may be flag sharing or group cheating.

[0231] In step S1106, the problem-solving records in the above-mentioned queue to be verified are not immediately included in the number of solutions variable n. At the same time, the delayed effect mechanism of score update is triggered. This application temporarily stores these suspicious problem-solving records in an independent data table to be verified and marks them as pending review.

[0232] Before the review is completed, these records are not included in the count range of the n value, so the recalculation of scores in steps S501 to S502 will not be triggered. On the front-end leaderboard, the scores of these teams are not displayed or are displayed as pending review.

[0233] In step S1107, the delayed activation mechanism continues to run until the multi-factor risk control model provides a safety assessment, at which point the batch of problem-solving records will be officially included in the n value and the score update will be triggered.

[0234] The multi-factor risk control model comprehensively considers three dimensions: the time interval between problem solving, the degree of IP address clustering, and the historical submission behavior pattern. It calculates a risk score for each batch of problem solving records in the queue to be verified, with the score range from 0 to 100.

[0235] Problem Solving Time Interval Factor: The system counts the time interval between adjacent correct submissions of the same problem, calculates the average interval, and compares it with the shortest expected logic time threshold corresponding to the problem. The shorter the average interval, the higher the score.

[0236] IP Address Clustering Factor: The system resolves the source IP address and groups teams with the same first three segments of the IP address into the same subnet group. It calculates the proportion of teams from the same subnet that solved the problem out of the total number of teams that solved the problem. The higher the proportion, the higher the score.

[0237] Historical Submission Behavior Pattern Factor: The system records the historical behavior profile of each team, including submission success rate, number of attempts per problem, and submission time distribution. The current submission behavior is compared with the historical pattern, and the greater the deviation, the higher the score.

[0238] The risk score uses a weighted summation formula: Risk Score = 0.4 × Time Interval Factor Score + 0.35 × IP Aggregation Factor Score + 0.25 × Historical Behavior Factor Score. The weighting coefficients are determined through statistical analysis of historical cheating case data.

[0239] The system presets a security threshold of 60 points. When the risk score is below 60 points, the model outputs a security evaluation, and the system transfers the problem-solving records in the queue to the formal problem-solving record table. The value of n increases by the corresponding number, triggering a recalculation of the score. When the risk score reaches or exceeds 60 points, the model outputs a risk evaluation, the system marks abnormal behavior, and pushes an alert to the administrator terminal for manual review via WebSocket.

[0240] The system periodically adds manually verified cheating cases to the training dataset, recalculates the weight coefficients, and enables adaptive model updates.

[0241] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0242] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for calculating dynamic scores in cybersecurity competitions based on the proportion of questions solved, characterized in that, Includes the following steps: S1. Capture the competition problem Flag submission records of participating teams through the message queue, call the preset Flag verification service to determine the correctness of the submission records, and retrieve the solution count variable n and the total number of problems N for each problem in real time. The total number of problems N is the total number of active teams in the current competition whose status field is marked as active and whose login count records have reached at least 2. S2. Based on the number of solutions variable n and the total base variable N, calculate the ratio of the number of solutions variable n to the total base variable N as the solution ratio coefficient. Use the solution ratio coefficient as the core driving factor for score decay. Construct a score decay model using an exponential function with the natural constant as the base. The score decay model uses the solution ratio coefficient as the input variable and the steepness coefficient and offset inflection point parameter as model adjustment parameters, and outputs the score decay coefficient. S3. Set the value of the steepness coefficient according to the difficulty level of the competition question. Set the first steepness coefficient value range for basic difficulty competition questions and the second steepness coefficient value range for high difficulty competition questions. Configure the offset inflection point parameter according to the initial score of the competition question. S4. Multiply the score decay coefficient by the initial score of the question to calculate the real-time dynamic score of the question, and display the score change trend of each question in real time through a dynamic curve in the front-end interface of the competition. S5. Periodically perform a global activity scan to count the number of currently active teams, and dynamically adjust the refresh frequency of the total base variable N based on the number of active teams.

2. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: In step S3, the minimum value of the first steepness coefficient range is not less than 10 and the maximum value is not greater than 15, and the minimum value of the second steepness coefficient range is not less than 25 and the maximum value is not greater than 40. The numerical range of the offset inflection point parameter mentioned in step S2 is a minimum value of not less than 0.05 and a maximum value of not greater than 0.25; When the initial maximum score of a problem exceeds the preset threshold of 2000 points, the system automatically reduces the value of the offset inflection point parameter, so that the score enters the decay stage at a lower problem-solving ratio.

3. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: It also includes a parameter intelligent prediction step: A parameter prediction model is constructed using a long short-term memory neural network. The input layer of the long short-term memory neural network includes the category to which the competition question belongs, the size of the competition question attachments, the number of lines of code for the competition question, and the preset difficulty level. The category to which the competition question belongs is encoded using one-hot encoding. The size of the competition question attachments is normalized in kilobytes. The number of lines of code for the competition question is normalized. The preset difficulty level is an integer from 1 to 5. The output layer of the long short-term memory neural network outputs the predicted steepness coefficient and offset inflection point parameter; The Long Short-Term Memory Neural Network uses the historical problem-solving ratio curves and the distribution data of the participants as training datasets for model training.

4. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: In step S4, when calculating the real-time dynamic score, a cross-platform fixed-point decimal algorithm is used to expand the score to an integer multiple before performing the calculation and then restore the original dimension, thereby eliminating the score calculation deviation caused by the difference in floating-point arithmetic between different operating systems. After the mapping calculation process is completed, the rounding function is called to perform an up-rounding operation on the calculation result, ensuring that the team that solves the problem first maintains a scoring advantage over the team that solves the problem later.

5. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: It also includes the steps for sorting by equal parts: When multiple teams have the same total score, a time weight factor is introduced as the ranking basis. The time weight factor is calculated based on the timestamp of the team's last correct Flag submission. The team with the earlier timestamp receives a higher ranking weight, ensuring that the team that solves the problem first has a ranking advantage in the case of a tie.

6. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: It also includes steps for monitoring abnormal problem-solving behavior: The system analyzes the rate of change of the solution ratio for each problem relative to time in real time. When the change in the solution ratio exceeds the preset 0.05 ratio threshold within a preset 5-minute monitoring period, the system triggers an abnormal behavior warning. By analyzing the source IP address of the submitted requests from participating teams, we can identify concentrated submission behavior under the same subnet. When the time interval between solving problems is lower than the minimum expected logical time threshold corresponding to the problem, the corresponding batch of problem-solving records will be temporarily stored in the queue to be verified. They will not be immediately included in the number of solutions variable n. They will be officially included and the score will be updated after the multi-factor risk control model completes the security evaluation. The minimum expected logical time threshold is configured differently according to the type of competition question. It is set to 60 seconds for basic Web questions and 300 seconds for high-difficulty Pwn questions.

7. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: The periodic execution of global activity scanning in step S5 is a preset fixed duration. When the competition enters the final 30-minute sprint phase, the sprint calibration operator is activated to lock the value of the total base variable N. Teams newly submitted during the sprint phase are no longer included in the total base variable N, ensuring the stability of the scoring logic during the sprint phase.

8. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 6, characterized in that: The multi-factor risk control model integrates three dimensions—solving time interval, IP address clustering degree, and historical submission behavior pattern—to calculate a risk score for each batch of solving records in the queue to be verified. The weight coefficient of the solving time interval factor is 0.4, the weight coefficient of the IP address clustering degree factor is 0.35, and the weight coefficient of the historical submission behavior pattern factor is 0.

25. When the risk score is lower than the preset safety threshold of 60 points, a safety evaluation is output, the problem-solving records in the queue to be checked are transferred to the formal problem-solving record table and the score is updated; when the risk score is higher than the preset safety threshold of 60 points, it is marked as abnormal behavior and an early warning signal is pushed to the administrator terminal.

9. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio as described in claim 1, characterized in that: The calculation results of the real-time dynamic score adopt a persistence strategy that combines incremental updates and full alignment: When a score changes, the difference is first written to the question score hash table in the Redis cache to complete the incremental update operation. A scheduled task synchronizes the incremental update results in Redis to the relational database in batches at fixed time intervals. The leaderboard query interface reads the real-time score from Redis first. The database is used for historical data archiving and final score calculation.

10. The method for calculating dynamic scores in cybersecurity competitions based on the problem-solving ratio according to claim 1, characterized in that: The message queue adopts a distributed message queue system to achieve high-concurrency capture and peak shaving of submission records; The backend monitoring module adopts a layered processing architecture, including a data capture submodule and a statistical aggregation submodule deployed in multiple container instances. The data capture submodule is responsible for initially filtering and verifying the requests submitted by participating teams from different geographical locations, and forwarding the verified messages to the statistical aggregation submodule. The statistical aggregation submodule uses a distributed lock mechanism to incrementally accumulate the global solution count variable n. The hierarchical processing architecture supports more than 10,000 participating teams submitting flag strings online simultaneously.

Images