A blockchain-based digital archive management system

Abstract

The application discloses a kind of digital archives management systems based on block chain, it is related to the technical field of archives management, including, extraction module is used according to the behavior statistical information in digital archives management system, extracts state set;Risk analysis module is used according to normal set in state set, locates text position, predicts semantic layer abnormal risk and permission risk, and constructs control flow diagram, to assess structural layer abnormal risk, risk signal is generated by summarizing;Correlation analysis module is used on the basis of risk analysis module, analyzes the running threat condition of Solidity contract in digital archives management system, judges the start of Solidity contract correction mechanism;Influence module is used to start Solidity contract correction mechanism, analyze the influence of abnormal condition to Solidity contract operation;Waiting setting module is used to set time lock waiting period.

Description

Technical Field

[0001] This invention relates to the field of archives management technology, specifically to a blockchain-based digital archives management system. Background Technology

[0002] In today's era of rapid development in information technology, blockchain, as an emerging distributed database technology, has gradually permeated numerous fields. Digital archives management is one such field; with the advancement of digital transformation across various industries, digital archives have become a key component of information management.

[0003] However, traditional digital record management systems have many drawbacks. In terms of security, data is easily tampered with. Once record information is maliciously modified, its authenticity and authority are greatly compromised, seriously affecting subsequent use and decision-making. For example, if a company's financial records are tampered with, it may lead to errors in tax declarations and trigger legal risks. However, traditional digital record management often relies too heavily on behavioral data statistical features rather than deep semantic understanding, resulting in limited accuracy in identifying abnormal behavior. When malicious behavior is highly concealed or disguised as normal operating mode, it may be misjudged or missed. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a blockchain-based digital archive management system, which solves the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a blockchain-based digital archive management system, comprising,

[0006] The extraction module is used to extract status sets based on behavioral statistics from the digital archives management system;

[0007] The risk analysis module is used to locate text positions based on the normal set in the state set, predict semantic layer anomaly risks and permission risks, construct a control flow graph to assess structural layer anomaly risks, and summarize and generate risk signals.

[0008] The correlation analysis module is used, based on the risk analysis module, to analyze the operational threat status of Solidity contracts in the digital file management system and determine the activation of the Solidity contract correction mechanism;

[0009] The impact module is used to initiate the Solidity contract correction mechanism and analyze the impact of abnormal situations on the Solidity contract operation.

[0010] The waiting setting module is used to set the waiting period for the time lock.

[0011] Preferably, the extraction module includes an extraction unit 1, an extraction unit 2, and a judgment and storage unit;

[0012] Extraction Unit 1 is used to extract Solidity contracts, on-chain transaction information, and contract status information from the digital file management system using a blockchain explorer. The on-chain transaction information includes transaction parameters, participant information, transaction content, and transaction status; the contract status information includes basic contract information, file management-related status, global status variables, event logs, and status change history.

[0013] The second extraction unit is used to extract behavioral statistics from on-chain transaction information and contract status information. The behavioral statistics include the frequency of user operations on files, the distribution entropy of operation time periods, the average file access traffic, and the proportion of user operations in the corresponding time period to the total number of operations.

[0014] The judgment and storage unit is used to obtain the threshold range of each feature in the behavior statistics information based on historical data, compare the corresponding feature in the behavior statistics information with its corresponding threshold range, and if it exceeds the threshold range, it is initially determined that the user behavior is abnormal. The features that exceed the threshold range are counted to generate an abnormal set and the abnormal set is stored in the local state database. If it does not exceed the threshold range, it is initially determined that the user behavior is not abnormal, and the features that do not exceed the threshold range are counted to generate a normal set.

[0015] The normal set and the abnormal set are combined to obtain the state set.

[0016] Preferably, the risk analysis module includes semantic units, structural units, permission verification units, and fusion analysis units;

[0017] The semantic unit is used to extract the normal set from the state set and locate the text corresponding to each feature in the normal set. The corresponding text is determined, and the BERT token segmenter is used to convert the text into a token sequence. The token sequence is then mapped to a semantic vector by the BERT model. Each token corresponds to a 768-dimensional vector. Based on the 768-dimensional vector corresponding to each token, a sentence-level vector is obtained. The sentence-level vector is then input into the fully connected layer added to the output layer of the BERT model to train the differentiation between normal intent and hidden intent, predict the probability of hidden intent, and use the probability of hidden intent as the semantic layer anomaly risk score.

[0018] The structural unit is used to parse Solidity contract code into an abstract syntax tree. The parsed abstract syntax tree contains function call nodes, condition judgment nodes, and variable operation nodes. Based on the abstract syntax tree, code segments that execute sequentially, without branches, and without jumps are marked as basic blocks. Directed edges between basic blocks are determined based on their jump relationships to construct a control flow graph. Statistical parameter sets are obtained from the control flow graph to analyze the vulnerability risks caused by code complexity and calculate the code complexity index. The specific formula is as follows: In the formula, C is the code complexity index, and N is the code complexity index. cond N represents the number of conditional statements in the code. total N is the total number of executable statements in the code. external N represents the number of times an external contract is called within a Solidity contract. func The total number of functions defined in a Solidity contract. The percentage of conditional statements in the code. The average number of external calls for each function reflects the frequency of interactions between contracts; code complexity metrics are used as a structural layer anomaly risk score.

[0019] In this abstract syntax tree, each node represents a structure in the source code.

[0020] Preferably, the permission verification unit is used to obtain the permission set of the corresponding user and the permission requirement set corresponding to the corresponding operation in the normal set according to the Solidity contract, and the specific expressions are: P = {P1, P2, ..., P...} n} and P req ={P r1 P r2 ... P rm}, where P is the user's permission set, P req For the set of permission requirements corresponding to the operation, P1 to P n For the corresponding operations authorized by the user, P r1 To P rm For the user group authorized for the corresponding operation, based on the user's permission set and the permission requirement set corresponding to the operation, check the user permissions of the corresponding users in the normal set involved in the normal operation. If the corresponding user in the normal set does not appear in the permission requirement set corresponding to the operation, it is determined that the operation of the corresponding user in the normal set has an unauthorized exception. The number of operations with unauthorized exceptions is counted, and the ratio of the number of operations with unauthorized exceptions to the total number of operations is calculated to obtain the permission risk score.

[0021] The semantic layer anomaly risk score, the structural layer anomaly risk score, and the permission risk score are combined to generate a risk signal.

[0022] Preferably, the fusion analysis unit normalizes each parameter in the risk signal using the max-min normalization method, and obtains a comprehensive risk score by weighted summation of the processed semantic layer anomaly risk score, structural layer anomaly risk score, and permission risk score. The comprehensive risk score is then compared with a pre-set scoring threshold. If the comprehensive risk score exceeds the scoring threshold, it is determined that there is a real anomaly, and the normal set is included in the anomaly set.

[0023] Preferably, the correlation analysis module includes an acquisition unit, a threat analysis unit, a condition unit, and a mechanism activation unit;

[0024] The acquisition unit is used to statistically analyze the parameters subject to constraints in the Solidity contract to obtain a set of contract information. Based on the fusion analysis unit, it extracts the parameters involved in the anomaly set to obtain a set of abnormal operation information.

[0025] The threat analysis unit analyzes whether the current anomaly threatens the operation of the Solidity contract based on the set of abnormal operation information and the set of contract information, in order to calculate the data dependency corresponding to the user operation. The specific formula is as follows: Where Dep(D1, D2) represents the data dependency, D1 represents the set of abnormal operation information, D2 represents the set of contract information, and |D1∩D2| represents the number of intersection elements.

[0026] The association judgment unit is used to compare the data dependency with the average value of previous data dependencies to generate threat outcome information.

[0027] Preferably, the condition unit is used to determine the abnormal conditions preset by the Solidity contract. Based on the attributes of the abnormal conditions preset by the Solidity contract, parameters corresponding to the abnormal conditions preset by the Solidity contract are extracted from the abnormal operation information set. After condition comparison, it is determined whether the abnormal operation triggers the abnormal conditions preset by the Solidity contract, and condition result information is generated.

[0028] The mechanism activation unit is used to determine whether to activate the Solidity contract correction mechanism based on threat outcome information and condition outcome information. Specifically:

[0029] If the data dependency does not exceed the average of previous data dependencies, the threat result information is that there is no threat; otherwise, the threat result information is that there is a threat.

[0030] If the threat outcome information indicates that a threat exists or the condition outcome information indicates that the conditions are met, the Solidity contract correction mechanism will be activated.

[0031] The condition result information includes those that do not meet the conditions and those that meet the conditions.

[0032] Preferably, the impact module includes a data extraction unit and an evaluation unit;

[0033] The data extraction unit is used to extract the duration of the abnormal operation and the number of Solidity contract functional modules affected from the abnormal operation information set, and generate impact data by combining the data dependency corresponding to the user operation, and obtain normalized impact data by using the max-min normalization method.

[0034] The evaluation unit is used to analyze the impact of the current anomaly on the operation of the Solidity contract based on the normalized impact data. The impact score is obtained by weighted summation and is used to set the time lock waiting period.

[0035] Preferably, the waiting configuration module includes a configuration unit and an execution management unit;

[0036] The setting unit is used to score the impact level and set the time lock waiting period, specifically: Where T is the time lock waiting period, e is the Euler number, and RS is the impact score; the time lock waiting period is used to set a mandatory delay time for the Solidity contract.

[0037] Preferably, the execution management unit is used to reserve review time for community members based on the time lock waiting period. If no abnormality is found by the community member during the waiting period, the corresponding user is allowed to continue execution; otherwise, a rejection signal is triggered to stop the corresponding user from performing the operation.

[0038] This invention provides a blockchain-based digital archive management system, which has the following advantages:

[0039] (1) At the semantic level, user operation text is transformed into a 768-dimensional semantic vector to capture hidden intentions in the text. For example, in the file management scenario, when a user submits a request to "batch delete files", the semantic unit can predict the probability of its hidden intention by analyzing the text semantics. If the probability is high, a high semantic layer anomaly risk score is output to warn of potential data deletion risks in advance and avoid the loss of important files due to malicious or accidental operations. This deep mining of text semantics breaks through the limitations of traditional keyword matching and can identify risky operations with ambiguous semantics and hidden intentions. The structural unit starts from the bottom layer of the code, parses the Solidity contract code into an abstract syntax tree and constructs a control flow graph. By calculating the code complexity index, the vulnerability risk brought about by code complexity is quantified. For example, in a certain DeFi contract, the structural unit found through analysis that its function call nodes are complex and external calls are frequent, and the calculated code complexity index is high. Therefore, it is judged that the contract has a high vulnerability risk and outputs a high structural layer anomaly risk score. This analysis based on code structure can discover potential code defects before or during contract deployment, such as reentrancy attacks and overflow vulnerabilities, and help the development team optimize the code in time and reduce the possibility of being attacked. The permission verification unit, based on Solidity contracts, rigorously verifies the match between user permissions and operational permission requirements. Finally, the fusion analysis unit normalizes the risk scores from the semantic, structural, and permission layers, then weights and sums them to generate a comprehensive risk score. For example, in a file management system upgrade operation, the semantic layer score reflects ambiguous descriptions in the operation instructions, the structural layer score indicates high complexity in the upgrade code, and the permission layer score indicates that some operations involve permission changes. The fusion analysis unit integrates these scores and compares them with preset thresholds to accurately determine whether the upgrade contains genuine anomalies. If the threshold is exceeded, the relevant operations are included in the anomaly set, providing a clear basis for subsequent risk handling. This represents a leap from single-dimensional risk identification to multi-dimensional comprehensive risk assessment, further improving the accuracy and reliability of risk analysis.

[0040] (2) The correlation analysis module collects contract information and abnormal operation information through the acquisition unit, the threat analysis unit quantifies the threat level of the abnormality to the contract operation, the correlation judgment unit provides threat result information, the condition unit determines whether to trigger the preset abnormal conditions, and the mechanism activation unit decides whether to activate the correction mechanism based on this information. This enables timely detection and targeted handling of contract abnormalities, ensuring the normal operation of the contract. The data extraction unit of the impact module comprehensively considers the duration of the abnormal operation, the number of affected functional modules, and data dependencies. The evaluation unit obtains the impact score through weighted summation, providing a scientific basis for setting the time lock waiting period. This allows the system to take corresponding measures according to the severity of the abnormality, balancing security and efficiency. The setting unit of the waiting setting module dynamically sets the time lock waiting period based on the impact score. The execution management unit reserves review time for community members and decides whether to allow the operation to be executed based on the review results. This mechanism not only gives community members sufficient time to review, but also can stop the operation in time when anomalies are found, achieving the purpose of safe reversal, enhancing the security of the system and the trust of users. It further overcomes the problem of "contract deadlock" in traditional systems, where it is difficult to modify or upgrade smart contracts once they are deployed on the chain. This is because when management strategies change or security vulnerabilities occur (contract deadlock), traditional systems may not be able to respond or correct quickly. Attached Figure Description

[0041] Figure 1 This is a block diagram of a blockchain-based digital archive management system according to the present invention;

[0042] Figure 2 This is a block diagram of a blockchain-based digital archive management system of the present invention.

[0043] Figure 3 This is a block diagram of the risk analysis module in a blockchain-based digital archives management system according to the present invention;

[0044] Figure 4 This is a block diagram of the association analysis module in a blockchain-based digital archives management system according to the present invention;

[0045] Figure 5 This is a block diagram of the impact modules in a blockchain-based digital archives management system of the present invention;

[0046] Figure 6 This is a block diagram of a waiting setting module in a blockchain-based digital archive management system according to the present invention. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] Example 1

[0049] Please see Figures 1 to 6 This invention provides a blockchain-based digital archive management system, comprising:

[0050] The extraction module is used to extract status sets based on behavioral statistics from the digital archives management system;

[0051] The risk analysis module is used to locate text positions based on the normal set in the state set, predict semantic layer anomaly risks and permission risks, construct a control flow graph to assess structural layer anomaly risks, and summarize and generate risk signals.

[0052] The correlation analysis module is used, based on the risk analysis module, to analyze the operational threat status of Solidity contracts in the digital file management system and determine the activation of the Solidity contract correction mechanism;

[0053] The impact module is used to initiate the Solidity contract correction mechanism and analyze the impact of abnormal situations on the Solidity contract operation.

[0054] The waiting setting module is used to set the waiting period for the time lock.

[0055] The extraction module extracts state sets from the behavioral statistics of the digital archives management system. Based on this, the risk analysis module uses the normal set to locate text positions, enabling accurate prediction of semantic-level anomaly risks and permission risks. For example, in accessing digital archives, by analyzing the semantics of user operation text, such as "delete important files," and combining it with normal operation semantic patterns, semantic-level anomaly risks can be detected in advance. Simultaneously, based on user permission configurations, it determines whether the user has the authority to perform the relevant operations, identifying permission risks. This risk prediction capability helps to take preventative measures to prevent unauthorized operations from damaging the archives.

[0056] The risk analysis module constructs a control flow graph to assess structural layer anomalies. Taking a digital archive management function implemented with a Solidity contract as an example, analyzing the control flow graph of the contract code can reveal potential vulnerabilities caused by complex logical branches or execution risks arising from unreasonable code structure. Risks at different levels are aggregated to generate risk signals, providing comprehensive and accurate risk information for subsequent processing.

[0057] Based on the risk signals output by the risk analysis module, the correlation analysis module further analyzes the operational threat status of Solidity contracts in the digital file management system. For example, when a risk signal indicates a semantic layer anomaly risk involving smart contract operations, the correlation analysis module will delve into the contract code's operational logic under such anomalies to determine if there is a possibility of malicious exploitation, such as whether there are logical vulnerabilities in the contract that can be exploited by attackers.

[0058] Based on the operational threat status, the correlation analysis module determines whether to activate the Solidity contract correction mechanism. If a serious security vulnerability is found in the contract, such as the risk of data tampering or leakage, the correction mechanism will be triggered. This intelligent judgment mechanism ensures that the contract can be adjusted in a timely manner when the risk reaches a certain level, thus guaranteeing the safe and stable operation of the digital file management system.

[0059] After the Solidity contract correction mechanism is activated, the impact module analyzes the impact of abnormal situations on the Solidity contract's operation. For example, if the abnormal situation is caused by data errors leading to contract execution failures, the impact module will assess the degree of impact of the erroneous data on various functional modules within the contract, such as whether it leads to errors in asset recording or permission judgment, providing detailed information support for subsequent correction and recovery work.

[0060] The waiting settings module allows for setting a time-lock waiting period to enable safe reversal. A certain waiting period can be set before contract modifications or important operations are executed. During this period, if problems are found in the modification plan or if the operation may have negative impacts, the operation can be terminated in time to avoid irreparable losses. For example, when making a major upgrade to a smart contract, a 3-day waiting period can be set. During this period, further testing and review can be conducted. If new risks are found, the upgrade can be stopped and the plan readjusted.

[0061] In this embodiment, state sets are extracted from the behavioral statistics of the digital archive management system. These state sets contain various operational state information during system operation and serve as the foundational data source for subsequent risk analysis. The logic involves filtering and organizing a large amount of behavioral statistics to extract representative state sets for more efficient risk assessment. Based on the normal set of state obtained by the extraction module, text positions are located, and natural language processing techniques and permission rules are used to predict semantic layer anomaly risks and permission risks. Simultaneously, a control flow graph is constructed to assess anomaly risks from the code structure level. This module summarizes the risk assessment results from different dimensions, generating risk signals to provide comprehensive risk information for subsequent correlation analysis. The logic involves comprehensively utilizing multiple analysis methods to fully and deeply uncover the risks existing in the system from both semantic and structural perspectives. Based on the risk signals generated by the risk analysis module, the operational threat status of Solidity contracts is analyzed in depth to determine whether the conditions for triggering the correction mechanism have been met. The logic is to focus on the contract as a key link based on existing risk information, assess the potential threat of risks to contract operation, and ensure that the correction mechanism is triggered in a timely manner when the threat reaches a certain level, thus protecting system security. After the correction mechanism is activated, the impact of the anomaly on the Solidity contract operation is analyzed. The logic is to clearly understand the specific scope and extent of the anomaly during the correction process, so as to formulate targeted correction strategies and ensure that the contract can resume normal operation.

[0062] Example 2

[0063] Please refer to Figure 2 Specifically: the extraction module includes extraction unit 1, extraction unit 2, and judgment and storage unit;

[0064] The first extraction unit is used to extract Solidity contracts, on-chain transaction information, and contract status information from the digital file management system using a blockchain explorer (such as Etherscan). The on-chain transaction information includes transaction parameters, participant information, transaction content, and transaction status; the contract status information includes basic contract information, file management-related status, global status variables, event logs, and status change history.

[0065] Among them, on-chain transactions are the basic operational units on the blockchain. Transaction parameters include transaction hash, block number and timestamp. Transaction hash is used to track transaction status, block number is used to record the block height into which the transaction is packaged and can be used to estimate the time when the transaction occurred, and timestamp is the time when the block was mined, usually accurate to the second.

[0066] Participant information includes the sender's address and the recipient's address;

[0067] The transaction details include the transaction type and data fields. The transaction type is used to distinguish between ordinary transfers, contract creation, and contract invocation. The data fields refer to the parameters carried when the contract is invoked, which are usually ABI-encoded byte strings.

[0068] The transaction status includes gas-related parameters and transaction status codes. Gas-related parameters include the price per unit of gas that the initiator is willing to pay, the actual amount of gas consumed (abnormally high gas consumption may indicate complex calculations or attacks), and the maximum total cost, which is used to control transaction costs. In the transaction status code, 1 indicates that the transaction is successful and 0 indicates that the transaction has failed.

[0069] Basic contract information includes contract address, contract creator, and qualified version;

[0070] Record management related status includes the record registry and access control table;

[0071] Global state variables include the administrator list, operation timers, and configuration parameters;

[0072] The event log includes the event type and event parameters;

[0073] The state change history includes state variable snapshots and state transition paths; the state variable snapshot refers to the state value at a specific block height (e.g., the file owner at block 1000). The state transition path is, for example, the complete process of transferring file permissions from user A to user B.

[0074] The second extraction unit is used to extract behavioral statistics from on-chain transaction information and contract status information. The behavioral statistics include the frequency of user operations on files, the distribution entropy of operation time periods, the average file access traffic, and the proportion of user operations in the corresponding time period to the total number of operations.

[0075] The formula for calculating the distribution entropy during the operation period is as follows: Where Fh is the distribution entropy of the operation period, i is the time period number, q is the number of time periods, and p i Let be the proportion of the number of operations in the i-th time interval to the total number of operations, and log2(*) is a logarithmic function with base 2;

[0076] Operation time period distribution entropy is used to measure the uniformity of operation distribution across different time periods;

[0077] The judgment and storage unit is used to obtain the threshold range of each feature in the behavior statistics information based on historical data, compare the corresponding feature in the behavior statistics information with its corresponding threshold range, and if it exceeds the threshold range, it is initially determined that the user behavior is abnormal. The features that exceed the threshold range are counted to generate an abnormal set and the abnormal set is stored in the local state database. If it does not exceed the threshold range, it is initially determined that the user behavior is not abnormal, and the features that do not exceed the threshold range are counted to generate a normal set.

[0078] The normal set and the abnormal set are combined to obtain the state set.

[0079] In this embodiment, raw on-chain data, including contract code, transaction details, and status change history, is directly captured by a blockchain explorer, ensuring the authenticity and immutability of the data source. For example, in a medical record management system, by extracting event logs from contract status information, the creation, modification, and access records of each medical record can be fully traced, providing credible evidence for medical disputes. Compared to traditional databases, the transparency and immutability of blockchain data ensure the integrity of behavioral data and avoid the risk of human tampering.

[0080] By extracting behavioral statistical indicators, such as operation frequency and time-period distribution entropy, from raw data, user behavior patterns are transformed into quantifiable mathematical features. Example: In a company's file system, calculating the time-period distribution entropy revealed that an employee frequently accessed sensitive files outside of working hours, which was later confirmed as a data breach attempt. Using data science methods to uncover hidden risks, such as abnormal access times and sudden traffic surges, is more efficient and sensitive than manual monitoring.

[0081] Based on historical data, characteristic threshold ranges are generated, such as normal operation frequency intervals. Current behavior is compared in real time, and exceeding the threshold triggers an anomaly flag. For example, a government archive system set "daily access volume exceeding 300% of the historical average" as the anomaly threshold, successfully intercepting a DDoS attack targeting public data. This automated judgment mechanism reduces manual intervention, shortens risk response time, and stores anomaly sets in a local database, providing a basis for subsequent audits. The normal and anomaly sets are merged into a state set, providing a unified data interface for subsequent risk analysis and correlation judgment modules. For example, in the risk analysis module, semantic unit analysis of the text content in the state set reveals that a user used sensitive terms such as "delete key files." Combined with the permission verification unit, it confirms that the user lacks this permission, promptly preventing an unauthorized operation. The state set, as a data hub, enables seamless integration between various functional modules, improving the overall analytical capabilities of the system.

[0082] Example 3

[0083] Please refer to Figure 3Specifically: the risk analysis module includes semantic units, structural units, permission verification units, and fusion analysis units;

[0084] In blockchain-based digital archive management, malicious users may transmit covert instructions through textual information such as transaction notes and operation logs. These instructions could include coded messages indicating unauthorized data access, or embedded malicious intent within seemingly normal operation descriptions, such as permission tampering disguised as "data correction." Semantic feature recognition aims to uncover the true intent from the surface meaning of text, addressing the problem of "semantic fraud" that is difficult to detect using traditional statistical methods.

[0085] The semantic unit is used to extract the normal set from the state set and locate the text corresponding to each feature in the normal set. The corresponding text is determined, and the BERT token segmenter is used to convert the text into a token sequence. The token sequence is then mapped to a semantic vector by the BERT model. Each token corresponds to a 768-dimensional vector. Based on the 768-dimensional vector corresponding to each token, a sentence-level vector is obtained. The sentence-level vector is then input into the fully connected layer added to the output layer of the BERT model to train the differentiation between normal intent and hidden intent, predict the probability of hidden intent, and use the probability of hidden intent as the semantic layer anomaly risk score.

[0086] BERT, or Transformer-Based Bidirectional Encoder Representation, is a pre-trained language model proposed by Google in 2018. The BERT tokenizer is a tool used by the BERT model to split text into appropriate units (tokens). It is mainly based on the WordPiece algorithm, which segments words into sub-word units. For example, "unhappiness" might be segmented into "un", "happy", and "ness".

[0087] The relevant text can be archive metadata, archive content text, operation log text, or interactive text, etc. Among them, archive metadata is used to describe the structured text of archive content, archive content text is the core textual content of the archive (unstructured or semi-structured), such as: contract terms, approval opinions, meeting minutes, audit report text, etc.; operation log text is the text record generated by system user operations, such as: access log, change record, or contract execution log; interactive text is the interactive information between the user and the system, such as: search keywords, query statements (such as "find 2024 procurement contracts");

[0088] A token sequence is a digital representation of text: converting natural language text, such as operation logs, smart contract code comments, and user input text, into a token sequence is a common preprocessing step in the NLP field. The purpose is to transform unstructured text into numerical data that the model can process, such as word vectors.

[0089] In Natural Language Processing (NLP), sentence-level vectors are generated to encode the semantic information of text into a single fixed-dimensional vector representation, thereby capturing the overall meaning of the entire sentence. A sentence-level vector compresses the semantic information of the entire sentence into a single fixed-dimensional vector (typically 768-dimensional), integrating the contextual information of all tokens in the sentence.

[0090] In blockchain smart contracts, attackers may implant hidden backdoors, such as undisclosed privilege escalation functions or malicious data manipulation logic. These backdoors appear to conform to normal logic, but trigger attacks under specific conditions. The goal of detecting hidden backdoors is to identify the potential logical complexity in the contract code and prevent unauthorized access or data tampering.

[0091] The structural unit is used to parse Solidity contract code into an Abstract Syntax Tree (AST). The parsed AST contains function call nodes, conditional statement nodes, and variable operation nodes. Based on the AST, code segments that execute sequentially, without branches or jumps are marked as basic blocks. Directed edges between basic blocks are determined based on their jump relationships to construct a Control Flow Graph (CFG). Statistical parameter sets are obtained from the CFG to analyze the vulnerability risks caused by code complexity and calculate the code complexity index. The specific formula is as follows: In the formula, C is the code complexity index, and N is the code complexity index. cond N represents the number of conditional statements in the code. total N is the total number of executable statements in the code. external N represents the number of times an external contract is called within a Solidity contract. func The total number of functions defined in a Solidity contract. This represents the proportion of conditional statements in the code. The average number of external calls for each function reflects the frequency of interactions between contracts; code complexity metrics are used as a structural layer anomaly risk score.

[0092] The relationship between the number of conditional statements in the code and the control flow graph is as follows: each conditional statement corresponds to a branch node in the control flow graph (i.e., a basic block has multiple outgoing edges).

[0093] The relationship between the total number of executable statements in the code and the control flow graph is as follows: each basic block in the control flow graph contains several statements executed sequentially. By summing the number of statements in all basic blocks, the total number of executable statements in the code can be obtained.

[0094] The relationship between the number of times an outer contract is called in a Solidity contract and the control flow graph is as follows: an outer contract call is represented in the control flow graph as an edge pointing from the current contract's basic block to the entry node of the outer contract. Each outer contract call increases the total number of calls to the outer contract in the Solidity contract.

[0095] The relationship between the total number of functions defined in a Solidity contract and the control flow graph is as follows: each function corresponds to a subgraph in the control flow graph, and the total number of functions defined in the Solidity contract can be obtained by counting the number of subgraphs in the control flow graph.

[0096] An abstract syntax tree (AST) is an abstract representation of the syntactic structure of source code. It uses a tree structure to represent the syntactic structure of code, with each node in the tree representing a structure in the source code.

[0097] Code complexity metrics are used to quantitatively assess the structural complexity and potential risks of code;

[0098] Parsing Solidity contract code into an Abstract Syntax Tree (AST) is typically done using a specialized compiler or parsing tool, such as Ethereum's official Solidity compiler, solc. When processing code, the compiler first performs lexical analysis, breaking the code down into individual lexical units. Then, it performs syntax analysis, combining these lexical units into an abstract syntax tree according to grammar rules.

[0099] A control flow graph is a directed graph used to represent the execution flow of a program. Nodes in the graph represent basic blocks of code (a code segment that executes sequentially and has only one entry point and one exit point), and edges represent control transfer relationships between basic blocks, such as transferring control from one branch of a conditional statement to another, or transferring control from one function call to subsequent code.

[0100] A basic block is a sequence of instructions executed sequentially in a program that satisfies the following conditions:

[0101] Single entry point: There is only one entry point (the first instruction);

[0102] Single exit: There is only one exit point (the last instruction);

[0103] Sequential execution: Instructions within a block are executed sequentially, without branches or jumps (except for the last instruction);

[0104] In this abstract syntax tree, each node represents a structure in the source code.

[0105] In this embodiment, normal behavior text is filtered from the state set, and the BERT model is used to convert the text into a 768-dimensional semantic vector. A classifier is trained through a fully connected layer to identify hidden intentions, such as malicious requests disguised as normal operations. In a certain government system, when a user submits a request to "update the file format", semantic analysis reveals that the text vector has a similarity of 82% with historical "data leakage" requests, triggering a risk warning. This helps to overcome the limitations of traditional rule-based detection and capture potential threats at the semantic level, such as phishing attacks and social engineering inducements.

[0106] Solidity contracts are parsed into abstract syntax trees, and control flow graphs are constructed. Code complexity metrics are calculated using formulas. For example, analysis of a DeFi archive system contract revealed a code complexity metric exceeding a threshold, indicating a recursive call vulnerability that could lead to reentrancy attacks. By quantifying code risk, high-complexity code segments, such as conditional statements nested more than five levels, can be identified early, preventing potential exploitation of vulnerabilities. Furthermore, by comparing user permission sets with operation permission requirement sets, permission risk scores are calculated, enabling fine-grained permission auditing to prevent unauthorized access by internal personnel, such as an accountant viewing executive salary records.

[0107] The risk scores at the semantic, structural, and permission levels are normalized, and a comprehensive risk score is calculated by weighted summation. For example, in a medical record system, the semantic risk score of a certain operation is 0.85, but the structural and permission risks are both 0.1, resulting in a comprehensive score of 0.37. The system triggers a moderate-intensity review process, which helps avoid misjudgments based on a single dimension. For example, operations that are semantically suspicious but structurally safe can avoid excessive blocking, thus balancing security and usability.

[0108] Example 4

[0109] Please refer to Figure 3 Specifically: The permission verification unit is used to obtain the permission set of the corresponding user and the permission requirement set corresponding to the operation in the normal set according to the Solidity contract. The specific expressions are: P = {P1, P2, ..., P...} n} and P req ={P r1 P r2 ... P rm}, where P is the user's permission set, P req For the set of permission requirements corresponding to the operation, P1 to P n For the corresponding operations authorized by the user, P r1 To P rmFor the user group authorized for the corresponding operation, based on the user's permission set and the permission requirement set corresponding to the operation, check the user permissions of the corresponding users in the normal set involved in the normal operation. If the corresponding user in the normal set does not appear in the permission requirement set corresponding to the operation, it is determined that the operation of the corresponding user in the normal set has an unauthorized exception. The number of operations with unauthorized exceptions is counted, and the ratio of the number of operations with unauthorized exceptions to the total number of operations is calculated to obtain the permission risk score.

[0110] Solidity is an object-oriented, high-level programming language specifically designed for writing smart contracts on the Ethereum Virtual Machine (EVM).

[0111] The semantic layer anomaly risk score, the structural layer anomaly risk score, and the permission risk score are combined to generate a risk signal.

[0112] The fusion analysis unit normalizes the parameters in the risk signal using the max-min normalization method. It then obtains a comprehensive risk score by weighted summation of the processed semantic layer anomaly risk score, structural layer anomaly risk score, and permission risk score. The comprehensive risk score is compared with a pre-set scoring threshold. If the comprehensive risk score exceeds the scoring threshold, it is determined that there is a real anomaly, and the normal set is included in the anomaly set.

[0113] In this embodiment, firstly, the permission set P of the corresponding user in the normal set and the permission requirement set corresponding to the corresponding operation are obtained according to the Solidity contract. For example, in a company's digital document management system, user A's permission set P may include read and modify permissions for ordinary documents, while the permission requirement set for a certain operation, such as deleting important financial statements, may only be allowed to be executed by the finance manager and specific senior management personnel. Then, the user permissions of the corresponding user in the normal set involved in the normal operation are checked. If the corresponding user in the normal set does not appear in the permission requirement set corresponding to the operation, such as user A attempting to delete important financial statements in the above example, but not being in the permission requirement set for that operation, it is determined that the user's operation involves unauthorized behavior. This precise permission verification mechanism can promptly detect and prevent unauthorized behavior by users, protecting the security of sensitive data in the system.

[0114] After identifying unauthorized access violations, the number of operations exhibiting such violations is counted, and the ratio of this count to the total number of operations is calculated to obtain a permission risk score. The permission risk score provides a quantitative indicator to measure the degree of risk associated with user permissions. This helps system administrators or security teams gain a more intuitive understanding of the status of permission management in the system, enabling them to take appropriate measures. For example, if a user's permission risk score is found to be continuously increasing, their permissions can be reviewed and adjusted promptly, or monitoring of that user's operations can be strengthened.

[0115] By combining the permission risk score with the semantic layer anomaly risk score and the structural layer anomaly risk score, a risk signal is generated. For example, if the semantic layer anomaly risk score is 0.3, the structural layer anomaly risk score is 0.2, and the permission risk score is 0.4, then the risk signal is the combination of these three scores. Comprehensively considering risk scores from multiple dimensions allows for a more complete assessment of the system's risk status.

[0116] The fusion analysis unit first normalizes the parameters in the risk signal using the min-max normalization method. Normalization transforms these parameters to the same value range for subsequent comparisons and calculations. This normalization process ensures comparability of risk scores across different dimensions, avoiding weight imbalances caused by varying score ranges. The processed semantic layer anomaly risk scores, structural layer anomaly risk scores, and permission risk scores are then weighted and summed to obtain a comprehensive risk score. For example, assuming a weight of 0.4 for the semantic layer anomaly risk score, 0.3 for the structural layer anomaly risk score, and 0.3 for the permission risk score, after normalization, the semantic layer anomaly risk score is 0.6, the structural layer anomaly risk score is 0.5, and the permission risk score is 0.7. Therefore, the comprehensive risk score is 0.4*0.6 + 0.3*0.5 + 0.3*0.7 = 0.6. The weighted summation method assigns appropriate weights to each score based on the importance of different risk dimensions, resulting in a more comprehensive and accurate overall risk score. For example, in a financial digital record management system with extremely high data security requirements, the weight of access risk scoring may be set relatively high, because vulnerabilities in access management may directly lead to serious consequences such as financial losses or leakage of customer information. In this way, the system can more effectively focus on and handle high-risk areas, thereby improving overall security.

[0117] The system compares a comprehensive risk score with a pre-set threshold. For example, if the threshold is 0.5, a comprehensive risk score of 0.58 exceeding this threshold indicates a genuine anomaly. This threshold comparison provides the system with a clear decision-making basis. When the comprehensive risk score exceeds the threshold, the system can take appropriate measures, such as strengthening security monitoring, activating emergency response mechanisms, or notifying relevant personnel for further investigation and handling. For instance, in a digital document management system, if the comprehensive risk score exceeds the threshold, the system might immediately suspend the relevant user's access and conduct a comprehensive security check to prevent potential security threats from escalating. Furthermore, including the normal set in the anomaly set helps the system conduct more comprehensive analysis and management of anomalies, providing more data support for subsequent risk prevention.

[0118] In summary, the authorization verification unit and the fusion analysis unit, through a series of rigorous steps and scientific methods, provide a comprehensive and accurate risk assessment and management capability for the blockchain-based digital archives management system, effectively ensuring the system's security and stability, and protecting the integrity and confidentiality of digital archives.

[0119] Example 5

[0120] Please refer to Figure 4 Specifically: the correlation analysis module includes an acquisition unit, a threat analysis unit, a condition unit, and a mechanism activation unit;

[0121] The acquisition unit is used to statistically analyze the parameters subject to constraints in the Solidity contract to obtain a set of contract information. Based on the fusion analysis unit, it extracts the parameters involved in the anomaly set to obtain a set of abnormal operation information.

[0122] This involves mapping key information about abnormal operations, such as the operation type, the file ID involved, and the user ID, to the input and output parameters of the Solidity contract to obtain a set of abnormal operation information. For example, if the abnormal operation involves modifying file permissions, the smart contract is checked to see if there are functions and parameters related to modifying file permissions. The data relied upon by the Solidity contract during execution is analyzed to determine whether the data involved in the abnormal operation is critical contract data. For example, the Solidity contract might rely on the file's creation time to verify the legality of the operation; if the abnormal operation modified the creation time, then this data is critical.

[0123] The contract information set consists of parameters in a Solidity contract that are subject to restrictions and constraints. Examples of such data include administrator address data used for access control, data recording asset balances, and data related to contract rule definitions.

[0124] The threat analysis unit analyzes whether the current anomaly threatens the operation of the Solidity contract based on the set of abnormal operation information and the set of contract information, in order to calculate the data dependency corresponding to the user operation. The specific formula is as follows: Where Dep(D1, D2) represents the data dependency, D1 represents the set of abnormal operation information, D2 represents the set of contract information, and |D1∩D2| represents the number of intersection elements.

[0125] The data dependency corresponding to the user operation is used to quantify the threat level of abnormal operation to the contract function.

[0126] The association judgment unit is used to compare the data dependency with the average value of previous data dependencies to generate threat outcome information.

[0127] The condition unit is used to determine the abnormal conditions preset by the Solidity contract. Based on the attributes of the abnormal conditions preset by the Solidity contract, it extracts the parameters corresponding to the abnormal conditions preset by the Solidity contract from the abnormal operation information set. After condition comparison, it determines whether the abnormal operation triggers the abnormal conditions preset by the Solidity contract and generates condition result information.

[0128] The purpose of determining whether a smart contract's preset abnormal conditions have been triggered is to promptly detect and handle operations that violate contract rules, protecting the security, integrity, and availability of the digital file management system. By accurately identifying abnormal triggering situations, appropriate measures can be taken, such as preventing illegal operations, logging abnormalities, and notifying administrators, thereby ensuring the normal operation of the system and the security of the data.

[0129] The mechanism activation unit is used to determine whether to activate the Solidity contract correction mechanism based on threat outcome information and condition outcome information. Specifically:

[0130] If the data dependency does not exceed the average of previous data dependencies, the threat result information is that there is no threat; otherwise, the threat result information is that there is a threat.

[0131] If the threat outcome information indicates that a threat exists or the condition outcome information indicates that the conditions are met, the Solidity contract correction mechanism will be activated.

[0132] The condition result information includes those that do not meet the conditions and those that meet the conditions.

[0133] In this embodiment, parameters subject to restrictions in the Solidity contract, such as permission thresholds, funding limits, and operation frequency limits, are statistically analyzed to form a contract information set denoted as S. Parameters related to these restrictions are extracted from the anomaly set output by the fusion analysis to form an anomaly operation information set denoted as A. For example, in a DeFi lending contract, S includes parameters such as "single loan limit of 100 ETH" and "administrator address whitelist." If the anomaly set shows that an address borrowed 150 ETH in a single day, then A contains the relevant data for this over-limit operation.

[0134] Establishing a mapping relationship between contract design constraints and actual operations provides a benchmark for subsequent threat analysis, avoiding isolated analysis of anomalous data. Quantifying the depth of impact of anomalous operations uses numerical values ​​to quantify the degree of threat, avoiding subjective judgment bias. For example, data dependency can intuitively reflect whether an anomalous operation affects the core logic of the contract, such as access control or fund calculation. Example: If a contract's information set contains 10 core parameters, and an anomalous operation involves 8 of them, then the data dependency = 0.8. If the historical average is 0.3, it indicates that the anomaly highly threatens the contract's operation.

[0135] Predefined contract exception conditions, such as "daily transfers exceeding 5% of total funds" or "non-whitelisted address calling critical functions." Parameters are extracted from the exception operation information set and compared against the preset conditions.

[0136] If the conditions are met, such as a single address receiving 6% of the total funds in a single day, a "Meets the conditions" result will be generated.

[0137] If the conditions are not met, such as the transfer amount being only 3%, a "not meeting the conditions" result will be generated.

[0138] Combine the threat outcome (threat present, threat absent) with the condition outcome (condition met, condition not met):

[0139] If a "threat exists" or "conditions are met", the contract correction mechanism will be activated immediately; otherwise, the current state will be maintained or only logs will be recorded.

[0140] Example 6

[0141] Please refer to Figure 5 and Figure 6 Specifically: Directly modifying a deployed Solidity contract when it encounters anomalies or requires an upgrade carries significant risks. On one hand, the immutability of blockchain makes it difficult to directly modify a contract once deployed; on the other hand, emergency upgrades or anomalies can introduce new vulnerabilities or lead to flawed decision-making due to time constraints. Therefore, a safety timeframe needs to be set to prevent the introduction of new vulnerabilities or flawed decision-making due to time constraints.

[0142] The impact module includes a data extraction unit and an evaluation unit;

[0143] The data extraction unit is used to extract the duration of the abnormal operation and the number of Solidity contract functional modules affected from the abnormal operation information set, and generate impact data by combining the data dependency corresponding to the user operation, and obtain normalized impact data by using the max-min normalization method.

[0144] The evaluation unit is used to analyze the impact of the current anomaly on the operation of the Solidity contract based on the normalized impact data. The impact score is obtained by weighted summation and is used to set the time lock waiting period.

[0145] The waiting configuration module includes a configuration unit and an execution management unit;

[0146] The setting unit is used to score the degree of impact and set the time lock waiting period, specifically: Where T is the time lock waiting period, e is the Euler number, with a value of approximately 2.71828, and RS is the impact score; the time lock waiting period is used to set a mandatory delay time for the Solidity contract.

[0147] The derivative of an exponential function with base e is itself, meaning its growth rate is related to the function value, reflecting a natural and continuous growth trend. In this scenario, it can simulate the natural and accelerating growth of time as the score increases. Compared to exponential functions with other constant bases, using e better reflects a relatively smooth and logically consistent growth trend.

[0148] The denominator in this section is determined by adjusting the actual scoring scale and the expected growth rate. If the scoring range is 0-100, dividing by 10 can adjust the score value to a relatively appropriate range, ensuring that the independent variable of the exponential function is not too large or too small. If the denominator is too small, such as 1, then when the score is high, the waiting period value will grow extremely large; if the denominator is too large, such as 100, then the exponential function grows slowly, failing to highlight the characteristic of rapid growth in the waiting period under high risk.

[0149] Subtracting 1 from the time lock waiting period formula is mainly to adjust the starting value of the waiting period. When the score is 0, This means that the waiting period is 0 days when the risk is lowest (score 0), which is logical, as no waiting period is needed when there is no risk. If we don't subtract 1, the waiting period would be 1 day when the score is 0, which is unreasonable for a risk-free situation. At the same time, subtracting 1 also calibrates the calculated waiting period on an overall numerical basis, making it more consistent with the expected range of waiting period days in actual business scenarios.

[0150] The higher the impact score, the longer the waiting period required. This is because high-impact operations, such as modifying the liquidity pool algorithm or transferring governance privileges, typically involve complex code logic, and potential vulnerabilities may be difficult to discover through short-term testing. For example, reentrancy vulnerabilities may only be triggered in high-frequency trading scenarios, requiring stress testing or simulated runs during the waiting period to expose the risk.

[0151] The execution management unit is used to reserve review time for community members based on the time lock waiting period. If no abnormality is found by the community member during the waiting period, the corresponding user is allowed to continue execution; otherwise, a rejection signal is triggered to stop the corresponding user from executing the operation.

[0152] In this embodiment, two core indicators are extracted from the abnormal operation information set:

[0153] Duration of abnormal operation: For example, an attack lasting 2 hours;

[0154] Number of affected functional modules: such as the contract permission management and fund transfer modules;

[0155] By combining the data dependency output from the threat analysis module, three-dimensional impact data is generated. For example, if an abnormal operation lasts for 4 hours, affects 3 core modules, and has a data dependency of 0.9, an impact data set (4, 3, 0.9) is formed. This avoids the bias of a single indicator; for example, looking only at the duration may overlook the deeper risks of high data dependencies, while a comprehensive indicator can fully reflect the actual destructive power of the anomaly. The three-dimensional impact data is converted into values ​​in the [0, 1] range using the max-min normalization method, transforming complex impacts into calculable scores (e.g., a 0-1 range), providing a scientific basis for the dynamic setting of the time lock waiting period and avoiding a rigid, one-size-fits-all approach to delays.

[0156] The waiting period is calculated based on the degree of impact, and the exponential function property is used to achieve non-linear control of "short waiting for low impact and long review for high impact." For example, the waiting period increases from 1.72 days to 1.46 days, an increase of 80%, strengthening the constraints on high-risk operations. During the waiting period, community members can review abnormal operations through on-chain voting, security audits, etc. If no abnormality is found, the operation is automatically allowed to proceed after the waiting period ends; if an abnormality is found, a veto signal is triggered, the operation is terminated, and the state is rolled back. For example, the waiting period for a DeFi contract upgrade application is 48 hours. If the community discovers a reentrancy vulnerability in the code in the 24th hour, a veto signal is triggered through governance voting to prevent the attack from occurring. Combining automated delays with manual intervention, the participation of decentralized governance is ensured, and time locks prevent the exploitation of urgent vulnerabilities. Through the above mechanisms, the system achieves the triple goals of quantifiable abnormal impact, configurable waiting time, and interventionist community review, finding a dynamic balance between the immutability of blockchain and the need for security upgrades, providing fault tolerance and a foundation of trust for the continuous evolution of smart contracts.

[0157] Some of the data in the above formulas are numerical calculations with dimensions removed, and the contents not described in detail in this specification are all prior art known to those skilled in the art.

[0158] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A blockchain-based digital archive management system, characterized in that: include, The extraction module is used to extract status sets based on behavioral statistics from the digital archives management system; The risk analysis module is used to locate text positions based on the normal set in the state set, predict semantic layer anomaly risks and permission risks, construct a control flow graph to assess structural layer anomaly risks, and summarize and generate risk signals. The correlation analysis module is used, based on the risk analysis module, to analyze the operational threat status of Solidity contracts in the digital file management system and determine the activation of the Solidity contract correction mechanism; The impact module is used to initiate the Solidity contract correction mechanism and analyze the impact of abnormal situations on the Solidity contract operation. The waiting setting module is used to set the waiting period for the time lock; The extraction module includes an extraction unit 1, an extraction unit 2, and a judgment and storage unit; Extraction Unit 1 is used to extract Solidity contracts, on-chain transaction information, and contract status information from the digital file management system using a blockchain explorer. The on-chain transaction information includes transaction parameters, participant information, transaction content, and transaction status; the contract status information includes basic contract information, file management-related status, global status variables, event logs, and status change history. The second extraction unit is used to extract behavioral statistics from on-chain transaction information and contract status information. The behavioral statistics include the frequency of user operations on files, the distribution entropy of operation time periods, the average file access traffic, and the proportion of user operations in the corresponding time period to the total number of operations. The judgment and storage unit is used to obtain the threshold range of each feature in the behavior statistics information based on historical data, compare the corresponding feature in the behavior statistics information with its corresponding threshold range, and if it exceeds the threshold range, it is initially determined that the user behavior is abnormal. The features that exceed the threshold range are counted to generate an abnormal set and the abnormal set is stored in the local state database. If it does not exceed the threshold range, it is initially determined that the user behavior is not abnormal, and the features that do not exceed the threshold range are counted to generate a normal set. The normal set and the abnormal set are combined to obtain the state set; The risk analysis module includes semantic units, structural units, permission verification units, and fusion analysis units; The semantic unit is used to extract the normal set from the state set and locate the text corresponding to each feature in the normal set. The corresponding text is determined, and the BERT token segmenter is used to convert the text into a token sequence. The token sequence is then mapped to a semantic vector by the BERT model. Each token corresponds to a 768-dimensional vector. Based on the 768-dimensional vector corresponding to each token, a sentence-level vector is obtained. The sentence-level vector is then input into the fully connected layer added to the output layer of the BERT model to train the differentiation between normal intent and hidden intent, predict the probability of hidden intent, and use the probability of hidden intent as the semantic layer anomaly risk score. The structural unit is used to parse Solidity contract code into an abstract syntax tree. The parsed abstract syntax tree contains function call nodes, condition judgment nodes, and variable operation nodes. Based on the abstract syntax tree, code segments that execute sequentially, without branches, and without jumps are marked as basic blocks. Directed edges between basic blocks are determined based on their jump relationships to construct a control flow graph. Statistical parameter sets are obtained from the control flow graph to analyze the vulnerability risks caused by code complexity and calculate the code complexity index. The specific formula is as follows: In the formula, As a code complexity metric, This represents the number of conditional statements in the code. The total number of all executable statements in the code. This represents the number of times an external contract is called within a Solidity contract. The total number of functions defined in a Solidity contract. This represents the proportion of conditional statements in the code. The average number of external calls for each function reflects the frequency of interactions between contracts; code complexity metrics are used as a structural layer anomaly risk score. Each node in the abstract syntax tree represents a structure in the source code; The waiting configuration module includes a configuration unit and an execution management unit; The setting unit is used to score the degree of impact and set the time lock waiting period, specifically: Where T is the time lock waiting period, e is the Euler number, and RS is the impact score; the time lock waiting period is used to set a mandatory delay time for the Solidity contract.

2. The blockchain-based digital archive management system according to claim 1, characterized in that: The permission verification unit is used to obtain the permission set of the corresponding user and the permission requirement set corresponding to the corresponding operation in the normal set according to the Solidity contract. The specific expressions are as follows: and Where P is the user's set of permissions. The set of permission requirements corresponding to the operation. to The corresponding operations authorized by the user. to For the user group authorized for the corresponding operation, based on the user's permission set and the permission requirement set corresponding to the operation, check the user permissions of the corresponding users in the normal set involved in the normal operation. If the corresponding user in the normal set does not appear in the permission requirement set corresponding to the operation, it is determined that the operation of the corresponding user in the normal set has an unauthorized exception. The number of operations with unauthorized exceptions is counted, and the ratio of the number of operations with unauthorized exceptions to the total number of operations is calculated to obtain the permission risk score. The semantic layer anomaly risk score, the structural layer anomaly risk score, and the permission risk score are combined to generate a risk signal.

3. A blockchain-based digital archive management system according to claim 2, characterized in that: The fusion analysis unit normalizes the parameters in the risk signal using the max-min normalization method. It then obtains a comprehensive risk score by weighted summation of the processed semantic layer anomaly risk score, structural layer anomaly risk score, and permission risk score. The comprehensive risk score is compared with a pre-set scoring threshold. If the comprehensive risk score exceeds the scoring threshold, it is determined that there is a real anomaly, and the normal set is included in the anomaly set.

4. A blockchain-based digital archive management system according to claim 3, characterized in that: The correlation analysis module includes an acquisition unit, a threat analysis unit, a condition unit, and a mechanism activation unit; The acquisition unit is used to statistically analyze the parameters subject to constraints in the Solidity contract to obtain a set of contract information. Based on the fusion analysis unit, it extracts the parameters involved in the anomaly set to obtain a set of abnormal operation information. The threat analysis unit analyzes whether the current anomaly threatens the operation of the Solidity contract based on the set of abnormal operation information and the set of contract information, in order to calculate the data dependency corresponding to the user operation. The specific formula is as follows: ,in, For data dependency, This is a collection of abnormal operation information. A collection of contract information. The number of elements in the intersection; The association judgment unit is used to compare the data dependency with the average value of previous data dependencies to generate threat outcome information.

5. A blockchain-based digital archive management system according to claim 4, characterized in that: The condition unit is used to determine the abnormal conditions preset by the Solidity contract. Based on the attributes of the abnormal conditions preset by the Solidity contract, it extracts the parameters corresponding to the abnormal conditions preset by the Solidity contract from the abnormal operation information set. After condition comparison, it determines whether the abnormal operation triggers the abnormal conditions preset by the Solidity contract and generates condition result information. The mechanism activation unit is used to determine whether to activate the Solidity contract correction mechanism based on threat outcome information and condition outcome information. Specifically: If the data dependency does not exceed the average of previous data dependencies, the threat result information is that there is no threat; otherwise, the threat result information is that there is a threat. If the threat outcome information indicates that a threat exists or the condition outcome information indicates that the conditions are met, the Solidity contract correction mechanism will be activated. The condition result information includes those that do not meet the conditions and those that meet the conditions.

6. A blockchain-based digital archive management system according to claim 5, characterized in that: The impact module includes a data extraction unit and an evaluation unit; The data extraction unit is used to extract the duration of the abnormal operation and the number of Solidity contract functional modules affected from the abnormal operation information set, and generate impact data by combining the data dependency corresponding to the user operation, and obtain normalized impact data by using the max-min normalization method. The evaluation unit is used to analyze the impact of the current anomaly on the operation of the Solidity contract based on the normalized impact data. The impact score is obtained by weighted summation and is used to set the time lock waiting period.

7. A blockchain-based digital archive management system according to claim 1, characterized in that: The execution management unit is used to reserve review time for community members based on the time lock waiting period. If no abnormality is found by the community member during the waiting period, the corresponding user is allowed to continue execution; otherwise, a rejection signal is triggered to stop the corresponding user from executing the operation.

Images