A network security log archiving method based on blockchain verification

Abstract

The application discloses a network security log evidence storage method based on blockchain verification, which comprises the following steps: collecting original logs and structuring them, generating standardized log records and a log hash set; extracting time window statistical features, constructing a log feature vector and inputting an improved OCSVM model, and outputting a log abnormal risk degree; according to the log abnormal risk degree, generating a configuration matrix to obtain a strategy identifier; embedding a honeypot log hash and generating a time sequence evidence, respectively constructing three types of Merkle tree structures to obtain log three-type root values; generating a unique anchor identifier and combining the three-type root values to construct a conflict-detectable evidence header, and submitting the evidence header to a blockchain consensus for writing; triggering a honeypot challenge verification according to the evidence strength, and verifying the consistency of the Merkle path. The application realizes unique log evidence storage, integrity detection and strength self-adaptation of network security logs through the conflict-detectable evidence header, OCSVM abnormal risk driven evidence storage and honeypot challenge verification.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a network security log storage method based on blockchain verification. Background Technology

[0002] As network information systems continue to expand, network devices, servers, and security systems generate a large amount of network security logs during operation. These logs record information such as access behavior, security events, system status, and abnormal operations. Network security logs play a crucial role in security auditing, incident tracing, and compliance supervision. Therefore, reliable notarization of log data is necessary to ensure the authenticity, integrity, and immutability of log content during subsequent audits. Existing technologies typically employ log hash digests, centralized log storage, and blockchain-based notarization to protect logs. Among these, writing log data or log hashes to a blockchain ledger leverages the immutability of the blockchain to achieve log notarization, thereby enhancing the credibility of the log data.

[0003] However, most existing blockchain-based log evidence preservation technologies achieve log immutability simply by uploading log files or log hash values ​​to the blockchain, which still has certain limitations in practical applications. For example, attackers can generate multiple different versions of log data for the same time period and submit them to different entities for evidence preservation, creating multiple legitimate records and then denying version verification during subsequent audits. During the log generation and evidence preservation process, some key log records may be selectively deleted or tampered with. Since the blockchain only records the final submitted log summary, it is difficult to detect such selective deletion and modification in a timely manner, affecting the reliability of log audits. Existing log evidence preservation mechanisms typically employ fixed evidence preservation strategies and cannot dynamically adjust the evidence preservation strength according to the degree of abnormality in log behavior. When the log anomaly risk is high, the evidence preservation strength cannot be increased in a timely manner, while when the log risk is low, it will cause unnecessary evidence preservation overhead, resulting in low utilization efficiency of system storage and computing resources.

[0004] Therefore, how to provide a blockchain-based method for storing network security logs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] One objective of this invention is to propose a blockchain-based method for storing network security logs. This invention introduces a conflict-detectable header mechanism, a multi-dimensional adaptive mapping mechanism for evidence strength driven by log anomaly risk assessment based on an improved OCSVM model, and a honey-label log challenge verification mechanism. It performs unique version evidence storage, anomaly-driven adaptive evidence storage, and selective deletion / modification behavior detection and verification on network security logs. The invention details the implementation method for achieving trusted log evidence storage and verifiable auditing in a blockchain environment. It possesses the advantages of verifiable log version uniqueness, detectable log integrity, and adaptive adjustment of evidence storage strategies, thereby improving the authenticity, integrity, and audit credibility of network security log evidence storage.

[0006] A method for storing network security logs based on blockchain verification according to an embodiment of the present invention includes: The raw logs generated by network security devices are collected and preprocessed to generate standardized log records. The log hash value of each standardized log record is calculated and a log hash set is generated. Within a preset time window, statistical features are extracted from standardized log records, log feature vectors are constructed, and the improved OCSVM model is input for anomaly risk assessment to obtain the log anomaly risk level. Based on the log anomaly risk level, perform multi-dimensional evidence strength mapping to generate an evidence strength configuration matrix and perform hash operation to obtain the policy identifier; Embed honeymark log hash values ​​generated based on blockchain random seeds into the log hash set. Perform verifiable delayed chain operations in sequence based on the honeymark log hash values ​​to generate a time-series evidence sequence. Construct Merkle trees for the log hash set, the time-series evidence sequence, and the log coding block set obtained by erasure coding, respectively, to generate log content root, log relationship root, and log availability root. A unique anchor identifier is generated based on the log batch identifier, blockchain random number and device set identifier. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, hash value of the previous batch of evidence header and time identifier are combined to generate a conflict-detectable evidence header. The conflict-detectable evidence header is submitted to the blockchain network for consensus verification and written into the blockchain. The blockchain smart contract triggers the log challenge verification process according to the challenge verification frequency in the evidence strength configuration matrix, randomly selects the honeymark log hash and verifies the existence of the honeymark log hash in the Merkle tree, and records the verification result in the blockchain.

[0007] Optionally, the original logs include security event records, network access records, and system operation records generated during the operation of network security devices. The network security devices include firewalls, intrusion detection systems, intrusion prevention systems, virtual private network gateways, server hosts, and database auditing devices.

[0008] Optionally, the preprocessing of the raw logs includes time format unification processing, field parsing and standardization processing, abnormal character cleaning processing, and log field structure mapping processing, converting the raw logs into standardized log records containing device identifier, timestamp, source address, destination address, communication protocol, port number, and event type fields.

[0009] Optionally, the step of calculating the log hash value for each standardized log record and generating a log hash set includes concatenating the fields of device identifier, timestamp, source address, destination address, communication protocol, port number, event type, and original log content in a preset order to form corresponding data to be hashed, performing hash operations on the data to be hashed to obtain log hash values ​​that correspond one-to-one with each standardized log record, and arranging the log hash values ​​in the order of timestamps to generate a log hash set.

[0010] Optionally, obtaining the log anomaly risk level includes: Standardized log records are aggregated within a preset time window. The frequency of access to source address, destination address, port, protocol, event type, alarm level, number of session identifier changes, and log burstiness are statistically analyzed according to the time order of the logs within the window, generating log feature vectors that correspond one-to-one with the time window. Multiple time windows of historical normal operation periods are selected, and corresponding log feature vectors are constructed for each time window to form a normal feature set. Missing value imputation, outlier truncation and feature scale unification are performed on the normal feature set to generate a standardized training feature set. An improved OCSVM model is constructed based on a standardized training feature set. The improved OCSVM model consists of a three-layer structure, including: The log behavior embedding layer performs discrete binning encoding, feature hash mapping, and window-level behavior statistical fusion processing on the log feature vector, converting discrete and continuous statistical features into behavior embedding vectors of a unified dimension. The behavior embedding vectors are then normalized to generate embedded feature vectors. The temporal drift constraint boundary learning layer constructs a dual-kernel OCSVM boundary learning structure on the embedded feature vectors corresponding to the standardized training feature set. It learns the boundary of normal log behavior by using the radial basis kernel OCSVM sub-model and the polynomial kernel OCSVM sub-model respectively, and calculates the behavior drift amount based on the change amplitude of the embedded feature vectors within the continuous time window. The behavior drift amount is used as a temporal constraint factor to adjust the consistency of the boundary deviation scores output by the two OCSVM sub-models to obtain the fused boundary score. The chain-state adaptive risk quantification layer is based on the normal distribution range of the statistical fusion boundary score of the standardized training feature set. The upper and lower boundaries of the normal distribution range are used as the risk benchmark range. The fusion boundary score corresponding to the current time window is normalized within the risk benchmark range. The blockchain storage status parameter is introduced to dynamically correct the normalization result, and the log anomaly risk level with a value range of zero to one is obtained. The log feature vector generated in the current time window is processed using the same feature scaling as during the training phase and then input into the improved OCSVM model. The model passes through the log behavior embedding layer, the temporal drift constraint boundary learning layer, and the chain-state adaptive risk quantization layer in sequence to obtain the log anomaly risk level corresponding to the current time window.

[0011] Optionally, the step of generating the evidence strength configuration matrix and performing a hash operation to obtain the policy identifier includes: Obtain the log anomaly risk level and bind it to the current time window identifier; Establish a benchmark vector for evidence storage strength, which includes a benchmark interval for the log evidence storage window length, a benchmark interval for erasure coding redundancy rate, a benchmark interval for blockchain challenge verification frequency, a benchmark interval for honey label log generation density, and a benchmark interval for witness node threshold signature threshold value. Store each benchmark interval in correspondence with the maximum and minimum values ​​of the corresponding parameters. Based on the log anomaly risk level, target values ​​for each parameter are generated within each baseline interval, specifically as follows: When the risk of log anomalies increases, the log evidence window length decreases monotonically within the baseline range, the erasure coding redundancy rate increases monotonically within the baseline range, the blockchain challenge verification frequency increases monotonically within the baseline range, the honey label log generation density increases monotonically within the baseline range, and the witness node threshold signature threshold value increases monotonically within the baseline range. Perform cross-parameter coupling consistency checks on the target values ​​of each parameter: The upper limit of challenge verification frequency is determined based on erasure coding redundancy rate; the lower limit of honey label log generation density is determined based on log storage window length; the upper limit of block confirmation latency tolerance is determined based on witness node threshold signature threshold value; and when any parameter target value exceeds the corresponding matching range, a linkage callback correction is performed on the parameter target value to generate a parameter set that satisfies cross-parameter consistency constraints. The log storage window length, erasure coding redundancy rate, blockchain challenge verification frequency, honey label log generation density, and witness node threshold signature threshold value that satisfy cross-parameter consistency constraints are arranged in a preset order to form a storage strength configuration matrix. The storage strength configuration matrix is ​​then hashed to obtain the policy identifier.

[0012] Optionally, the generation of the log content root, log relationship root, and log availability root includes: Obtain the log hash set, honeymark log generation density, and erasure coding redundancy rate; read the blockchain random seed and generate a honeymark index sequence based on the blockchain random seed; insert the corresponding number of honeymark log hash values ​​into the log hash set according to the honeymark index sequence to obtain the extended log hash set. The extended log hash set is subjected to hierarchical rearrangement. The extended log hash set is grouped by device identifier and sorted by timestamp within each group. The sequence within each group is constructed into a Merkle subtree. The root values ​​of the Merkle subtrees within each group are concatenated in the order of device identifier to form a device root sequence. Then, a cross-device Merkle tree is constructed on the device root sequence to obtain the log content root. Generate a time-series evidence sequence in chronological order for the extended log hash set. Use the previous time-series evidence value, the current log hash value, and the current log's sequence number in the extended log hash set as inputs, perform continuous iterative hash operations to obtain the current time-series evidence value, and combine the time-series evidence values ​​corresponding to each log in chronological order to form a time-series evidence set. A relation leaf set is constructed by associating log hash values ​​and corresponding time-series evidence values ​​in the extended log hash set with the log hash values ​​and corresponding time-series evidence values. Each relation leaf in the relation leaf set is generated by the log hash value, the time-series evidence value and the device identifier corresponding to the log. A relation Merkle tree is constructed on the relation leaf set to obtain the log relation root. The original log data corresponding to the extended log hash set is divided into a log data block set according to a preset block size. The log data block set is then subjected to erasure coding based on the erasure coding redundancy rate to generate a log coding block set. An availability Merkle tree is then constructed on the log coding block set to obtain the log availability root.

[0013] Optionally, submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it to the blockchain includes: Obtain the log content root, log relationship root, and log availability root, as well as the policy identifier. At the same time, read the current log batch identifier, the set of device identifiers that participated in generating the log, and the random number of the current block of the blockchain network. Then, concatenate the set of device identifiers according to the order of the device identifiers to obtain the device set identifier. A unique anchor identifier is generated based on the log batch identifier, the blockchain random number, and the device set identifier, and a one-to-one correspondence is established between the unique anchor identifier and the current log batch. Perform multi-root coupling verification processing on the log content root, log relation root and log availability root. Verify the sequential consistency of each log hash value in the log content root according to the time-series evidence sequence contained in the log relation root, and verify the coverage integrity of the log hash values ​​in the log content root according to the coded block index corresponding to the log availability root. Generate multi-root consistency identifier when both sequential consistency and coverage integrity are satisfied. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, multi-root consistency identifier, hash value of the previous batch of evidence header, and current time identifier are concatenated according to the preset field order, and a hash operation is performed on the concatenated data to generate a conflict-detectable evidence header. The conflict-detectable evidence header is sent to the set of witness nodes in the blockchain network for threshold signature verification. If the threshold signature threshold of the witness nodes is met, the conflict-detectable evidence header is submitted to the blockchain network for consensus verification. The blockchain ledger checks whether there is a record with the same unique anchor identifier but different log content. If it exists, it is determined to be a log evidence conflict event and the conflict identifier is recorded. If it does not exist, the conflict-detectable evidence header is written into a new block and the blockchain ledger is updated.

[0014] Optionally, submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it to the blockchain includes: Read the honeymark index sequence, extended log hash set, and log content root to obtain the conflict detection header and unique anchor identifier of the corresponding log batch from the blockchain ledger; Based on the honeymark index sequence, locate the corresponding honeymark log hash value in the extended log hash set, and generate the corresponding Merkel path proof set according to the position of the honeymark log hash value in the Merkel tree of the log content. The verification root value is recalculated using the honeymark log hash value and the corresponding Merkel path proof set. The verification root value is obtained by concatenating the honeymark log hash value and the sibling node hash values ​​in the path proof set in the path order and performing a hash operation. The verification root value is then compared with the log content root recorded in the blockchain ledger for consistency. When the verification root value is consistent with the log content root in the blockchain ledger, it is determined that the path of the corresponding honeymark log in the log content Merkle tree is complete, and the consistency of the corresponding time-series evidence value in the log relation root is verified based on the sequence number of the honeymark log in the extended log hash set. The log evidence integrity index is calculated based on the verification results of the honeymark logs. The log evidence integrity index is calculated according to the ratio of the number of successfully verified honeymark logs to the total number of challenge honeymark logs. When the log evidence integrity index is lower than a preset threshold, it is determined that the corresponding log batch has selective deletion or tampering behavior, and an abnormal verification mark is recorded in the blockchain ledger.

[0015] The beneficial effects of this invention are: This invention introduces a conflict-detectable header mechanism into the log evidence storage structure. It combines the log content root, log relationship root, and log availability root with a unique anchor identifier, a policy identifier, and the hash value of the previous batch of evidence headers to generate an evidence header. Consensus verification is then performed on the blockchain network, ensuring that only one valid evidence record is generated for each log batch in the blockchain ledger. When different versions of the same log batch are constructed and attempted to be submitted repeatedly, the unique anchor identifier and multi-root coupled verification mechanism can quickly identify and record conflicting evidence, effectively avoiding the log version repudiation problem that may occur in existing technologies, and improving the uniqueness and credibility of the log evidence storage results.

[0016] This invention assesses the anomaly risk of network security logs by constructing an improved OCSVM model. It maps the log anomaly risk level to multiple evidence storage parameters, such as log storage window length, erasure coding redundancy rate, blockchain challenge verification frequency, and honeytag log generation density, forming a dynamically adjustable evidence storage strength configuration matrix. This allows the log evidence storage strategy to adaptively adjust based on changes in log behavior. When the log anomaly risk increases, the evidence storage strength is automatically increased; conversely, when log behavior is stable, unnecessary evidence storage overhead is reduced. This ensures the reliability of log evidence storage while reducing system storage and computing resource consumption, thereby improving the overall operational efficiency of the blockchain evidence storage system.

[0017] This invention embeds honey-labeled logs into a log hash set and constructs a log relationship Merkle tree and a log availability Merkle tree. Combined with a honey-labeled log challenge verification mechanism, it can proactively initiate random challenge verification during the audit process. By verifying the consistency of honey-labeled log path proof and time-series evidence, it can determine whether there is selective deletion or tampering of logs. It achieves efficient detection of log integrity without relying on complete log replay, thereby improving the network security log evidence storage system's ability to detect log deletion and modification behaviors and its audit credibility. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a network security log storage method based on blockchain verification proposed in this invention; Figure 2 This is a schematic diagram of the log anomaly risk assessment process based on the improved OCSVM model, which is a network security log notarization method based on blockchain verification proposed in this invention. Detailed Implementation

[0019] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0020] refer to Figure 1 and Figure 2 A blockchain-based method for storing network security logs includes: The raw logs generated by network security devices are collected and preprocessed to generate standardized log records. The log hash value of each standardized log record is calculated and a log hash set is generated. Within a preset time window, statistical features are extracted from standardized log records, log feature vectors are constructed, and the improved OCSVM model is input for anomaly risk assessment to obtain the log anomaly risk level. Based on the log anomaly risk level, perform multi-dimensional evidence strength mapping to generate an evidence strength configuration matrix and perform hash operation to obtain the policy identifier; Embed honeymark log hash values ​​generated based on blockchain random seeds into the log hash set. Perform verifiable delayed chain operations in sequence based on the honeymark log hash values ​​to generate a time-series evidence sequence. Construct Merkle trees for the log hash set, the time-series evidence sequence, and the log coding block set obtained by erasure coding, respectively, to generate log content root, log relationship root, and log availability root. A unique anchor identifier is generated based on the log batch identifier, blockchain random number and device set identifier. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, hash value of the previous batch of evidence header and time identifier are combined to generate a conflict-detectable evidence header. The conflict-detectable evidence header is submitted to the blockchain network for consensus verification and written into the blockchain. The blockchain smart contract triggers the log challenge verification process according to the challenge verification frequency in the evidence strength configuration matrix, randomly selects the honeymark log hash and verifies the existence of the honeymark log hash in the Merkle tree, and records the verification result in the blockchain.

[0021] In this embodiment, the original log includes security event records, network access records, and system operation records generated during the operation of network security devices. The network security devices include firewalls, intrusion detection systems, intrusion prevention systems, virtual private network gateways, server hosts, and database auditing devices. The original log includes device identification information, event occurrence time, source address, destination address, communication protocol, port information, event type, and original log content fields.

[0022] In this embodiment, the preprocessing of the raw log includes time format unification processing, field parsing and standardization processing, abnormal character cleaning processing, and log field structure mapping processing, converting the raw log into a standardized log record containing device identifier, timestamp, source address, destination address, communication protocol, port number, and event type fields.

[0023] In this embodiment, calculating the log hash value for each standardized log record and generating a log hash set includes concatenating the fields of device identifier, timestamp, source address, destination address, communication protocol, port number, event type, and original log content in a preset order to form corresponding data to be hashed, performing hash operations on the data to be hashed to obtain log hash values ​​that correspond one-to-one with each standardized log record, and arranging the log hash values ​​in the order of timestamps to generate a log hash set.

[0024] In this embodiment, obtaining the log anomaly risk level includes: Standardized log records are aggregated within a preset time window. Statistics are then compiled based on the logs' chronological order within the window, including source address access frequency, destination address access frequency, port access frequency, protocol distribution, event type distribution, alarm level distribution, session identifier change frequency, and log burstiness. This generates log feature vectors that correspond one-to-one with the time window. The preset time window is initially set to 120 seconds. When the number of log entries per unit time exceeds a preset threshold, the preset time window is shortened to 60 seconds; when the number of log entries per unit time is below the preset threshold, the preset time window is adjusted to 180 seconds. Multiple time windows of historical normal operation periods are selected, and corresponding log feature vectors are constructed for each time window to form a normal feature set. Missing value imputation, outlier truncation and feature scale unification are performed on the normal feature set to generate a standardized training feature set. An improved OCSVM model is constructed based on a standardized training feature set. The improved OCSVM model consists of a three-layer structure, including: The log behavior embedding layer performs discrete binning encoding, feature hashing mapping, and window-level behavior statistical fusion processing on the log feature vectors, converting discrete and continuous statistical features into behavior embedding vectors of uniform dimension. These behavior embedding vectors are then normalized to generate embedded feature vectors, where: Discrete binning coding: Based on the historical distribution range of continuous features statistically analyzed from the normal feature set, the source address access frequency, destination address access frequency, port access frequency, and log burstiness are divided into multiple numerical intervals, and a corresponding code is assigned to each interval. When a feature value falls into the corresponding interval, the interval code is used as the discrete representation of the feature. Feature hash mapping: The features after discrete binning and encoding are processed together with the original discrete features. Each feature field and its value are concatenated to generate a feature identifier. The feature identifier is hashed to obtain the index position and mapped to a feature space of preset dimension to generate a feature vector representation of fixed dimension. Window-level behavior statistics fusion: Within a preset time window, log features generated by the same device or source address are aggregated and statistically analyzed. Access frequency features are accumulated, and the distribution of protocols, event types, and alarm levels are statistically analyzed. The statistical results are combined in a preset order to form a window-level behavior statistics vector, which is then concatenated with the feature hash mapping results to generate a behavior embedding vector. The temporal drift constraint boundary learning layer constructs a dual-kernel OCSVM boundary learning structure on the embedded feature vectors corresponding to the standardized training feature set. It learns the normal log behavior boundary using both a radial basis function kernel OCSVM sub-model and a multinomial kernel OCSVM sub-model. The behavior drift is calculated based on the magnitude of change in the embedded feature vectors within a continuous time window. This behavior drift is used as a temporal constraint factor to adjust the consistency of the boundary deviation scores output by the two OCSVM sub-models, resulting in a fused boundary score. Specifically, the normal log behavior boundary is learned using both the radial basis function kernel OCSVM sub-model and the multinomial kernel OCSVM sub-model. The embedded feature vectors corresponding to the standardized training feature set are input into the radial basis kernel OCSVM sub-model and the polynomial kernel OCSVM sub-model for training. In the radial basis kernel OCSVM sub-model, the similarity relationship between the embedded feature vectors is calculated through the radial basis kernel function, and a boundary surface surrounding the normal log behavior samples is constructed in the feature space. In the polynomial kernel OCSVM sub-model, the embedded feature vectors are mapped to a high dimension through the polynomial kernel function, and the normal log behavior boundary is constructed in the mapped feature space. In the model prediction stage, the distance values ​​from the current embedded feature vector to the two boundary surfaces are calculated respectively, and the distance values ​​are used as the boundary deviation scores of the corresponding sub-model. Consistency adjustment is applied to boundary deviation scores, specifically as follows: The behavior drift is calculated based on the change magnitude of the embedded feature vector within the continuous time window. The behavior drift is mapped to the temporal constraint coefficient. When the behavior drift increases, the consistency weight of the boundary deviation scores of the two OCSVM sub-models is increased. When the behavior drift decreases, the consistency weight is decreased while the score difference between the two sub-models is retained. The boundary deviation scores output by the radial basis kernel OCSVM sub-model and the polynomial kernel OCSVM sub-model are weighted and fused according to the temporal constraint coefficient to obtain the fused boundary score. The chain-state adaptive risk quantification layer is based on the normal distribution range of the statistical fusion boundary score according to the standardized training feature set. Using the upper and lower boundaries of the normal distribution range as the risk benchmark range, the fusion boundary score corresponding to the current time window is normalized within the risk benchmark range. Blockchain evidence storage status parameters are introduced to dynamically correct the normalization result. These parameters include block confirmation latency, on-chain challenge verification success rate, and evidence storage capacity utilization rate, resulting in a log anomaly risk level ranging from zero to one. Specifically, the introduction of blockchain evidence storage status parameters to dynamically correct the normalization result involves: The system acquires the block confirmation latency, on-chain challenge verification success rate, and evidence storage capacity utilization rate of the blockchain network in real time. It standardizes these parameters to generate a chain state vector and calculates the chain state correction coefficient based on the chain state vector. When the block confirmation latency increases or the evidence storage capacity utilization rate increases, the risk weight corresponding to the normalized result is increased. When the on-chain challenge verification success rate decreases, the abnormal risk correction magnitude is increased. The chain state correction coefficient is used to adjust the normalized result proportionally to obtain the log abnormal risk level after dynamic correction of the blockchain evidence storage status. The log feature vector generated in the current time window is processed using the same feature scaling as during the training phase and then input into the improved OCSVM model. The model passes through the log behavior embedding layer, the temporal drift constraint boundary learning layer, and the chain-state adaptive risk quantization layer in sequence to obtain the log anomaly risk level corresponding to the current time window.

[0025] In this embodiment, the step of generating the evidence storage strength configuration matrix and performing a hash operation to obtain the policy identifier includes: Obtain the log anomaly risk level and bind it to the current time window identifier; A baseline vector for evidence storage strength is established, comprising a baseline interval for the log evidence storage window length, a baseline interval for erasure coding redundancy rate, a baseline interval for blockchain challenge verification frequency, a baseline interval for honey label log generation density, and a baseline interval for witness node threshold signature threshold value. Each baseline interval is then stored in a one-to-one correspondence with the maximum and minimum values ​​of its corresponding parameters. Log evidence window length: Based on the historical log generation rate, the distribution of the number of log entries per unit time is statistically analyzed, and the log batch generation cycle is determined in combination with the blockchain block confirmation time. The time range that can ensure the stability of the number of logs in a single batch and does not exceed the upper limit of the blockchain write load is used as the benchmark range for the log evidence window length. Erasure coding redundancy rate: The minimum fault tolerance recovery ratio is determined based on the number of log storage nodes and the statistical results of the node's historical failure rate. The maximum redundancy ratio is determined in combination with the upper limit of the system's available storage capacity. The range of redundancy ratios that ensures log data can still be recovered in the event of node failure is taken as the benchmark range of erasure coding redundancy rate. Blockchain challenge verification frequency: The minimum triggering period for challenge verification is determined based on the average block generation time of the blockchain and the statistical results of smart contract execution latency, and the maximum triggering frequency is determined based on the processing capacity of the blockchain network, forming a benchmark range for blockchain challenge verification frequency; Honeymark log generation density: The minimum insertion ratio of honeymark logs is determined based on the statistical results of the number of logs within a unit time window and the minimum detection probability required for log integrity detection. The maximum insertion ratio is determined in combination with the system log processing overhead limit, forming a benchmark range for honeymark log generation density. Witness node threshold signature threshold: The minimum signature threshold is determined based on the number of witness nodes participating in the evidence verification in the blockchain network and the system's security fault tolerance ratio. The maximum signature threshold is determined by combining node communication overhead and signature verification efficiency, forming a benchmark range for the witness node threshold signature threshold. Based on the log anomaly risk level, target values ​​for each parameter are generated within each baseline interval, specifically as follows: When the risk of log anomalies increases, the log evidence window length decreases monotonically within the baseline range, the erasure coding redundancy rate increases monotonically within the baseline range, the blockchain challenge verification frequency increases monotonically within the baseline range, the honey label log generation density increases monotonically within the baseline range, and the witness node threshold signature threshold value increases monotonically within the baseline range. Perform cross-parameter coupling consistency checks on the target values ​​of each parameter: The upper limit of challenge verification frequency is determined based on erasure coding redundancy rate; the lower limit of honey label log generation density is determined based on log storage window length; the upper limit of block confirmation latency tolerance is determined based on witness node threshold signature threshold value; and when any parameter target value exceeds the corresponding matching range, a linkage callback correction is performed on the parameter target value to generate a parameter set that satisfies cross-parameter consistency constraints. The log evidence storage window length, erasure coding redundancy rate, blockchain challenge verification frequency, honey tag log generation density, and witness node threshold signature threshold value, which satisfy cross-parameter consistency constraints, are arranged in a preset order to form an evidence storage strength configuration matrix. The evidence storage strength configuration matrix is ​​hashed to obtain the policy identifier, where the preset order is log evidence storage window length, erasure coding redundancy rate, blockchain challenge verification frequency, honey tag log generation density, and witness node threshold signature threshold value.

[0026] In this embodiment, the generation of log content root, log relationship root, and log availability root includes: Obtain the log hash set, honeymark log generation density, and erasure coding redundancy rate; read the blockchain random seed and generate a honeymark index sequence based on the blockchain random seed; insert the corresponding number of honeymark log hash values ​​into the log hash set according to the honeymark index sequence to obtain the extended log hash set. The extended log hash set is subjected to hierarchical rearrangement. The extended log hash set is grouped by device identifier and sorted by timestamp within each group. The sequence within each group is constructed into a Merkle subtree. The root values ​​of the Merkle subtrees within each group are concatenated in the order of device identifier to form the device root sequence. Then, a cross-device Merkle tree is constructed on the device root sequence to obtain the log content root. The cross-device Merkle tree uses the root node of the Merkle subtree corresponding to each device as the leaf node. After arranging in the order of device identifier, adjacent leaf nodes are merged pairwise to generate a parent node. This process is repeated layer by layer upwards until the root node is obtained. Generate a time-series evidence sequence in chronological order for the extended log hash set. Use the previous time-series evidence value, the current log hash value, and the current log's sequence number in the extended log hash set as inputs, perform continuous iterative hash operations to obtain the current time-series evidence value, and combine the time-series evidence values ​​corresponding to each log in chronological order to form a time-series evidence set. A relation leaf set is constructed by associating log hash values ​​and corresponding time-series evidence values ​​in the extended log hash set. Each relation leaf in the relation leaf set is generated by the log hash value, the time-series evidence value, and the device identifier corresponding to the log. A relation Merkle tree is constructed on the relation leaf set to obtain the log relation root. The relation Merkle tree is constructed by merging adjacent relation leaves in pairs to generate parent nodes and merging them layer by layer upwards until the root node is obtained. The original log data corresponding to the extended log hash set is divided into a log data block set according to a preset block size. The log data block set is then subjected to erasure coding based on the erasure coding redundancy rate to generate a log coded block set. An availability Merkle tree is constructed on the log coded block set to obtain the log availability root. The availability Merkle tree generates leaf nodes by combining the block index of the coded block with the content of the coded block, and is constructed by merging adjacent leaf nodes one by one and merging them upwards layer by layer until the root node is obtained.

[0027] In this embodiment, submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it into the blockchain includes: Obtain the log content root, log relationship root, and log availability root, as well as the policy identifier. At the same time, read the current log batch identifier, the set of device identifiers that participated in generating the log, and the random number of the current block of the blockchain network. Then, concatenate the set of device identifiers according to the order of the device identifiers to obtain the device set identifier. A unique anchor identifier is generated based on the log batch identifier, the blockchain random number, and the device set identifier, and a one-to-one correspondence is established between the unique anchor identifier and the current log batch. Perform multi-root coupling verification processing on the log content root, log relation root and log availability root. Verify the sequential consistency of each log hash value in the log content root according to the time-series evidence sequence contained in the log relation root, and verify the coverage integrity of the log hash values ​​in the log content root according to the coded block index corresponding to the log availability root. Generate multi-root consistency identifier when both sequential consistency and coverage integrity are satisfied. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, multi-root consistency identifier, hash value of the previous batch of evidence header, and current time identifier are concatenated according to the preset field order, and a hash operation is performed on the concatenated data to generate a conflict-detectable evidence header. The conflict-detectable evidence header is sent to the set of witness nodes in the blockchain network for threshold signature verification. If the threshold signature threshold of the witness nodes is met, the conflict-detectable evidence header is submitted to the blockchain network for consensus verification. The blockchain ledger checks whether there is a record with the same unique anchor identifier but different log content. If it exists, it is determined to be a log evidence conflict event and the conflict identifier is recorded. If it does not exist, the conflict-detectable evidence header is written into a new block and the blockchain ledger is updated.

[0028] In this embodiment, submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it into the blockchain includes: Read the honeymark index sequence, extended log hash set, and log content root to obtain the conflict detection header and unique anchor identifier of the corresponding log batch from the blockchain ledger; Based on the honeymark index sequence, locate the corresponding honeymark log hash value in the extended log hash set, and generate the corresponding Merkle path proof set according to the position of the honeymark log hash value in the Merkle tree of the log content. The Merkle path proof set is composed of the hash values ​​of sibling nodes on the path from the leaf node to the root node. The verification root value is recalculated using the honeymark log hash value and the corresponding Merkel path proof set. The verification root value is obtained by concatenating the honeymark log hash value and the sibling node hash values ​​in the path proof set in the path order and performing a hash operation. The verification root value is then compared with the log content root recorded in the blockchain ledger for consistency. When the verification root value is consistent with the log content root in the blockchain ledger, it is determined that the path of the corresponding honeymark log in the log content Merkle tree is complete, and the consistency of the corresponding time-series evidence value in the log relation root is verified based on the sequence number of the honeymark log in the extended log hash set. The log evidence integrity index is calculated based on the verification results of the honeymark logs. The log evidence integrity index is calculated according to the ratio of the number of successfully verified honeymark logs to the total number of challenge honeymark logs. When the log evidence integrity index is lower than a preset threshold, it is determined that the corresponding log batch has selective deletion or tampering behavior, and an abnormal verification mark is recorded in the blockchain ledger.

[0029] Example 1: To verify the feasibility of this invention in practice, it was applied to a cloud data center. This data center primarily hosts business systems such as an enterprise e-commerce platform, user account system, payment system, and data analysis platform. Its network infrastructure includes application servers, database servers, security gateways, firewalls, intrusion detection systems, and log auditing servers. Actual operational statistics show that the data center has approximately 310 servers, 46 security devices, and 72 network switching devices. The number of network security logs generated daily fluctuates between 30 million and 38 million, with a log data size of approximately 48GB to 60GB. The logs are mainly used for network security incident auditing, system fault diagnosis, and abnormal behavior analysis; therefore, high requirements are placed on the integrity, authenticity, and traceability of the log data.

[0030] Before the system upgrade, the enterprise's data center used a traditional log storage method, which centrally stored log files on a log server and wrote them to a consortium blockchain ledger after calculating their hash values ​​for storage. However, this method revealed several problems during actual operation. For example, in a security exercise, the security team modified the log file content to regenerate a new log file and then stored it on the blockchain again; the system failed to recognize the existence of multiple versions of the log. In simulated attack tests, the traditional system also failed to recognize selective log deletion when some critical access logs were deleted and the log file was regenerated and stored. Because the system uses a fixed time period for logging to the blockchain, the pressure on the blockchain writes increases significantly during peak business access periods, while unnecessary resource consumption occurs during stable system operation, resulting in low operational efficiency for the log storage system.

[0031] To address the aforementioned issues, the log evidence preservation method proposed in this invention is deployed in the data center log auditing system. The system first performs unified preprocessing on raw logs generated from servers, firewalls, and intrusion detection systems to generate standardized log records, and then calculates log hash values ​​for these standardized log records to form a log hash set. In the log risk assessment phase, the system analyzes log characteristics based on an improved OCSVM model, which consists of a log behavior embedding layer, a temporal drift constraint boundary learning layer, and a chain-state adaptive risk quantification layer. By analyzing log behavior within each time window, the system can obtain the corresponding log anomaly risk level, which serves as the basis for adjusting the evidence preservation strategy.

[0032] After obtaining the log anomaly risk level, the system performs multi-dimensional evidence strength mapping, dynamically adjusting the log evidence window length, erasure coding redundancy rate, blockchain challenge verification frequency, and honeymark log generation density based on the log anomaly risk level. When the system detects abnormal log behavior, it automatically shortens the log evidence window and increases the number of honeymark logs to enhance log integrity verification capabilities. During the log evidence storage phase, honeymark log hash values ​​are embedded in the system's log hash set, and Merkle trees for log content, log relationships, and log availability are constructed, generating log content roots, log relationship roots, and log availability roots. Subsequently, the system combines these three types of root values ​​with the unique anchor identifier, policy identifier, and hash values ​​of the previous batch of evidence headers to generate a conflict-detectable evidence header and writes it to the blockchain network. When subsequent log auditing or security verification is performed, honeymark logs are randomly selected through the honeymark log challenge verification mechanism for Merkle path verification to detect whether the logs have been deleted or tampered with.

[0033] During three consecutive months of operational testing, the security team conducted multiple simulated attack tests on the system, including log tampering tests, log deletion tests, and dual-version log submission tests.

[0034] Table 1. Comparison of Operational Performance of Data Center Log Storage Systems Indicator Items Traditional blockchain log storage system Log storage method of the present invention Daily log count Approximately 34 million Approximately 34 million Daily average log data volume Approximately 55GB Approximately 55GB Daily average number of blockchain writes 6100 times 4900 times Average processing latency of log evidence 3.5 seconds 2.0 seconds Log version conflict detection capability Unable to detect Detectable and recordable Log deletion attack detection capability Unable to detect Detectable Challenge to verify average response time Not supported 1.3 seconds System storage overhead benchmark value Reduced by approximately 20% Adaptive capability of evidence preservation strategy Not supported support As shown in Table 1, under the same log scale, both log evidence storage methods process approximately 34 million log entries per day, totaling about 55GB of data. This indicates that the test environment was consistent, making the comparison results comparable. The method of this invention can stably complete log evidence storage processing under the same business load, demonstrating its good applicability and scalability in large-scale log scenarios.

[0035] From the perspective of system operating efficiency, traditional blockchain log storage systems perform an average of approximately 6,100 blockchain writes per day. In contrast, the method of this invention uses a multi-dimensional adaptive evidence strength mechanism to batch aggregate logs, reducing the average daily number of blockchain writes to approximately 4,900, a reduction of about 20%. The average processing latency for log storage is reduced from 3.5 seconds to 2.0 seconds, demonstrating a significant improvement in processing efficiency. This indicates that the method of this invention can effectively reduce blockchain write pressure and improve system operating efficiency while ensuring the security of log storage.

[0036] From a security auditing perspective, traditional systems cannot detect log version conflicts and log deletion attacks. This invention, however, utilizes a conflict-detectable evidence header mechanism and a honey-label log challenge verification mechanism to enable the system to identify dual-version log submissions and detect selective log deletion. The method supports a challenge verification mechanism with an average response time of approximately 1.3 seconds. While ensuring log integrity verification capabilities, it reduces system storage overhead by approximately 20%, achieves adaptive adjustment of the evidence storage strategy, and improves the security and resource utilization efficiency of the log evidence storage system.

[0037] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for storing network security logs based on blockchain verification, characterized in that, include: The raw logs generated by network security devices are collected and preprocessed to generate standardized log records. The log hash value of each standardized log record is calculated and a log hash set is generated. Within a preset time window, statistical features are extracted from standardized log records, log feature vectors are constructed, and the improved OCSVM model is input for anomaly risk assessment to obtain the log anomaly risk level. Based on the log anomaly risk level, perform multi-dimensional evidence strength mapping to generate an evidence strength configuration matrix and perform hash operation to obtain the policy identifier; Embed honeymark log hash values ​​generated based on blockchain random seeds into the log hash set. Perform verifiable delayed chain operations in sequence based on the honeymark log hash values ​​to generate a time-series evidence sequence. Construct Merkle trees for the log hash set, the time-series evidence sequence, and the log coding block set obtained by erasure coding, respectively, to generate log content root, log relationship root, and log availability root. A unique anchor identifier is generated based on the log batch identifier, blockchain random number and device set identifier. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, hash value of the previous batch of evidence header and time identifier are combined to generate a conflict-detectable evidence header. The conflict-detectable evidence header is submitted to the blockchain network for consensus verification and written into the blockchain. The blockchain smart contract triggers the log challenge verification process according to the challenge verification frequency in the evidence strength configuration matrix, randomly selects the honeymark log hash and verifies the existence of the honeymark log hash in the Merkle tree, and records the verification result in the blockchain.

2. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The original logs include security event records, network access records, and system operation records generated during the operation of network security devices. The network security devices include firewalls, intrusion detection systems, intrusion prevention systems, virtual private network gateways, server hosts, and database auditing devices.

3. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The preprocessing of the raw logs includes time format unification, field parsing and standardization, abnormal character cleaning, and log field structure mapping, converting the raw logs into standardized log records containing device identifier, timestamp, source address, destination address, communication protocol, port number, and event type fields.

4. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The process of calculating the log hash value for each standardized log record and generating a log hash set includes concatenating the fields of device identifier, timestamp, source address, destination address, communication protocol, port number, event type, and original log content in a preset order to form corresponding data to be hashed; performing hash operations on the data to be hashed to obtain log hash values ​​that correspond one-to-one with each standardized log record; and arranging the log hash values ​​in the order of timestamps to generate a log hash set.

5. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The obtained log anomaly risk level includes: Standardized log records are aggregated within a preset time window. The frequency of access to source address, destination address, port, protocol, event type, alarm level, number of session identifier changes, and log burstiness are statistically analyzed according to the time order of the logs within the window, generating log feature vectors that correspond one-to-one with the time window. Multiple time windows of historical normal operation periods are selected, and corresponding log feature vectors are constructed for each time window to form a normal feature set. Missing value imputation, outlier truncation and feature scale unification are performed on the normal feature set to generate a standardized training feature set. An improved OCSVM model is constructed based on a standardized training feature set. The improved OCSVM model consists of a three-layer structure, including: The log behavior embedding layer performs discrete binning encoding, feature hash mapping, and window-level behavior statistical fusion processing on the log feature vector, converting discrete and continuous statistical features into behavior embedding vectors of a unified dimension. The behavior embedding vectors are then normalized to generate embedded feature vectors. The temporal drift constraint boundary learning layer constructs a dual-kernel OCSVM boundary learning structure on the embedded feature vectors corresponding to the standardized training feature set. It learns the boundary of normal log behavior by using the radial basis kernel OCSVM sub-model and the polynomial kernel OCSVM sub-model respectively, and calculates the behavior drift amount based on the change amplitude of the embedded feature vectors within the continuous time window. The behavior drift amount is used as a temporal constraint factor to adjust the consistency of the boundary deviation scores output by the two OCSVM sub-models to obtain the fused boundary score. The chain-state adaptive risk quantification layer is based on the normal distribution range of the statistical fusion boundary score of the standardized training feature set. The upper and lower boundaries of the normal distribution range are used as the risk benchmark range. The fusion boundary score corresponding to the current time window is normalized within the risk benchmark range. The blockchain storage status parameter is introduced to dynamically correct the normalization result, and the log anomaly risk level with a value range of zero to one is obtained. The log feature vector generated in the current time window is processed using the same feature scaling as during the training phase and then input into the improved OCSVM model. The model passes through the log behavior embedding layer, the temporal drift constraint boundary learning layer, and the chain-state adaptive risk quantization layer in sequence to obtain the log anomaly risk level corresponding to the current time window.

6. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The process of generating the evidence storage strength configuration matrix and performing a hash operation to obtain the policy identifier includes: Obtain the log anomaly risk level and bind it to the current time window identifier; Establish a benchmark vector for evidence storage strength, which includes a benchmark interval for the log evidence storage window length, a benchmark interval for erasure coding redundancy rate, a benchmark interval for blockchain challenge verification frequency, a benchmark interval for honey label log generation density, and a benchmark interval for witness node threshold signature threshold value. Store each benchmark interval in correspondence with the maximum and minimum values ​​of the corresponding parameters. Based on the log anomaly risk level, target values ​​for each parameter are generated within each baseline interval, specifically as follows: When the risk of log anomalies increases, the log evidence window length decreases monotonically within the baseline range, the erasure coding redundancy rate increases monotonically within the baseline range, the blockchain challenge verification frequency increases monotonically within the baseline range, the honey label log generation density increases monotonically within the baseline range, and the witness node threshold signature threshold value increases monotonically within the baseline range. Perform cross-parameter coupling consistency checks on the target values ​​of each parameter: The upper limit of challenge verification frequency is determined based on erasure coding redundancy rate; the lower limit of honey label log generation density is determined based on log storage window length; the upper limit of block confirmation latency tolerance is determined based on witness node threshold signature threshold value; and when any parameter target value exceeds the corresponding matching range, a linkage callback correction is performed on the parameter target value to generate a parameter set that satisfies cross-parameter consistency constraints. The log storage window length, erasure coding redundancy rate, blockchain challenge verification frequency, honey label log generation density, and witness node threshold signature threshold value that satisfy cross-parameter consistency constraints are arranged in a preset order to form a storage strength configuration matrix. The storage strength configuration matrix is ​​then hashed to obtain the policy identifier.

7. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The generated log content root, log relationship root, and log availability root include: Obtain the log hash set, honeymark log generation density, and erasure coding redundancy rate; read the blockchain random seed and generate a honeymark index sequence based on the blockchain random seed; insert the corresponding number of honeymark log hash values ​​into the log hash set according to the honeymark index sequence to obtain the extended log hash set. The extended log hash set is subjected to hierarchical rearrangement. The extended log hash set is grouped by device identifier and sorted by timestamp within each group. The sequence within each group is constructed into a Merkle subtree. The root values ​​of the Merkle subtrees within each group are concatenated in the order of device identifier to form a device root sequence. Then, a cross-device Merkle tree is constructed on the device root sequence to obtain the log content root. Generate a time-series evidence sequence in chronological order for the extended log hash set. Use the previous time-series evidence value, the current log hash value, and the current log's sequence number in the extended log hash set as inputs, perform continuous iterative hash operations to obtain the current time-series evidence value, and combine the time-series evidence values ​​corresponding to each log in chronological order to form a time-series evidence set. A relation leaf set is constructed by associating log hash values ​​and corresponding time-series evidence values ​​in the extended log hash set with the log hash values ​​and corresponding time-series evidence values. Each relation leaf in the relation leaf set is generated by the log hash value, the time-series evidence value and the device identifier corresponding to the log. A relation Merkle tree is constructed on the relation leaf set to obtain the log relation root. The original log data corresponding to the extended log hash set is divided into a log data block set according to a preset block size. The log data block set is then subjected to erasure coding based on the erasure coding redundancy rate to generate a log coding block set. An availability Merkle tree is then constructed on the log coding block set to obtain the log availability root.

8. The method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The step of submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it into the blockchain includes: Obtain the log content root, log relationship root, and log availability root, as well as the policy identifier. At the same time, read the current log batch identifier, the set of device identifiers that participated in generating the log, and the random number of the current block of the blockchain network. Then, concatenate the set of device identifiers according to the order of the device identifiers to obtain the device set identifier. A unique anchor identifier is generated based on the log batch identifier, the blockchain random number, and the device set identifier, and a one-to-one correspondence is established between the unique anchor identifier and the current log batch. Perform multi-root coupling verification processing on the log content root, log relation root and log availability root. Verify the sequential consistency of each log hash value in the log content root according to the time-series evidence sequence contained in the log relation root, and verify the coverage integrity of the log hash values ​​in the log content root according to the coded block index corresponding to the log availability root. Generate multi-root consistency identifier when both sequential consistency and coverage integrity are satisfied. The log content root, log relationship root, log availability root, policy identifier, unique anchor identifier, multi-root consistency identifier, hash value of the previous batch of evidence header, and current time identifier are concatenated according to the preset field order, and a hash operation is performed on the concatenated data to generate a conflict-detectable evidence header. The conflict-detectable evidence header is sent to the set of witness nodes in the blockchain network for threshold signature verification. If the threshold signature threshold of the witness nodes is met, the conflict-detectable evidence header is submitted to the blockchain network for consensus verification. The blockchain ledger checks whether there is a record with the same unique anchor identifier but different log content. If it exists, it is determined to be a log evidence conflict event and the conflict identifier is recorded. If it does not exist, the conflict-detectable evidence header is written into a new block and the blockchain ledger is updated.

9. A method for storing network security logs based on blockchain verification according to claim 1, characterized in that, The step of submitting the conflict-detectable evidence header to the blockchain network for consensus verification and writing it into the blockchain includes: Read the honeymark index sequence, extended log hash set, and log content root to obtain the conflict detection header and unique anchor identifier of the corresponding log batch from the blockchain ledger; Based on the honeymark index sequence, locate the corresponding honeymark log hash value in the extended log hash set, and generate the corresponding Merkel path proof set according to the position of the honeymark log hash value in the Merkel tree of the log content. The verification root value is recalculated using the honeymark log hash value and the corresponding Merkel path proof set. The verification root value is obtained by concatenating the honeymark log hash value and the sibling node hash values ​​in the path proof set in the path order and performing a hash operation. The verification root value is then compared with the log content root recorded in the blockchain ledger for consistency. When the verification root value is consistent with the log content root in the blockchain ledger, it is determined that the path of the corresponding honeymark log in the log content Merkle tree is complete, and the consistency of the corresponding time-series evidence value in the log relation root is verified based on the sequence number of the honeymark log in the extended log hash set. The log evidence integrity index is calculated based on the verification results of the honeymark logs. The log evidence integrity index is calculated according to the ratio of the number of successfully verified honeymark logs to the total number of challenge honeymark logs. When the log evidence integrity index is lower than a preset threshold, it is determined that the corresponding log batch has selective deletion or tampering behavior, and an abnormal verification mark is recorded in the blockchain ledger.

Images