A data sharing system and method based on smart contracts

Abstract

The present invention discloses a data sharing system and method based on smart contracts, which relates to the field of computer application technology. This solution realizes dynamic risk prevention and control and self-optimization closed loop of data sharing through deep integration of smart contracts and real-time monitoring. By real-time collection of call frequency, response time, number of failures and user address, a three-dimensional feature vector is constructed, and low / medium / high risk levels are dynamically determined in combination with a preset rule base; user authorization parameters are automatically adjusted according to the risk level, and current limiting / fuse instructions are generated. The data gateway limits high-risk user requests or switches to backup nodes in real time; historical data is regularly analyzed to dynamically update the risk judgment benchmark value and proportional coefficient, the rule base is optimized and stored on the chain, and it is ensured that the strategy continues to adapt to changes in system load. This solution significantly improves data sharing security, system stability and resource utilization, and provides an efficient and intelligent risk prevention and control solution for distributed data sharing.

Description

Technical Field

[0001] The present invention relates to the field of computer application technology, and in particular to a data sharing system and method based on smart contracts. Background Art

[0002] In distributed data sharing scenarios, traditional data sharing systems generally use static permission configuration and single-indicator risk assessment solutions, which are difficult to adapt to dynamically changing security needs. Existing methods mainly rely on preset thresholds and manual rules to determine the risk of user behavior, which has the following significant flaws:

[0003] First, real-time risk response capabilities are insufficient. Traditional systems use preset call frequency thresholds for permission control, but are unable to detect abnormal changes in user behavior (such as sudden high-frequency requests or response delays) in real time, leading to service overload or data leakage risks.

[0004] Secondly, risk assessment is limited in scope. Existing solutions often assess risk based on a single metric, such as call frequency, while ignoring the combined impact of key dimensions like call failure rate and response time distribution. For example, if the call frequency of an interface does not exceed the threshold, but the continuous failure rate increases abnormally, traditional methods cannot identify this stability risk, leading to misjudgments or missed detections and reducing the accuracy of risk prevention and control.

[0005] Furthermore, the policy adjustment mechanism lags behind. Risk assessment rules rely on manual optimization of threshold parameters, which is time-consuming and difficult to adapt to changes in system load. For example, when the system experiences brief performance fluctuations during peak hours, the time required to manually adjust rules lags behind real-time requirements, resulting in delays in rule updates and implementation, impacting risk prevention and control effectiveness.

[0006] Finally, the service recovery mechanism is simplistic and crude. Circuit-breaking policies often rely on fixed durations, without dynamically evaluating the actual recovery effect. For example, if the interface response time hasn't returned to normal after the circuit-breaking period expires, traditional methods still remove the circuit-breaking mechanism, potentially leading to false service recovery or secondary failures, impacting system stability.

[0007] Furthermore, traditional systems lack closed-loop analysis of historical policy execution results, making it difficult to continuously optimize risk assessment rules. For example, the failure to integrate historical call behavior data with policy execution records prevents the rule base from dynamically evolving based on actual scenarios, leading to a gradual weakening of risk prevention and control capabilities after long-term operation.

[0008] In summary, the existing data sharing system has significant deficiencies in dynamic risk identification, multi-dimensional assessment, real-time policy adjustment, and intelligent recovery mechanisms, making it difficult to meet the security, stability, and efficiency requirements of data sharing in a distributed environment.

[0009] To solve the above problems, the present invention proposes a data sharing system and method based on smart contracts, which provides an innovative solution for risk prevention and control of data sharing systems. Summary of the Invention

[0010] The purpose of the present invention is to provide a data sharing system and method based on smart contracts to solve the problems raised in the prior art.

[0011] To achieve the above object, the present invention provides the following technical solutions:

[0012] A data sharing method based on a smart contract, comprising the following steps:

[0013] S1. Deploy a monitoring module on the data sharing platform node to continuously collect behavioral data on user interface calls, including call frequency, response time, error frequency, and user identity;

[0014] S2. Perform statistical analysis on the behavior data to generate characteristic vectors of the distribution of call volume per unit time, continuous failure rate, and response time;

[0015] S3. Mapping the feature vector to a risk level according to a preset rule, where the risk level is divided into three levels: low, medium, and high;

[0016] S4. When the risk level is detected as medium or high, the smart contract automatically adjusts the user authorization parameters, including the query limit and validity period, and sends a circuit breaker instruction to the data gateway;

[0017] S5. The data gateway limits concurrent requests from high-risk users or suspends specific interface services in real time according to the circuit breaker instructions.

[0018] S6. Extract historical data, regularly analyze historical strategy execution records, and optimize the preset rules.

[0019] The step S1 further comprises the following steps:

[0020] S1.1: Install a monitoring agent program on each service node of the data sharing platform and establish a communication link with the platform core system through a standardized interface;

[0021] S1.2: Collect four types of structured data: call frequency, average response time, number of consecutive failures, and user blockchain address. The call frequency refers to the number of successful interface calls per unit time. The average response time refers to the arithmetic mean of the response times of all successful requests. The consecutive failure count refers to the number of consecutive calls that failed to return valid data. When a call returns an HTTP status code other than 200, the count is incremented by 1 and reset to 0 upon successful call. The user blockchain address refers to a 40-digit hexadecimal string that conforms to the address specification.

[0022] S1.3: Adopt adaptive sampling rate and dynamically adjust the collection frequency according to the platform load; specifically: take the initial reference value as the unit time data collection frequency to form a fixed-size data block; when the interface response time of the service node exceeds the preset high threshold, the sampling rate is reduced to the first proportion of the basic sampling rate; when the interface response time of the service node is lower than the preset low threshold, the sampling rate is increased to the second proportion of the basic sampling rate; and the sampling rate adjustment range is limited to between the third proportion and the fourth proportion of the basic sampling rate; the preset high / low threshold is the interface response time critical value pre-set according to the system resource load, the first / second proportion represents the proportional coefficient of the sampling rate adjustment, and the third / fourth proportion represents the minimum and maximum limit proportions of the sampling rate.

[0023] The step S2 further comprises the following steps:

[0024] S2.1: Divide historical data into analysis periods of a preset fixed length, generating independent data units for each period;

[0025] S2.2: Calculate statistical indicators based on the call frequency, average response time, and number of consecutive failures collected in step S1. The statistical indicators are divided into call frequency C, call failure rate R, and response time percentile F. The call frequency C directly uses the call frequency data collected in S1. The call failure rate R refers to the ratio of call failures to the total number of calls during the analysis period. The calculation formula is as follows:

[0026] ;

[0027] The number of failed calls is the cumulative value of the consecutive failures collected by S1, and the total number of calls is the sum of the number of successful calls and the number of failed calls;

[0028] The response time percentile F is a specific percentile value of the response time of all successful calls in the analysis period. Specifically, all successful call response times in the analysis period are sorted in ascending order to obtain the array t = [t1, t2, ..., t n ], and then calculate the position index k of the Xth percentile, the formula is as follows:

[0029] ;

[0030] Where X is the preset percentile threshold, and n is the number of successful calls. Based on the calculation of the k value, the response time percentile F is the value of the kth position in the array t.

[0031] S2.3: Based on the calculated statistical indicators, construct a three-dimensional feature vector V = [C, F, R] to comprehensively reflect the call frequency, stability, and response efficiency.

[0032] The step S3 further comprises the following steps:

[0033] S3.1: Based on the three-dimensional feature vector V, a multi-condition combination logic is established to obtain a three-level risk determination rule base. The rules are as follows:

[0034] Low risk: C ≤ reference value × P1 and F ≤ T1 and R ≤ reference value × P2;

[0035] Medium risk: C>baseline value×P1 or F>T1 or R>baseline value×P2;

[0036] High risk: C>baseline value×P3 and F>T2 and R>baseline value×P4;

[0037] Among them, P1, P2, P3, and P4 are preset proportional coefficients, and T1 and T2 are preset failure rate thresholds;

[0038] S3.2: Based on the four types of structured data collected in step S1.2, use them as the historical data set, select data that aligns with the current analysis cycle, and sort the filtered historical data by the three indicators of call frequency, call failure rate, and response time percentile. Calculate the Qth percentile, which means that Q% of the historical data is less than or equal to this value. The calculation formula is:

[0039] ;

[0040] Where n is the number of samples of historical data, and Q is a configurable parameter;

[0041] The benchmark value is updated and calculated according to the preset time period every day to update the benchmark value parameters in the rule base. When the benchmark value is updated, all risk assessment rules that rely on the benchmark value are automatically adjusted according to the change in the benchmark value.

[0042] S3.3: Acquire the feature vector V in real time, and determine whether it meets the high risk, medium risk, and low risk conditions in sequence according to the above steps, and then determine a unique risk level; in addition, when the feature vector meets multiple level conditions at the same time, it is prioritized as high risk.

[0043] The step S4 further comprises the following steps:

[0044] S4.1: The smart contract obtains the risk level information output in step S3 in real time through the data exchange channel established with the oracle interface, and encapsulates the risk level information in the data returned by the oracle in the form of a data structure. The smart contract then parses the returned data format according to the data protocol built into the oracle. This protocol clearly defines the data encoding method, field order, and data type.

[0045] S4.2: The smart contract adjusts the authorization parameters based on the received risk level and pre-set policy logic. The authorization parameter adjustment is divided into two parts: the daily query limit and the authorization validity period.

[0046] The calculation formula for adjusting the daily query limit is as follows:

[0047] ;

[0048] The average query volume for the same period in history is the average of the same period in the past 7 days, obtained from the historical records stored in the blockchain;

[0049] The calculation formula for adjusting the authorization validity period is as follows:

[0050] ;

[0051] The risk level coefficient is calculated by collecting historical data of similar risk events in the past 30 days, extracting the actual effect indicators of authorization parameter adjustments, and using a linear regression algorithm to establish a mapping relationship between risk levels and historical average adjustment effects. The formula for calculating the risk level coefficient is as follows:

[0052] ;

[0053] For the establishment of the linear regression model, the three risk levels of low, medium, and high are used as input variables, with preset values ​​of 0, 1, and 2 respectively. The historical average adjustment effect is the output variable. The coefficients a and b are obtained by fitting the historical data of the past 30 days through the least squares method. The calculation formula of the historical average adjustment effect is as follows:

[0054] Historical average adjustment effect = a × risk level + b;

[0055] The benchmark adjustment effect is the average of all historical adjustment effects, and the risk level weight is predefined by the risk level rule library;

[0056] S4.3: The smart contract generates corresponding circuit breakers based on the risk level. For medium risk levels, a flow limiter is generated to limit the number of concurrent interface requests. For high risk levels, a circuit breaker is generated to suspend the interface service and enable a backup node. The concurrency limit calculation formula in the flow limiter is as follows:

[0057] ;

[0058] The historical average concurrency refers to the historical data stored in the blockchain, which is the average number of concurrent interface requests in the same time period over the past seven days. It is calculated based on the call frequency and average response time collected by S1.

[0059] The calculation formula for the circuit breaker duration in a circuit breaker instruction is as follows:

[0060] ;

[0061] The historical average recovery time is the average repair time for similar failures in the past 30 days, obtained through historical blockchain data;

[0062] For the current limiting instruction recovery, it will be automatically released when the interface call success rate is ≥ the preset success rate threshold for 5 consecutive minutes. For the circuit breaker instruction recovery, it will be released when the following conditions are met at the same time:

[0063] The call success rate is ≥ the preset success rate threshold for 5 consecutive minutes;

[0064] Response time ≤ 1x the reference value × the preset response time multiple;

[0065] The benchmark value 1 of this part is the average response time during the same period in history, and its calculation formula is:

[0066] ;

[0067] Where m is the number of successful calls in the same period of history;

[0068] S4.4: The smart contract triggers its own event mechanism to send a message containing a circuit breaker instruction to the monitoring module of the data gateway.

[0069] The step S5 further comprises the following steps:

[0070] S5.1: The data gateway obtains the circuit breaker instructions generated by S4 in real time by monitoring smart contract events. The instructions include circuit breaker type, threshold parameters, and recovery conditions. Circuit breaker types include current limiting and circuit breaking; threshold parameters include concurrency limit and circuit breaking duration; recovery conditions include success rate threshold and response time multiplier.

[0071] S5.2: For medium-risk level rate limiting operations, dynamically adjust the interface's request processing strategy based on the concurrency limit in the rate limiting instruction. Specifically, use a token bucket algorithm to control the number of concurrent requests, ensuring that the number of requests per second does not exceed the threshold, and return a smart contract status code for requests that exceed the concurrency limit.

[0072] S5.3: For high-risk circuit breaker operations, the service of the faulty interface is suspended, the status code of the smart contract is returned, and then the service node is automatically switched to the backup service node, and the request is routed to the available node through the load balancing mechanism;

[0073] S5.4: For monitoring of recovery conditions, continuously monitor the call success rate and response time of the interface; for flow control scenarios, when the call success rate is ≥ the preset threshold for 5 consecutive minutes, gradually restore the concurrency limit according to the 10% standard; for circuit breaker scenarios, after the circuit breaker period expires, if the conditions described in step S4.3 are met at the same time, release the circuit breaker and restore the master node service.

[0074] The step S6 further comprises the following steps:

[0075] S6.1: Obtain policy execution records from the blockchain for the past 30 days, including the risk level determination results from step S3, the authorization parameter adjustment records and circuit breaker instruction execution logs from step S4, and the rate limiting / circuit breaking operation records from step S5. Simultaneously extract the user behavior data collected in step S1 and the feature vector generated in step S2 as input for policy effectiveness analysis.

[0076] S6.2: For strategy effectiveness evaluation, compare the system error rate and response time before and after strategy execution. If the error rate decreases and the response time decreases, the risk control is considered effective.

[0077] S6.3: For rule base optimization logic, if the proportion of risk events exceeds the preset threshold for seven consecutive days, the current baseline value is determined to be too high and needs to be lowered to improve risk identification sensitivity;

[0078] If the frequency of high-risk event triggering is lower than the preset threshold, the current baseline value is judged to be too low and needs to be adjusted upward to reduce excessive response;

[0079] S6.4: Write the optimized benchmark value and proportional coefficient into the configuration table of the blockchain smart contract, and trigger the automatic update process of the S3 rule base. The new rules are updated within the preset time period every day.

[0080] A data sharing system based on smart contracts includes a monitoring module, a feature extraction module, a risk assessment module, a smart contract module, a data gateway module and a policy optimization module; the monitoring module is responsible for collecting call frequency, response time, number of failures and user blockchain address in real time, dynamically adjusting the sampling rate and transmitting data to the feature extraction module; the feature extraction module slices historical data according to a preset period, calculates the percentiles of call frequency, failure rate and response time, and generates a three-dimensional feature vector for risk assessment; the risk assessment module matches a preset rule base based on the three-dimensional feature vector, dynamically updates the benchmark value and determines a unique risk level in real time; after receiving the risk level, the smart contract module automatically adjusts the authorization parameters, generates a circuit breaker instruction and transmits it to the data gateway; the data gateway module listens to and verifies the circuit breaker instruction, executes concurrent flow limiting or service circuit breaking, and gradually restores service after continuously monitoring the recovery conditions; the policy optimization module is used to analyze historical execution records and user behavior data, dynamically adjust the risk determination benchmark value and proportional coefficient, optimize the rule base and store it on the chain.

[0081] Compared with the prior art, the present invention has the following beneficial effects:

[0082] 1. Improve data sharing security: Smart contracts automatically limit high-risk user permissions to prevent data abuse and malicious attacks; the circuit breaker mechanism effectively isolates faulty interfaces to prevent single-point failures from spreading to the entire system.

[0083] 2. Enhance system stability: Dynamically adjust the sampling rate and concurrency limit to balance data collection accuracy and system resource usage; combine recovery conditions to ensure that performance meets standards after service restoration and reduce the probability of secondary failures.

[0084] 3. Achieve closed-loop optimization: The strategy optimization module continuously improves the rule base based on historical data to enhance long-term risk prevention and control capabilities; blockchain evidence storage ensures that strategy execution is traceable and meets data compliance requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Figure 1 This is a flow chart of a data sharing method based on smart contracts in the present invention;

[0086] Figure 2 This is a data flow diagram between modules of a data sharing system based on smart contracts in the present invention. DETAILED DESCRIPTION

[0087] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0088] Example: Figure 1-Figure 2 As shown, the present invention provides a technical solution.

[0089] A data sharing method based on smart contracts, such as Figure 1 As shown, the following steps are included:

[0090] S1. Deploy a monitoring module on the data sharing platform node to continuously collect behavioral data on user interface calls, including call frequency, response time, error frequency, and user identity;

[0091] S2. Perform statistical analysis on the behavior data to generate characteristic vectors of the distribution of call volume per unit time, continuous failure rate, and response time;

[0092] S3. Mapping the feature vector to a risk level according to a preset rule, where the risk level is divided into three levels: low, medium, and high;

[0093] S4. When the risk level is detected as medium or high, the smart contract automatically adjusts the user authorization parameters, including the query limit and validity period, and sends a circuit breaker instruction to the data gateway;

[0094] S5. The data gateway limits concurrent requests from high-risk users or suspends specific interface services in real time according to the circuit breaker instructions.

[0095] S6. Extract historical data, regularly analyze historical strategy execution records, and optimize the preset rules.

[0096] The step S1 further comprises the following steps:

[0097] S1.1: Install a monitoring agent program on each service node of the data sharing platform and establish a communication link with the platform core system through a standardized interface;

[0098] S1.2: Collect four types of structured data: call frequency, average response time, number of consecutive failures, and user blockchain address. The call frequency refers to the number of successful interface calls per unit time. The average response time refers to the arithmetic mean of the response times of all successful requests. The consecutive failure count refers to the number of consecutive calls that failed to return valid data. When a call returns an HTTP status code other than 200, the count is incremented by 1 and reset to 0 upon successful call. The user blockchain address refers to a 40-digit hexadecimal string that conforms to the address specification.

[0099] S1.3: Adopt adaptive sampling rate and dynamically adjust the collection frequency according to the platform load; specifically: take the initial reference value as the unit time data collection frequency to form a fixed-size data block; when the interface response time of the service node exceeds the preset high threshold, the sampling rate is reduced to the first proportion of the basic sampling rate; when the interface response time of the service node is lower than the preset low threshold, the sampling rate is increased to the second proportion of the basic sampling rate; and the sampling rate adjustment range is limited to between the third proportion and the fourth proportion of the basic sampling rate; the preset high / low threshold is the interface response time critical value pre-set according to the system resource load, the first / second proportion represents the proportional coefficient of the sampling rate adjustment, and the third / fourth proportion represents the minimum and maximum limit proportions of the sampling rate.

[0100] The step S2 further comprises the following steps:

[0101] S2.1: Divide historical data into analysis periods of a preset fixed length, generating independent data units for each period;

[0102] S2.2: Calculate statistical indicators based on the call frequency, average response time, and number of consecutive failures collected in step S1. The statistical indicators are divided into call frequency C, call failure rate R, and response time percentile F. The call frequency C directly uses the call frequency data collected in S1. The call failure rate R refers to the ratio of call failures to the total number of calls during the analysis period. The calculation formula is as follows:

[0103] ;

[0104] The number of failed calls is the cumulative value of the consecutive failures collected by S1, and the total number of calls is the sum of the number of successful calls and the number of failed calls;

[0105] The response time percentile F is a specific percentile value of the response time of all successful calls in the analysis period. Specifically, all successful call response times in the analysis period are sorted in ascending order to obtain the array t = [t1, t2, ..., t n ], and then calculate the position index k of the Xth percentile, the formula is as follows:

[0106] ;

[0107] Where X is the preset percentile threshold, and n is the number of successful calls. Based on the calculation of the k value, the response time percentile F is the value of the kth position in the array t.

[0108] S2.3: Based on the calculated statistical indicators, construct a three-dimensional feature vector V = [C, F, R] to comprehensively reflect the call frequency, stability, and response efficiency.

[0109] The step S3 further comprises the following steps:

[0110] S3.1: Based on the three-dimensional feature vector V, a multi-condition combination logic is established to obtain a three-level risk determination rule base. The rules are as follows:

[0111] Low risk: C ≤ reference value × P1 and F ≤ T1 and R ≤ reference value × P2;

[0112] Medium risk: C>baseline value×P1 or F>T1 or R>baseline value×P2;

[0113] High risk: C>baseline value×P3 and F>T2 and R>baseline value×P4;

[0114] Among them, P1, P2, P3, and P4 are preset proportional coefficients, and T1 and T2 are preset failure rate thresholds;

[0115] S3.2: Based on the four types of structured data collected in step S1.2, use them as the historical data set, select data that aligns with the current analysis cycle, and sort the filtered historical data by the three indicators of call frequency, call failure rate, and response time percentile. Calculate the Qth percentile, which means that Q% of the historical data is less than or equal to this value. The calculation formula is:

[0116] ;

[0117] Where n is the number of samples of historical data, and Q is a configurable parameter;

[0118] The benchmark value is updated and calculated according to the preset time period every day to update the benchmark value parameters in the rule base. When the benchmark value is updated, all risk assessment rules that rely on the benchmark value are automatically adjusted according to the change in the benchmark value.

[0119] S3.3: Acquire the feature vector V in real time, and determine whether it meets the high risk, medium risk, and low risk conditions in sequence according to the above steps, and then determine a unique risk level; in addition, when the feature vector meets multiple level conditions at the same time, it is prioritized as high risk.

[0120] The step S4 further comprises the following steps:

[0121] S4.1: The smart contract obtains the risk level information output in step S3 in real time through the data exchange channel established with the oracle interface, and encapsulates the risk level information in the data returned by the oracle in the form of a data structure. The smart contract then parses the returned data format according to the data protocol built into the oracle. This protocol clearly defines the data encoding method, field order, and data type.

[0122] S4.2: The smart contract adjusts the authorization parameters based on the received risk level and pre-set policy logic. The authorization parameter adjustment is divided into two parts: the daily query limit and the authorization validity period.

[0123] The calculation formula for adjusting the daily query limit is as follows:

[0124] ;

[0125] The average query volume for the same period in history is the average of the same period in the past 7 days, obtained from the historical records stored in the blockchain;

[0126] The calculation formula for adjusting the authorization validity period is as follows:

[0127] ;

[0128] The risk level coefficient is calculated by collecting historical data of similar risk events in the past 30 days, extracting the actual effect indicators of authorization parameter adjustments, and using a linear regression algorithm to establish a mapping relationship between risk levels and historical average adjustment effects. The formula for calculating the risk level coefficient is as follows:

[0129] ;

[0130] For the establishment of the linear regression model, the three risk levels of low, medium, and high are used as input variables, with preset values ​​of 0, 1, and 2 respectively. The historical average adjustment effect is the output variable. The coefficients a and b are obtained by fitting the historical data of the past 30 days through the least squares method. The calculation formula of the historical average adjustment effect is as follows:

[0131] Historical average adjustment effect = a × risk level + b;

[0132] The benchmark adjustment effect is the average of all historical adjustment effects, and the risk level weight is predefined by the risk level rule library;

[0133] S4.3: The smart contract generates corresponding circuit breakers based on the risk level. For medium risk levels, a flow limiter is generated to limit the number of concurrent interface requests. For high risk levels, a circuit breaker is generated to suspend the interface service and enable a backup node. The concurrency limit calculation formula in the flow limiter is as follows:

[0134] ;

[0135] The historical average concurrency refers to the historical data stored in the blockchain, which is the average number of concurrent interface requests in the same time period over the past seven days. It is calculated based on the call frequency and average response time collected by S1.

[0136] The calculation formula for the circuit breaker duration in a circuit breaker instruction is as follows:

[0137] ;

[0138] The historical average recovery time is the average repair time for similar failures in the past 30 days, obtained through historical blockchain data;

[0139] For the current limiting instruction recovery, it will be automatically released when the interface call success rate is ≥ the preset success rate threshold for 5 consecutive minutes. For the circuit breaker instruction recovery, it will be released when the following conditions are met at the same time:

[0140] The call success rate is ≥ the preset success rate threshold for 5 consecutive minutes;

[0141] Response time ≤ 1x the reference value × the preset response time multiple;

[0142] The benchmark value 1 of this part is the average response time during the same period in history, and its calculation formula is:

[0143] ;

[0144] Where m is the number of successful calls in the same period of history;

[0145] S4.4: The smart contract triggers its own event mechanism to send a message containing a circuit breaker instruction to the monitoring module of the data gateway.

[0146] The step S5 further comprises the following steps:

[0147] S5.1: The data gateway obtains the circuit breaker instructions generated by S4 in real time by monitoring smart contract events. The instructions include circuit breaker type, threshold parameters, and recovery conditions. Circuit breaker types include current limiting and circuit breaking; threshold parameters include concurrency limit and circuit breaking duration; recovery conditions include success rate threshold and response time multiplier.

[0148] S5.2: For medium-risk level rate limiting operations, dynamically adjust the interface's request processing strategy based on the concurrency limit in the rate limiting instruction. Specifically, use a token bucket algorithm to control the number of concurrent requests, ensuring that the number of requests per second does not exceed the threshold, and return a smart contract status code for requests that exceed the concurrency limit.

[0149] S5.3: For high-risk circuit breaker operations, the service of the faulty interface is suspended, the status code of the smart contract is returned, and then the service node is automatically switched to the backup service node, and the request is routed to the available node through the load balancing mechanism;

[0150] S5.4: For monitoring of recovery conditions, continuously monitor the call success rate and response time of the interface; for flow control scenarios, when the call success rate is ≥ the preset threshold for 5 consecutive minutes, gradually restore the concurrency limit according to the 10% standard; for circuit breaker scenarios, after the circuit breaker period expires, if the conditions described in step S4.3 are met at the same time, release the circuit breaker and restore the master node service.

[0151] The step S6 further comprises the following steps:

[0152] S6.1: Obtain policy execution records from the blockchain for the past 30 days, including the risk level determination results from step S3, the authorization parameter adjustment records and circuit breaker instruction execution logs from step S4, and the rate limiting / circuit breaking operation records from step S5. Simultaneously extract the user behavior data collected in step S1 and the feature vector generated in step S2 as input for policy effectiveness analysis.

[0153] S6.2: For strategy effectiveness evaluation, compare the system error rate and response time before and after strategy execution. If the error rate decreases and the response time decreases, the risk control is considered effective.

[0154] S6.3: For rule base optimization logic, if the proportion of risk events exceeds the preset threshold for seven consecutive days, the current baseline value is determined to be too high and needs to be lowered to improve risk identification sensitivity;

[0155] If the frequency of high-risk event triggering is lower than the preset threshold, the current baseline value is judged to be too low and needs to be adjusted upward to reduce excessive response;

[0156] S6.4: Write the optimized benchmark value and proportional coefficient into the configuration table of the blockchain smart contract, and trigger the automatic update process of the S3 rule base. The new rules are updated within the preset time period every day.

[0157] A data sharing system based on smart contracts, including a monitoring module, a feature extraction module, a risk assessment module, a smart contract module, a data gateway module and a strategy optimization module; the monitoring module is responsible for collecting call frequency, response time, number of failures and user blockchain address in real time, dynamically adjusting the sampling rate and transmitting data to the feature extraction module; the feature extraction module slices historical data according to a preset period, calculates the call frequency, failure rate and response time percentile, and generates a three-dimensional feature vector for risk assessment; the risk assessment module matches the preset rule library based on the three-dimensional feature vector, dynamically updates the benchmark value and determines the unique risk level in real time; the smart contract module automatically adjusts the authorization parameters after receiving the risk level, generates a circuit breaker instruction and transmits it to the data gateway; the data gateway module listens to and verifies the circuit breaker instruction, executes concurrent flow limiting or service circuit breaker, and gradually restores the service after continuously monitoring the recovery conditions; the strategy optimization module is used to analyze historical execution records and user behavior data, dynamically adjust the risk determination benchmark value and proportional coefficient, optimize the rule library and store it on the chain; Figure 2 shown. Example

[0158] In a data sharing platform, the monitoring module deploys active-active monitoring agents on service nodes and establishes a communication link with the core system through a standardized gRPC interface. Assume that within a 5-minute analysis cycle, divided into 5 scenarios, the following data is collected:

[0159] Normal call scenario: Within a 5-minute period, there are 1200 successful calls and 60 failed calls (a total of 1260 calls). The 90th percentile of the response duration array is 600ms, generating the feature vector V = [240 calls / minute, 1200ms, 4.76%].

[0160] High-frequency exception scenario: 1500 successful calls and 300 failed calls (a total of 1800 calls) in 5 minutes, the 95th percentile of the response time is 1800ms, and the feature vector V = [300 calls / minute, 1800ms, 16.67%].

[0161] Low-frequency, high-failure scenario: 50 successful calls and 150 failures (200 total) in 5 minutes, the 80th percentile of the response time is 400 ms, and the feature vector V = [10 calls / minute, 400 ms, 75%].

[0162] Response fluctuation scenario: 2000 successful calls and 20 failed calls (2020 total calls) in 10 minutes, the 99th percentile of the response time is 2800ms, and the characteristic vector V = [200 times / minute, 2800ms, 0.99%].

[0163] Edge threshold scenario: 199 successful calls and 1 failed call (200 total) in 5 minutes, the 95th percentile of the response time is 1100ms, and the feature vector V = [39.8 calls / minute, 1100ms, 0.5%]

[0164] For example, consider a normal call scenario: 1200 successful calls and 60 consecutive failures (a total of 1260 calls). The successful call response duration array is [100ms, 200ms, ..., 1500ms] (1200 samples in total). The feature extraction module slices the data according to a preset period and calculates: the call failure rate F = 60 / 1260 × 100% = 4.76%. The response duration percentile R (95th percentile) is calculated using the formula k = ⌈95 / 100 × 1200⌉ = 1140, with the 1140th value in the array being 1200ms. The call frequency C = 1200 calls / 5 minutes (i.e., 240 calls / minute), and a three-dimensional feature vector V = [240 calls / minute, 1200ms, 4.76%] is constructed.

[0165] The risk assessment module makes decisions based on the rule base parameters (C_low = 200 times / minute, R_low = 1000ms, P1 = 0.8, P2 = 1.2, T1 = 5%):

[0166] The low-risk condition (C≤200×0.8=160 times / minute) is not met (current C=240);

[0167] Medium-risk conditions (C>160 or F>5% or R>1000×1.2=1200ms) are met (C=240 and R=1200ms);

[0168] The high-risk condition (C>200×1.5=300 times / minute) is not met.

[0169] The final risk rating was medium. Based on the historical average query volume of 1,500 queries per day and a risk level of 0.6, the smart contract module adjusted the daily query limit to 1,500 × (1 - 0.6) = 600 queries per day, shortening the validity period from 7 days to 3.5 days. A rate limit was also generated: the historical average concurrent volume was 300 queries per minute, and the concurrency limit was 300 × (1 - 0.3) = 210 queries per minute. The recovery condition was a success rate ≥ 95% for 5 minutes.

[0170] After receiving the circuit breaker command, the data gateway enabled the token bucket algorithm for rate limiting on the target interface, setting a concurrency limit of 210 calls per minute. Exceeding the limit returned HTTP 429. Continuous monitoring revealed that the call success rate increased to 96% after 5 minutes, triggering the rate limit recovery mechanism. The concurrency limit was gradually restored to 240 calls per minute in 10% increments. The policy optimization module analyzed 30 days of historical data and found that the C_low rate was reduced by 5% to 190 calls per minute due to the medium-risk event rate of 25% (exceeding the preset threshold of 20%). The R_low rate was increased by 3% to 1030ms due to the high-risk event rate of 3 times per day (below the threshold of 5 times per day). The optimized rules were embedded in the blockchain smart contract and took effect at midnight the next day.

[0171] Implementation effect:

[0172] Improved security: The daily query limit is reduced by 60%, and the interception rate of malicious high-frequency requests reaches 90%;

[0173] Enhanced stability: After current limiting, the interface response time is reduced from 1200ms to 800ms, and the error rate is reduced by 40%;

[0174] Adaptive optimization: After the baseline value was dynamically adjusted, the proportion of medium-risk events dropped to 18%, and the system's misjudgment rate decreased by 25%.

[0175] This embodiment fully demonstrates the entire process from real-time monitoring, multi-dimensional risk assessment, smart contract strategy execution to closed-loop optimization, verifying the technical advantages of the present invention in dynamic risk prevention and control and system stability assurance.

[0176] 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 embodied in other specific forms without departing from the spirit or essential characteristics of the invention. Therefore, the embodiments should be considered in all respects as illustrative and non-restrictive, and the scope of the invention is defined by the appended claims, not the foregoing description, and all variations within the meaning and range of equivalents of the claims are intended to be included therein. Any reference sign in a claim should not be construed as limiting the claim to which it relates.

Claims

1. A data sharing method based on smart contracts, characterized by: The following steps are involved: S1. Deploy a monitoring module on the data sharing platform node to continuously collect behavioral data on user interface calls, including call frequency, response time, error frequency, and user identity; S2. Perform statistical analysis on the behavior data to generate characteristic vectors of the distribution of call volume per unit time, continuous failure rate, and response time; S3. Mapping the feature vector to a risk level according to a preset rule, where the risk level is divided into three levels: low, medium, and high; S4. When the risk level is detected as medium or high, the smart contract automatically adjusts the user authorization parameters, including the query limit and validity period, and sends a circuit breaker instruction to the data gateway; S5. The data gateway limits concurrent requests from high-risk users or suspends specific interface services in real time according to the circuit breaker instructions. S6. Extract historical data, regularly analyze historical policy execution records, and optimize the preset rules; S4.1: The smart contract obtains the risk level information output in step S3 in real time through the data interaction channel established with the oracle interface, and encapsulates the risk level information in the data returned by the oracle in the form of a data structure; The smart contract then parses the returned data format according to the data protocol built into the oracle. This protocol clearly specifies the data encoding method, field order, and data type. S4.2: The smart contract adjusts the authorization parameters based on the received risk level and pre-set policy logic. The authorization parameter adjustment is divided into two parts: the daily query limit and the authorization validity period. The calculation formula for adjusting the daily query limit is as follows: ； The average query volume for the same period in history is the average of the same period in the past 7 days, obtained from the historical records stored in the blockchain; The calculation formula for adjusting the authorization validity period is as follows: ； The risk level coefficient is calculated by collecting historical data of similar risk events in the past 30 days, extracting the actual effect indicators of authorization parameter adjustments, and using a linear regression algorithm to establish a mapping relationship between risk levels and historical average adjustment effects. The formula for calculating the risk level coefficient is as follows: ； For the establishment of the linear regression model, the three risk levels of low, medium, and high are used as input variables, with preset values ​​of 0, 1, and 2 respectively. The historical average adjustment effect is the output variable. The coefficients a and b are obtained by fitting the historical data of the past 30 days through the least squares method. The calculation formula of the historical average adjustment effect is as follows: Historical average adjustment effect = a × risk level + b; The benchmark adjustment effect is the average of all historical adjustment effects, and the risk level weight is predefined by the risk level rule library; S4.3: The smart contract generates corresponding circuit breakers based on the risk level. For medium risk levels, a flow limiter is generated to limit the number of concurrent interface requests. For high risk levels, a circuit breaker is generated to suspend the interface service and enable a backup node. The concurrency limit calculation formula in the flow limiter is as follows: ； The historical average concurrency refers to the historical data stored in the blockchain, which is the average number of concurrent interface requests in the same time period over the past seven days. It is calculated based on the call frequency and average response time collected by S1. The calculation formula for the circuit breaker duration in a circuit breaker instruction is as follows: ； The historical average recovery time is the average repair time for similar failures in the past 30 days, obtained through historical blockchain data; For the current limiting instruction recovery, it will be automatically released when the interface call success rate is ≥ the preset success rate threshold for 5 consecutive minutes. For the circuit breaker instruction recovery, it will be released when the following conditions are met at the same time: The call success rate is ≥ the preset success rate threshold for 5 consecutive minutes; Response time ≤ 1x the reference value × the preset response time multiple; The benchmark value 1 of this part is the average response time during the same period in history, and its calculation formula is: ； Where m is the number of successful calls in the same period of history; S4.4: The smart contract triggers its own event mechanism to send a message containing a circuit breaker instruction to the monitoring module of the data gateway.

2. The data sharing method based on smart contracts according to claim 1, characterized in that: The step S1 further comprises the following steps: S1.1: Install a monitoring agent program on each service node of the data sharing platform and establish a communication link with the platform core system through a standardized interface; S1.2: Collect four types of structured data: call frequency, average response time, number of consecutive failures, and user blockchain address. The call frequency refers to the number of successful interface calls per unit time. The average response time refers to the arithmetic mean of the response times of all successful requests. The consecutive failure count refers to the number of consecutive calls that failed to return valid data. When a call returns an HTTP status code other than 200, the count is incremented by 1 and reset to 0 upon successful call. The user blockchain address refers to a 40-digit hexadecimal string that conforms to the address specification. S1.3: Adopt adaptive sampling rate and dynamically adjust the collection frequency according to the platform load; specifically: take the initial reference value as the unit time data collection frequency to form a fixed-size data block; when the interface response time of the service node exceeds the preset high threshold, the sampling rate is reduced to the first proportion of the basic sampling rate; when the interface response time of the service node is lower than the preset low threshold, the sampling rate is increased to the second proportion of the basic sampling rate; and the sampling rate adjustment range is limited to between the third proportion and the fourth proportion of the basic sampling rate; the preset high / low threshold is the interface response time critical value pre-set according to the system resource load, the first / second proportion represents the proportional coefficient of the sampling rate adjustment, and the third / fourth proportion represents the minimum and maximum limit proportions of the sampling rate.

3. The data sharing method based on smart contracts according to claim 2, characterized in that: The step S2 further comprises the following steps: S2.1: Divide historical data into analysis periods of a preset fixed length, generating independent data units for each period; S2.2: Calculate statistical indicators based on the call frequency, average response time, and number of consecutive failures collected in step S1. The statistical indicators are divided into call frequency C, call failure rate R, and response time percentile F. The call frequency C directly uses the call frequency data collected in S1. The call failure rate R refers to the ratio of call failures to the total number of calls during the analysis period. The calculation formula is as follows: ； The number of failed calls is the cumulative value of the consecutive failures collected by S1, and the total number of calls is the sum of the number of successful calls and the number of failed calls; The response time percentile F is a specific percentile value of the response time of all successful calls in the analysis period. Specifically, all successful call response times in the analysis period are sorted in ascending order to obtain the array t = [t1, t2,...,t n ], and then calculate the position index k of the Xth percentile, the formula is as follows: ； Where X is the preset percentile threshold, and n is the number of successful calls. Based on the calculation of the k value, the response time percentile F is the value of the kth position in the array t. S2.3: Based on the calculated statistical indicators, construct a three-dimensional feature vector V = [C, F, R] to comprehensively reflect the call frequency, stability, and response efficiency.

4. The data sharing method based on smart contracts according to claim 2, characterized in that: The step S3 further comprises the following steps: S3.1: Based on the three-dimensional feature vector V, a multi-condition combination logic is established to obtain a three-level risk determination rule base. The rules are as follows: Low risk: C ≤ reference value × P1 and F ≤ T1 and R ≤ reference value × P2; Medium risk: C>baseline value×P1 or F>T1 or R>baseline value×P2; High risk: C>baseline value×P3 and F>T2 and R>baseline value×P4; Among them, P1, P2, P3, and P4 are preset proportional coefficients, and T1 and T2 are preset failure rate thresholds; S3.2: Based on the four types of structured data collected in step S1.2, use them as the historical data set, select data that aligns with the current analysis cycle, and sort the filtered historical data by the three indicators of call frequency, call failure rate, and response time percentile. Calculate the Qth percentile, which means that Q% of the historical data is less than or equal to this value. The calculation formula is: ； Where n is the number of samples of historical data, and Q is a configurable parameter; The benchmark value is updated and calculated according to the preset time period every day to update the benchmark value parameters in the rule base. When the benchmark value is updated, all risk assessment rules that rely on the benchmark value are automatically adjusted according to the change in the benchmark value. S3.3: Acquire the feature vector V in real time, and determine whether it meets the high risk, medium risk, and low risk conditions in sequence according to the above steps, and then determine a unique risk level; in addition, when the feature vector meets multiple level conditions at the same time, it is prioritized as high risk.

5. The data sharing method based on smart contracts according to claim 1, characterized in that: The step S5 further comprises the following steps: S5.1: The data gateway obtains the circuit breaker instructions generated by S4 in real time by monitoring smart contract events. The instructions include circuit breaker type, threshold parameters, and recovery conditions. Circuit breaker types include current limiting and circuit breaking; threshold parameters include concurrency limit and circuit breaking duration; recovery conditions include success rate threshold and response time multiplier. S5.2: For medium-risk level rate limiting operations, dynamically adjust the interface's request processing strategy based on the concurrency limit in the rate limiting instruction. Specifically, use a token bucket algorithm to control the number of concurrent requests, ensuring that the number of requests per second does not exceed the threshold, and return a smart contract status code for requests that exceed the concurrency limit. S5.3: For high-risk circuit breaker operations, the service of the faulty interface is suspended, the status code of the smart contract is returned, and then the service node is automatically switched to the backup service node, and the request is routed to the available node through the load balancing mechanism; S5.4: For monitoring of recovery conditions, continuously monitor the call success rate and response time of the interface; for flow control scenarios, when the call success rate is ≥ the preset threshold for 5 consecutive minutes, gradually restore the concurrency limit according to the 10% standard; for circuit breaker scenarios, after the circuit breaker period expires, if the conditions described in step S4.3 are met at the same time, release the circuit breaker and restore the master node service.

6. The data sharing method based on smart contracts according to claim 1, characterized in that: The step S6 further comprises the following steps: S6.1: Obtain policy execution records from the blockchain for the past 30 days, including the risk level determination results from step S3, the authorization parameter adjustment records and circuit breaker instruction execution logs from step S4, and the rate limiting / circuit breaking operation records from step S5. Simultaneously extract the user behavior data collected in step S1 and the feature vector generated in step S2 as input for policy effectiveness analysis. S6.2: For strategy effectiveness evaluation, compare the system error rate and response time before and after strategy execution. If the error rate decreases and the response time decreases, the risk control is considered effective. S6.3: For rule base optimization logic, if the proportion of risk events exceeds the preset threshold for seven consecutive days, the current baseline value is determined to be too high and needs to be lowered to improve risk identification sensitivity; If the frequency of high-risk event triggering is lower than the preset threshold, the current baseline value is judged to be too low and needs to be adjusted upward to reduce excessive response; S6.4: Write the optimized benchmark value and proportional coefficient into the configuration table of the blockchain smart contract, and trigger the automatic update process of the S3 rule base. The new rules are updated within the preset time period every day.

7. A data sharing system based on smart contracts, applied to a data sharing method based on smart contracts as described in claims 1-6, characterized in that: It includes a monitoring module, a feature extraction module, a risk assessment module, a smart contract module, a data gateway module, and a strategy optimization module. The monitoring module is responsible for collecting call frequency, response time, number of failures, and user blockchain addresses in real time, dynamically adjusting the sampling rate, and transmitting data to the feature extraction module. The feature extraction module slices historical data according to a preset period, calculates the call frequency, failure rate and response time percentile, and generates a three-dimensional feature vector for risk assessment; the risk assessment module matches the preset rule base based on the three-dimensional feature vector, dynamically updates the benchmark value and determines a unique risk level in real time; After receiving the risk level, the smart contract module automatically adjusts the authorization parameters, generates a circuit breaker instruction and transmits it to the data gateway; the data gateway module monitors and verifies the circuit breaker instruction, executes concurrent flow limiting or service circuit breaking, and gradually restores the service after continuously monitoring the recovery conditions; the policy optimization module is used to analyze historical execution records and user behavior data, dynamically adjust the risk judgment benchmark value and proportional coefficient, optimize the rule base and store it on the chain.

Images