A digital information traceability management system

Abstract

The application relates to the technical field of information tracing, in particular to a digital information tracing management system. The system comprises an information fingerprint extraction module, an origin node consensus module, a flow path mapping module, an information integrity checking module and a behavior consensus feedback module, and can be used for obtaining original information; text semantic feature extraction is carried out on the original information to obtain semantic features; information fingerprint extraction is carried out on the semantic features to obtain semantic fingerprints; consensus processing based on the origin node is carried out on the semantic fingerprints to obtain a consensus result; source point credentials are generated according to the consensus result to obtain the source point credentials; flow behavior triggering is carried out according to the source point credentials to obtain a behavior to be recorded; content change analysis is carried out according to the behavior to be recorded to obtain changed semantic fingerprints. Through the fusion of semantic hashing and behavior consensus, the robustness, safety, efficiency and applicability of the tracing are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information traceability, and in particular to a digital information traceability management system. BACKGROUND

[0002] Digital information traceability management is not a completely new concept. The earliest traceability method was relatively simple, mainly relying on log records and time stamps. Later, in order to improve the tamper resistance of traceability information, traditional encryption technology and hash algorithms were introduced. The advent of blockchain technology has brought revolutionary changes to digital information traceability.

[0003] However, despite the continuous development of digital information traceability technology, the existing methods still have problems of traceability chain being easily tampered with and complex and inefficient traceability process.

[0004] Traceability chain is easily tampered with: although traditional hash algorithms can detect data tampering, they are very sensitive to any minor modifications of data (including format changes, space adjustments, etc.), even if the core semantics of the information do not change, the hash value will change greatly. This causes the traceability system based on traditional hash to easily produce false positives when facing information format changes, version iterations or minor edits, and even causes the traceability chain to break, reducing the practicality and robustness of traceability.

[0005] Complex and inefficient traceability process: traditional traceability methods are mainly based on literal comparison and operation records of data, and lack the ability to understand the semantic content of information. When information undergoes semantic drift, content evolution or multiple rounds of propagation, traditional traceability methods are difficult to accurately identify the true source and evolution trajectory of information, resulting in a decrease in traceability accuracy and efficiency. SUMMARY

[0006] Therefore, it is necessary to provide a digital information traceability management system to solve at least one of the above technical problems.

[0007] To achieve the above purpose, a digital information traceability management system includes the following modules:

[0008] An information fingerprint extraction module includes an NLP processing server and a cache server, configured to obtain original information; perform text semantic feature extraction on the original information to obtain semantic features; and perform information fingerprint extraction on the semantic features to obtain semantic fingerprints;

[0009] An origin node consensus module includes a consensus node server, configured to perform consensus processing on the semantic fingerprints based on the origin node to obtain a consensus result; and generate a source point certificate based on the consensus result to obtain the source point certificate;

[0010] The flow path mapping module comprises a behavior data collector configured to trigger a flow behavior according to a source point credential to obtain a to-be-recorded behavior, perform content change analysis on the to-be-recorded behavior to obtain a changed semantic fingerprint, and perform flow path mapping according to the to-be-recorded behavior and the changed semantic fingerprint to obtain flow track data.

[0011] The information integrity verification module comprises a verification server and an abnormal pattern detection engine, and is configured to receive a verification request according to a source point credential to obtain to-be-verified information, perform source point fingerprint comparison on the to-be-verified information to obtain a fingerprint comparison result, perform flow path backtracking according to the flow track data to obtain a verified path, perform behavior consistency verification on the verified path and perform abnormal pattern identification to obtain a behavior verification result and an abnormal behavior report, and generate a verification report according to the fingerprint comparison result, the behavior verification result and the abnormal behavior report to obtain a traceability verification report.

[0012] The behavior consensus feedback module comprises a consensus node server and a monitoring and handling component, and is configured to perform node consensus voting according to the traceability verification report to obtain a consensus vote warehouse, perform consensus decision formation according to a preset consensus algorithm and the consensus vote warehouse to obtain a consensus resolution draft, and perform resolution measure execution according to the consensus resolution draft to obtain handling resolution data, so as to realize digital information traceability management operation.

[0013] Preferably, the information fingerprint extraction module comprises the following functions:

[0014] Obtaining original information; performing text preprocessing on the original information to obtain preprocessed text;

[0015] Performing semantic feature extraction on the preprocessed text to obtain semantic features;

[0016] Performing semantic vector construction on the semantic features to obtain semantic vectors;

[0017] Performing semantic hash coding on the semantic vectors to obtain semantic hash codes;

[0018] Performing semantic fingerprint generation on the semantic hash codes to obtain semantic fingerprints.

[0019] Preferably, the origin node consensus module comprises the following functions:

[0020] Performing origin information encapsulation on the semantic fingerprints to obtain to-be-consensus information;

[0021] Performing network broadcast submission on the to-be-consensus information to obtain a broadcast request;

[0022] Performing node preliminary verification on the broadcast request to obtain to-be-verified information;

[0023] Performing consensus proposal and voting on the to-be-verified information to obtain consensus votes;

[0024] According to the preset consensus algorithm, the consensus votes are confirmed to obtain a consensus result;

[0025] According to the consensus result, a source point certificate is generated to obtain a source point certificate.

[0026] Preferably, the flow path mapping module comprises the following functions:

[0027] According to the source point certificate, a flow behavior trigger is performed to obtain a behavior to be recorded;

[0028] According to the behavior to be recorded, content change analysis is performed to obtain a changed semantic fingerprint;

[0029] According to the behavior to be recorded and the changed semantic fingerprint, a flow event is constructed to obtain a flow snapshot;

[0030] The flow snapshot is subjected to flow record addition to obtain a record to be chained;

[0031] According to the preset distributed ledger, the record to be chained is subjected to distributed ledger writing to obtain a chain flow record;

[0032] According to the chain flow record and the source point certificate, a flow track is updated to obtain flow track data.

[0033] Preferably, the information integrity verification module comprises the following functions:

[0034] According to the source point certificate, a verification request is received to obtain information to be verified; the current semantic fingerprint is reconstructed from the information to be verified to obtain a current semantic fingerprint;

[0035] The current semantic fingerprint and the information to be verified are subjected to source point fingerprint comparison to obtain a fingerprint comparison result;

[0036] According to the information to be verified and the flow track data, a flow path is traced back to obtain a verified path;

[0037] According to the current semantic fingerprint, the behavior consistency of the verified path is verified to obtain a behavior verification result;

[0038] The verified path is subjected to abnormal mode recognition to obtain an abnormal behavior report;

[0039] The fingerprint comparison result, the behavior verification result and the abnormal behavior report are subjected to verification result summarization to obtain a report to be signed; the report to be signed is subjected to verification report generation to obtain a traceability verification report.

[0040] Preferably, the behavior consensus feedback module comprises the following functions:

[0041] The traceability check report is checked and a check report is distributed to obtain a to-be-consensus report;

[0042] A consensus process is started according to the to-be-consensus report to obtain a consensus proposal;

[0043] Node evaluation and voting are performed according to the to-be-consensus report and the consensus proposal to obtain a disposal vote;

[0044] The voting results of the disposal vote are summarized to obtain a consensus vote warehouse;

[0045] A consensus decision is formed according to a preset consensus algorithm and the consensus vote warehouse to obtain a consensus resolution draft;

[0046] Disposal measures are executed according to the consensus resolution draft to obtain an execution instruction; an execution result is recorded according to the execution instruction to obtain a disposal record;

[0047] The consensus resolution draft, the consensus vote warehouse, and the disposal record are solidified to obtain a disposal resolution data.

[0048] The application realizes the automatic acquisition and efficient processing of original information through the NLP processing server and the cache server. By using the text semantic feature extraction technology, the system can deeply understand the core semantics of the information, overcoming the limitations of traditional keyword matching and more accurately capturing the essence of the information. The information fingerprint extraction process compresses complex semantic information into a concise semantic fingerprint, realizing efficient indexing and comparison of information content, and laying a foundation for efficient and accurate information identification and integrity verification in the subsequent traceability process. By using the consensus node server, the semantic fingerprint is processed based on the origin node, ensuring the authority and non-tamperability of the information source identity. The introduction of the consensus mechanism makes the generation of the source point certificate no longer dependent on the trust endorsement of a single center, but is confirmed by the distributed network, enhancing the credibility and public trust of the source point certificate. The generation of the source point certificate provides a trusted anchor point for subsequent tracking of the flow path and verification of information integrity, ensuring the reliability of the traceability system from the source. With the help of the behavior data collector, the system can real-time perceive and record various behaviors of information in the flow process, realizing the automatic and fine tracking of the information flow trajectory. The application of content change analysis technology enables the system to identify subtle changes in information content during the flow process and generate a changed semantic fingerprint, accurately recording each content evolution. The flow path mapping process associates the recorded behavior with the changed semantic fingerprint, constructing a complete flow trajectory data, providing a clear and credible path record for the whole life cycle management and responsibility tracing of information. Through the verification server and the abnormal mode detection engine, the system can receive verification requests according to the source point certificate and perform multi-dimensional and deep integrity verification on the information to be verified. The source point fingerprint comparison technology can quickly judge whether the core semantics of the information to be verified and the original information are consistent, and preliminarily identify the content tampering risk. The flow path backtracking and behavior consistency verification mechanism can verify whether the flow trajectory of the information conforms to the recorded path and identify potential abnormal behaviors such as unauthorized modification or jump flow, effectively improving the accuracy and comprehensiveness of information integrity verification. The final generated traceability verification report provides an objective and reliable basis for the credibility evaluation and risk warning of information. By using the consensus node server and the monitoring and disposal component, the system can start node consensus voting based on the traceability verification report, realizing the automatic and collaborative disposal decision of abnormal behaviors. The consensus algorithm and the consensus vote bank ensure the democracy and fairness of the disposal decision, avoiding the risk of single-point decision-making and improving the credibility of the disposal result. The generation of the consensus resolution draft and the implementation of the resolution measures realize the closed-loop management from abnormal detection to disposal response, improving the rapid response and automatic disposal capability of the system to information security risks. The final disposal resolution data provides valuable data support for the continuous optimization and security audit of the system, and builds a more robust and reliable digital information traceability management system.Therefore, the application provides a digital information traceability management system, through the innovative fusion of semantic hashing and behavior consensus, not only effectively solves the prominent disadvantages of the prior art in the tamperability of the traceability chain and the complexity and inefficiency of the traceability process, but also significantly improves the robustness, security, efficiency and applicability of traceability. BRIEF DESCRIPTION OF DRAWINGS

[0049] Figure 1 A step flow schematic diagram of the digital information traceability management system is shown in Figure 1.

[0050] Figure 2 A detailed implementation step flow schematic diagram of the information fingerprint extraction module in the application is shown in Figure 2.

[0051] The purposes, functional features and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0052] The technical method of the application will be described clearly and completely below with reference to the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the application, rather than all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0053] In addition, the accompanying drawings are only schematic illustrations of the application, and are not necessarily drawn to scale. The same reference numerals in the drawings represent the same or similar parts, and thus repeated descriptions thereof will be omitted. Some block diagrams shown in the drawings are functional entities, and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0054] It should be understood that although the terms "first", "second" and the like can be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the exemplary embodiments, a first element can be referred to as a second element, and similarly a second element can be referred to as a first element. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0055] To achieve the above-mentioned purposes, please refer to Figures 1 to 2 A digital information traceability management system, the system comprises the following modules:

[0056] The information fingerprint extraction module includes an NLP processing server and a cache server, is used for obtaining original information, performing text semantic feature extraction on the original information to obtain semantic features, and performing information fingerprint extraction on the semantic features to obtain semantic fingerprints;

[0057] The origin node consensus module includes a consensus node server, is used for performing origin node-based consensus processing on the semantic fingerprints to obtain a consensus result, and generating a source point certificate according to the consensus result to obtain the source point certificate;

[0058] The flow path mapping module includes a behavior data collector, is used for triggering a flow behavior according to the source point certificate to obtain a to-be-recorded behavior, performing content change analysis according to the to-be-recorded behavior to obtain a changed semantic fingerprint, and performing flow path mapping according to the to-be-recorded behavior and the changed semantic fingerprint to obtain flow track data;

[0059] The information integrity verification module includes a verification server and an abnormal pattern detection engine, is used for receiving a verification request according to the source point certificate to obtain to-be-verified information, performing source point fingerprint comparison on the to-be-verified information to obtain a fingerprint comparison result, performing flow path backtracking according to the flow track data to obtain a verified path, performing behavior consistency verification on the verified path and performing abnormal pattern recognition to obtain a behavior verification result and an abnormal behavior report, and generating a verification report according to the fingerprint comparison result, the behavior verification result and the abnormal behavior report to obtain a traceability verification report;

[0060] The behavior consensus feedback module includes a consensus node server and a monitoring and disposal component, is used for performing node consensus voting according to the traceability verification report to obtain a consensus vote warehouse, performing consensus decision formation according to a preset consensus algorithm and the consensus vote warehouse to obtain a consensus resolution draft, and performing resolution measure execution according to the consensus resolution draft to obtain disposal resolution data, so as to realize digital information traceability management work.

[0061] In the embodiment of the application, reference Figure 1 is shown, which is a step flowchart of the digital information traceability management system of the application. In the example, the digital information traceability management system includes the following modules:

[0062] S1: The information fingerprint extraction module includes an NLP processing server and a cache server, is used for obtaining original information, performing text semantic feature extraction on the original information to obtain semantic features, and performing information fingerprint extraction on the semantic features to obtain semantic fingerprints;

[0063] In the embodiment of the application, by using the NLP processing server and the cache server, first, the original information of various data sources is monitored and received through a preset port. Then, text preprocessing is performed using a Jieba or HanLP tokenizer to remove noise and stop words. Then, semantic features are extracted using TF-IDF, LDA, NER, and dependency syntax analysis techniques, and these features are converted into semantic vectors. Finally, the semantic vectors are hashed using the LSH algorithm to generate semantic hash codes, and after adding metadata, SHA-256 hash calculation is performed to obtain the final semantic fingerprint as the unique identifier of the information.

[0064] S2: an origin node consensus module including a consensus node server, configured to perform origin node-based consensus processing on the semantic fingerprint to obtain a consensus result, and perform source point certificate generation according to the consensus result to obtain a source point certificate;

[0065] In the embodiment of the application, the consensus node server is used to encapsulate the semantic fingerprint as to-be-consensed information, and submit it to the consensus network through network broadcasting. After the consensus node performs preliminary verification on the broadcast request, consensus proposal and voting are performed. According to a preset consensus algorithm, the consensus votes collected are confirmed to obtain the source point certificate as the proof of the trusted identity of the information source.

[0066] S3: a flow path mapping module including a behavior data collector, configured to trigger a flow behavior according to the source point certificate to obtain a to-be-recorded behavior, perform content change analysis according to the to-be-recorded behavior to obtain a changed semantic fingerprint, and perform flow path mapping according to the to-be-recorded behavior and the changed semantic fingerprint to obtain flow trajectory data;

[0067] In the embodiment of the application, the behavior data collector is used to trigger flow behavior recording according to the source point certificate. When the flow behavior is detected, content change analysis is performed to obtain a content difference segment through fine-grained difference detection technology (row-level and word-level comparison), and a changed semantic fingerprint is generated. Then, a flow event snapshot is constructed and appended to the flow record, and written into a distributed ledger. Finally, the flow trajectory data is updated according to the on-chain flow record and the source point certificate to form a complete flow path of the information.

[0068] S4: an information integrity verification module including a verification server and an abnormal pattern detection engine, configured to receive a verification request according to the source point certificate to obtain to-be-verified information, perform source point fingerprint comparison on the to-be-verified information to obtain a fingerprint comparison result, perform flow path backtracking according to the flow trajectory data to obtain a verified path, perform behavior consistency verification on the verified path, and perform abnormal pattern recognition to obtain a behavior verification result and an abnormal behavior report, and generate a verification report according to the fingerprint comparison result, the behavior verification result, and the abnormal behavior report to obtain a traceability verification report;

[0069] In the embodiment of the present application, the verification server and the abnormal pattern detection engine receive the verification request according to the source point credential, and obtain the to-be-verified information. The current semantic fingerprint of the to-be-verified information is reconstructed. Then, the Hamming distance comparison between the current semantic fingerprint and the source point fingerprint in the source point credential is performed to obtain a fingerprint comparison result. At the same time, the flow path backtracking and hash verification are performed according to the to-be-verified information and the flow track data to obtain a verified path. Next, the behavior consistency verification and the abnormal pattern recognition are performed on the verified path to obtain a behavior verification result and an abnormal behavior report. Finally, the fingerprint comparison result, the behavior verification result and the abnormal behavior report are summarized to generate a traceability verification report.

[0070] S5: a behavior consensus feedback module including a consensus node server and a monitoring and disposal component, configured to perform node consensus voting according to the traceability verification report to obtain a consensus ticket pool, perform consensus decision formation according to a preset consensus algorithm and the consensus ticket pool to obtain a consensus resolution draft, perform resolution measure execution according to the consensus resolution draft to obtain disposal resolution data, so as to realize digital information traceability management operation;

[0071] In the embodiment of the present application, the consensus node server and the monitoring and disposal component are used to distribute the traceability verification report, start the consensus process and generate a consensus proposal. The consensus node performs evaluation and voting based on the report and the proposal to obtain disposal votes. The disposal votes are summarized to form a consensus ticket pool, and a consensus decision is formed according to a preset consensus algorithm (such as a simple majority voting algorithm) to form a consensus resolution draft. Finally, the disposal measures are executed according to the resolution draft, the execution result is recorded as disposal records, and the consensus resolution draft, the consensus ticket pool and the disposal records are finally resolved to obtain disposal resolution data, so as to complete the digital information traceability management operation.

[0072] As an example of the present application, refer to Figure 2 Fig. 1 shows a functional flow diagram of an information fingerprint extraction module in the embodiment, and the functions of the information fingerprint extraction module in the embodiment include: Figure 1

[0073] S11: obtaining original information; performing text preprocessing on the original information to obtain preprocessed text;

[0074] ​In the embodiments of the present application, the acquisition of original information is the primary step of the digital information provenance management process. The system predefines an information receiving port, which continuously collects and responds to information requests from data input channels. Data input channels include but are not limited to: open API interface, database connection, file system directory, and web crawler component. When receiving an information input request, the system immediately establishes a data connection and receives the original information data stream from the data source according to the predefined communication protocol, such as HTTP protocol, TCP / IP protocol or file transfer protocol. The original information data stream is captured in digital form by the system and temporarily stored in the system memory buffer, waiting for subsequent text preprocessing operations. For example, the system can receive text information packaged in JSON format by collecting the pre-defined API endpoint, or read the newly added text file in the specified directory in real time through the file monitoring component, thereby realizing the automatic collection of original information from different sources. The text preprocessing stage aims to improve the accuracy and efficiency of subsequent semantic analysis. The system first uses a rule-based word segmentation engine, such as Jieba or HanLP, to accurately segment the original information text, cutting the continuous text sequence into independent word units. Subsequently, the system performs a noise removal program that removes non-semantic components in the text according to pre-defined regular expression rules, including but not limited to: various punctuation marks, special characters, HTML / XML tags, and URL links. Further, the system loads a pre-defined stop word list containing high-frequency but low-semantic-contribution words such as "of", "is", "in". The system accurately matches the segmentation results with the stop word list and removes all matching stop words, finally outputting the pre-processed text after segmentation, denoising and stop word filtering, providing a standardized text data basis for the subsequent semantic feature extraction step.

[0075] S12: performing semantic feature extraction on the pre-processed text to obtain semantic features;

[0076] In the embodiment of the present application, the semantic feature extraction link is the core step of constructing the information semantic fingerprint. The target is to extract a feature vector set capable of representing the core semantics of information from the preprocessed text. The system first uses the TF-IDF (Term Frequency-Inverse Document Frequency) algorithm to calculate the weight of each word in the preprocessed text, quantifies the importance of the word in the information content, and forms an initial keyword weight vector. Secondly, the system uses a topic model algorithm, such as LDA (Latent Dirichlet Allocation) or NMF (Non-negative Matrix Factorization), to mine the topic distribution of the preprocessed text, identify the latent topic structure of the text, and output the probability distribution vector of the text on each topic. In addition, the system integrates a named entity recognition (NER) model, such as a BiLSTM-CRF-based NER model or a Transformer-based NER model, to identify the named entities, such as names, places, and organization names, in the text and construct a named entity set. Finally, the system uses a dependency syntax analyzer, such as Stanford Parser or LTP dependency syntax analyzer, to parse the dependency syntax structure of the sentence and generate a dependency relationship graph. The system integrates the keyword weight vector, the topic probability distribution vector, the named entity set, and the dependency relationship graph to form a multi-dimensional semantic feature data set, which comprehensively represents the semantic connotation of the information.

[0077] S13: constructing a semantic vector based on the semantic features to obtain the semantic vector;

[0078] In the embodiment of the present application, the semantic vector construction stage is responsible for converting the extracted multi-dimensional semantic features into a numerical vector representation form that can be processed by a computer. For the keyword weight vector, the system directly uses the weight value output by the TF-IDF algorithm as the vector dimension value to construct the keyword weight vector. For the topic probability distribution, the system directly uses the topic probability value output by the topic model as the vector dimension value to construct the topic distribution vector. For the named entity set, the system pre-constructs a named entity vector space, which can be trained based on Word2Vec, GloVe, or FastText word vector model. The system maps each named entity in the named entity set to the vector space to obtain the corresponding entity vector, and performs average pooling or weighted average pooling operation on all entity vectors to generate a fixed-length entity vector. For the dependency relationship graph, the system uses graph embedding technology, such as DeepWalk, Node2Vec, or GraphSAGE, to learn the low-dimensional vector representation of the nodes in the graph, and embed the entire graph into a fixed-dimensional vector space to generate a relationship vector. The system finally concatenates or weightedly fuses the keyword weight vector, the topic distribution vector, the entity vector, and the relationship vector to obtain a comprehensive and high-dimensional semantic vector, which can numerically represent the semantic content of the original information.

[0079] S14: perform semantic hashing coding on the semantic vector to obtain a semantic hash code;

[0080] In the embodiment of the application, the semantic hashing coding stage aims to compress the high-dimensional semantic vector into a fixed-length low-dimensional hash code while maintaining semantic similarity as much as possible. The system uses a local sensitive hashing (LSH) algorithm for semantic hashing coding. The system pre-configures multiple LSH hash function families, each of which contains multiple hash functions. For the input semantic vector, the system uses the hash functions in each hash function family to perform hash calculation respectively to obtain multiple hash bucket numbers. The system combines the hash bucket numbers from different hash function families to form a fixed-length hash code. In order to improve the robustness and precision of the hash, the system uses a multi-bucket strategy, that is, for each semantic vector, it is not only mapped to one hash bucket, but also mapped to multiple related hash buckets. The system can select specific LSH algorithms such as random hyperplane hashing, MinHash or SimHash for implementation. For example, the system can use 128 random hyperplane hash functions to project the high-dimensional semantic vector into a 128-dimensional binary hash code space, each dimension representing a hash bucket, and finally output a 128-bit binary semantic hash code as the compressed representation of the information semantics.

[0081] S15: perform semantic fingerprint generation on the semantic hash code to obtain a semantic fingerprint;

[0082] In this embodiment of the invention, the semantic fingerprint generation stage is the final step of the information fingerprint extraction module. Its purpose is to standardize the semantic hash code and generate the final semantic fingerprint identifier. The system first converts the generated binary semantic hash code into a hexadecimal string representation for easy storage, transmission, and comparison. The system then appends metadata information to the generated hexadecimal semantic hash string to enhance the integrity and traceability of the semantic fingerprint. The appended metadata information includes, but is not limited to: the LSH algorithm version identifier used when generating the semantic hash code, the specific parameter configuration of the LSH algorithm (e.g., the number of hash function families, hash bucket size, random seed), and the NLP model version information used in the semantic feature extraction stage. This metadata information is organized in a structured JSON format and concatenated with the hexadecimal semantic hash string to form a composite semantic fingerprint string. To ensure the uniqueness and tamper-proof nature of the semantic fingerprint, the system uses a cryptographic hash algorithm, such as the SHA-256 algorithm, to perform hash calculations on the composite semantic fingerprint string, generating the final semantic fingerprint hash value. This final hash value serves as the unique semantic identifier of the original information and is recorded by the system for subsequent stages such as origin node consensus, flow path mapping, and information integrity verification. For example, the system can concatenate a JSON string containing the version identifier "LSH_V1.2", parameter configuration "buckets=256,functions=128,seed=12345", and NLP model version "BERT_NER_V2.1" with a hexadecimal semantic hash code, then use the SHA-256 algorithm to calculate its hash value, ultimately outputting a 256-bit hexadecimal string as the semantic fingerprint of the original information. This semantic fingerprint will serve as a unique identifier for this information throughout the entire traceability management system.

[0083] Preferably, the semantic feature extraction of the preprocessed text includes:

[0084] Preliminary keyword extraction is performed on the preprocessed text to obtain an initial keyword list;

[0085] Topic distribution mining is performed on the preprocessed text to obtain the topic probability distribution;

[0086] Named entity recognition is performed on the preprocessed text to obtain a named entity set;

[0087] Dependency parsing is performed on the preprocessed text to obtain a dependency graph;

[0088] Semantic features are obtained by fusing and enhancing the initial keyword list, topic probability distribution, named entity set, and dependency graph.

[0089] In the embodiment of the application, the keyword preliminary extraction aims to quickly screen out the core vocabulary in the preprocessed text, and lays a foundation for subsequent deep semantic analysis. The system adopts a keyword extraction algorithm based on term frequency-inverse document frequency (TF-IDF). The system preloads a large-scale general corpus, which covers multiple domain texts. For the input preprocessed text, the system calculates the term frequency (TF) of each word, and combines the pre-calculated IDF value to calculate the TF-IDF weight score of each word. The system sets a keyword quantity threshold, for example, the first 20 keywords. The system sorts all words in descending order according to the TF-IDF weight score, selects the words ranked within the threshold, and constructs an initial keyword list.

[0090] The topic distribution mining aims to reveal the potential topic structure in the preprocessed text, and capture the macro semantic tendency of the text. The system adopts a latent Dirichlet allocation (LDA) topic model for topic distribution mining. The system pre-trains the LDA topic model, and the training corpus is a large-scale domain-related text dataset, such as information security field literature, blockchain technology white paper, etc. The system configures the number of topics of the LDA model, for example, 50 topics. For the input preprocessed text, the system inputs it into the pre-trained LDA model. The model analyzes the co-occurrence pattern of words in the text based on Bayesian inference method, and infers the topic probability distribution of the text on the preset topic set. The system outputs a topic probability distribution vector, and the vector dimension is the number of topics. Each dimension value represents the probability that the text belongs to the corresponding topic.

[0091] The named entity recognition aims to identify entity words with specific meanings from the preprocessed text, such as names, place names, organization names, etc., and capture key entity information in the text. The system adopts a named entity recognition (NER) model based on deep learning, such as a BiLSTM-CRF or Transformer-based NER model. The system pre-trains the NER model, and the training data is a professional field corpus annotated with named entity information, such as information security news, technical blogs, etc. The system configures the entity types identified by the NER model. For the input preprocessed text, the system inputs it into the pre-trained NER model. The model predicts the entity type label of each word in the text based on the sequence labeling method. The system post-processes the model prediction result, extracts all identified named entities, classifies them according to the entity type, and constructs a named entity set.

[0092] Dependency parsing aims to reveal the syntactic dependency relations between words in the preprocessed text, capturing the deep structured semantic information of the sentence. The system uses a neural network-based dependency parser. The system pre-trains the dependency parser using a large-scale dependency-labeled Treebank corpus as training data. For the input preprocessed text, the system performs dependency parsing sentence by sentence. The parser analyzes the dependency relations between the words in each sentence, such as subject-predicate relations, verb-object relations, and determiner-noun relations. The system represents the dependency parsing results of each sentence as a directed graph, where the nodes represent the words in the sentence, and the directed edges represent the dependency relations between the words. The labels on the edges represent the types of dependency relations. The system integrates the dependency relation graphs of all sentences to form the overall dependency relation graph of the preprocessed text. For example, for the sentence "semantic hashing technology is applied to information tracing", the dependency parser analyzes "semantic hashing technology" as the subject, "apply" as the predicate, and "to information tracing" as the adverbial phrase, and labels the dependency relation types between them, such as "subject-predicate relation", "verb-object relation", "adverbial relation", etc. The system represents and stores these dependency relation information in the form of a graph structure as an important feature of the structured semantic of the text.

[0093] The semantic feature fusion and enhancement stage aims to integrate the various semantic features extracted in the previous steps to improve the comprehensiveness and robustness of the semantic representation. The system uses a multi-strategy feature fusion method. First, for the initial keyword list, the system uses semantic knowledge bases such as WordNet or HowNet to perform semantic expansion on the keywords, such as synonym expansion, near-synonym expansion, and hypernym expansion, to expand the coverage of the keyword list and enhance the semantic completeness of the keyword representation. Second, the system performs dimensionality reduction on the topic probability distribution, such as using principal component analysis (PCA) or singular value decomposition (SVD) algorithms, to reduce the dimensionality of the topic vector, reduce redundant information, and improve computational efficiency. Then, the system performs entity linking on the named entity set, using entity linking technology to link the named entities to standardized entities in knowledge graphs or Wikidata knowledge bases, to obtain more rich entity semantic information such as entity attributes and entity relationships, and enhance the semantic depth of entity representation. Finally, the system fuses the structured information of the dependency relation graph. The system can extract key subgraph patterns from the dependency relation graph, such as frequent subgraphs and maximum common subgraphs, as structured semantic features; or the system can use graph neural networks (GNN) such as GCN or GAT to learn the graph embedding representation of the dependency relation graph, and convert the structured information into low-dimensional vector representation. The system integrates the enhanced keyword list, the dimensionality-reduced topic probability distribution, the entity-linked named entity set, and the graph-embedded dependency relation graph to form the final semantic feature set. The integration method can be simple concatenation, weighted fusion, or dynamic fusion based on attention mechanisms. The final semantic feature set will serve as the basis for information semantic fingerprint construction, comprehensively and robustly representing the semantic content of the original information. For example, the system can add the expanded keywords to the feature vector, concatenate the dimensionality-reduced topic probability vector with the entity vector and graph embedding vector to form a high-dimensional comprehensive semantic feature vector.

[0094] Preferably, the functions of the origin node consensus module include:

[0095] The semantic fingerprint is encapsulated with origin information to obtain consensus information to be verified;

[0096] The consensus information to be verified is broadcasted on the network to obtain a broadcast request;

[0097] The broadcast request is preliminarily verified by the nodes to obtain information to be verified;

[0098] The information to be verified is subjected to consensus proposal and voting to obtain consensus votes;

[0099] The consensus votes are subjected to consensus result confirmation according to a preset consensus algorithm to obtain a consensus result;

[0100] According to the consensus result, the source point certificate is generated.

[0101] In the embodiment of the application, the origin information encapsulation step aims to integrate the semantic fingerprint with necessary metadata to form a data packet that can be verified by consensus. The system obtains the semantic fingerprint generated by the information fingerprint extraction module and collects metadata related to the origin of the information. The metadata at least includes: the digital identity of the information creator, the timestamp of the information creation (accurate to the millisecond level), the information type (such as text, picture, video), and the information access permission control policy. The system encapsulates the semantic fingerprint and the metadata in a predefined structured data format, such as JSON or Protocol Buffer. The encapsulated data packet contains the "semantic_fingerprint" field (storing the semantic fingerprint), the "creator_id" field (storing the creator's identity), the "timestamp" field (storing the creation timestamp), the "information_type" field (storing the information type), and the "access_policy" field (storing the access permission control policy). To ensure data integrity and source credibility, the information creator uses his private key to digitally sign the encapsulated data packet based on the Elliptic Curve Digital Signature Algorithm (ECDSA) or the RSA Digital Signature Algorithm. The digital signature result is added to the data packet as the "signature" field, and finally forms the "to-be-consensus information" to prepare for the subsequent network broadcast submission step.

[0102] The network broadcast submission step is responsible for efficiently and reliably delivering the encapsulated “to-be-consensus information” to each node in the consensus network. The system uses network broadcast technology based on gRPC or ZeroMQ to build an efficient message broadcast channel. The information origin node acts as the broadcast initiator and broadcasts the “to-be-consensus information” and its own node identity to the pre-configured consensus node list through the broadcast channel. The broadcast message uses a point-to-multipoint communication mode to ensure that the message can be sent to multiple consensus nodes simultaneously. To ensure the reliability of message transmission, the broadcast protocol uses a message acknowledgement mechanism and a retransmission mechanism. After receiving the broadcast message, the consensus node sends an acknowledgement message (ACK) to the broadcast initiator. If the broadcast initiator does not receive an ACK within a predetermined time, it will retransmit the message until it receives an ACK from all target consensus nodes or reaches the maximum number of retransmissions. The content of the broadcast message includes the “to-be-consensus information” data packet itself and the node identity of the broadcast initiator. The system records the sending log of all broadcast messages, including message ID, sending time, target node list, sending status, etc. For example, the origin node sends the encapsulated JSON format “to-be-consensus information” data packet and its own node ID to all pre-configured consensus nodes through the gRPC broadcast channel and waits for the ACK confirmation from each node.

[0103] The node preliminary verification step aims to quickly verify the legality of the request and the correctness of the data format after the consensus node receives the broadcast request, and to filter invalid requests to prepare for the subsequent consensus voting link. After receiving the broadcast request, the consensus node first verifies whether the node identity of the broadcast initiator is in the pre-registered trusted node list. If the initiator identity fails the verification, the request is directly rejected and an abnormal log is recorded. After the identity verification is passed, the consensus node performs format verification on the received “to-be-consensus information” data packet. After the format verification is passed, the consensus node uses the public key of the broadcast initiator to verify whether the digital signature of the “to-be-consensus information” data packet is valid based on the digital signature algorithm. If the signature verification fails, it indicates that the data may have been tampered with, and the consensus node will reject the request and record a tampering warning log. After all the verification steps are passed, the consensus node marks the “to-be-consensus information” that has passed the preliminary verification as “to-be-verified information” and places it in the to-be-consensus queue, waiting for the subsequent consensus proposal and voting link. The preliminary verification process should be completed within milliseconds to ensure the processing efficiency of the consensus network. For example, after receiving the broadcast request, the consensus node first queries the local trusted node list to verify the identity ID of the broadcast initiator, then verifies the JSON format of the “to-be-consensus information” using JSON Schema, and verifies the digital signature using the initiator’s public key. After all the verifications are passed, the information is marked as “to-be-verified information” and enters the consensus process.

[0104] The consensus proposal and voting steps are the core steps of the origin node consensus module, aiming to reach consensus on the origin of information and the validity of semantic fingerprints through distributed voting. The leader node or rotating node in the consensus network is responsible for initiating the consensus proposal. The proposal content includes the data packet of the "to-be-verified information" and the proposed consensus round identifier. After receiving the consensus proposal, the consensus node enters the voting stage. Each consensus node independently evaluates and votes on the "to-be-verified information" based on its pre-set consensus strategy and local data. The evaluation content includes: whether the information creator's identity is trustworthy, whether the information type conforms to the system specification, and whether the semantic fingerprint is consistent with the locally recalculated semantic fingerprint (optional step, which can be selected according to performance requirements). The consensus node generates a voting ticket based on the evaluation results. The ticket content at least includes: the identity of the voting node, the voting result ("agree" or "reject"), and the voting timestamp. In order to ensure the authenticity and non-repudiation of the vote, the consensus node uses its private key to digitally sign the voting ticket. The signed voting ticket is sent to the consensus coordination node (which can be the leader node or an independent coordination node) through the network. The consensus coordination node is responsible for collecting all the voting tickets of the consensus nodes to form a "consensus ticket" set, providing a data basis for the subsequent consensus result confirmation link.

[0105] The consensus result confirmation step aims to collect enough "consensus votes" by the consensus coordinator node, and then statistically analyze the voting results according to the preset consensus algorithm, to determine whether consensus is reached and the specific results of the consensus. After the consensus coordinator node receives all the "consensus votes" from the participating consensus nodes, it first verifies the digital signature of each vote to ensure the authenticity and integrity of the vote, and filters out invalid votes. Then, the consensus coordinator node statistically analyzes the valid votes according to the preset consensus algorithm, such as the Practical Byzantine Fault Tolerance algorithm (PBFT), Raft algorithm or Paxos algorithm. Taking the PBFT algorithm as an example, the consensus coordinator node counts the number of "agree" votes and "reject" votes. If the number of "agree" votes exceeds two-thirds of the total number of votes, it is considered that consensus is reached, and the consensus result is "consensus passed". If the number of "reject" votes or "invalid votes" (such as votes that have not been submitted due to timeout) reaches or exceeds one-third of the total number of votes, it is considered that consensus is not reached, and the consensus result is "consensus failed". The consensus result needs to clearly indicate whether consensus is reached and the specific resolution of the consensus (such as "consensus passed" or "consensus failed"). The consensus coordinator node broadcasts the consensus result and all the voting information of the participating nodes to inform all the consensus nodes, ensuring the openness, transparency and verifiability of the consensus result. For example, after the consensus coordinator node collects all the voting votes from the consensus nodes and verifies the signatures, it counts 22 "agree" votes and 2 "reject" votes, with a total of 30 votes. Since the number of "agree" votes exceeds two-thirds (30*2 / 3=20), consensus is reached, and the consensus result is "consensus passed", which is broadcast to all consensus nodes.

[0106] The source point credential generation step is the final link of the origin node consensus module, aiming to generate a trusted digital credential when consensus is reached. When the consensus result is "consensus passed", the consensus coordinator node is responsible for generating the source point credential. In order to ensure the authority and non-tamperability of the source point credential, the consensus coordinator node uses its private key to digitally sign all the contents of the source point credential based on the digital signature algorithm. The digital signature as a component of the credential ensures the credibility of the source and the integrity of the content. The generated source point credential is stored and published in the form of a structured digital certificate. The digital certificate can adopt the X.509 standard format or a custom JSON format. Once the source point credential is generated, it becomes the authoritative basis for information traceability. The source point credential needs to be stored in a trusted storage medium, such as a distributed ledger or a trusted database, for long-term preservation and query. For example, after consensus is reached, the consensus coordinator node encapsulates the semantic fingerprint, creator ID, creation timestamp, consensus timestamp, list of participating consensus nodes and "consensus passed" result according to the X.509 digital certificate standard format, and signs it with the private key of the coordinator node to generate the final source point credential, which is stored in the blockchain system.

[0107] Preferably, the flow path mapping module comprises the following functions:

[0108] Trigger a flow action according to the source point credential to obtain a to-be-recorded action;

[0109] Perform content change analysis according to the to-be-recorded action to obtain a changed semantic fingerprint;

[0110] Perform flow event construction according to the to-be-recorded action and the changed semantic fingerprint to obtain a flow snapshot;

[0111] Perform flow record addition to the flow snapshot to obtain a to-be-chained record;

[0112] Perform distributed ledger writing to the to-be-chained record according to a preset distributed ledger to obtain a chain flow record;

[0113] Perform flow track updating according to the chain flow record and the source point credential to obtain flow track data.

[0114] In the embodiment of the application, the flow action triggering step aims to monitor and capture various operation behaviors of the user on the traced information in real time, and lays a foundation for subsequent flow path recording. The captured event data is encapsulated into a structured "to-be-recorded action" data object, and is sent to the flow path mapping module for subsequent processing.

[0115] The content change analysis step aims to detect content changes and generate new semantic fingerprints when the flow action involves information content modification, so as to track the information evolution track. After the system receives the "to-be-recorded action" data, it first judges the operation type. If the operation type is "MODIFY" (modification) or "QUOTE_MODIFY" (quote and modify), the content change analysis process is triggered. The system obtains the original information content before modification and the information content after modification. The obtaining method can be: retrieving the original version from the information storage system, and obtaining the modified version from the user's modification request. The system calls the information fingerprint extraction module to execute the complete semantic fingerprint extraction process on the modified information content. If the operation type is a non-modification operation (for example, "FORWARD", "SHARE", "COPY"), the content change analysis process is skipped, and the "changed semantic fingerprint" field is empty. The result of the content change analysis, i.e. the "changed semantic fingerprint" (if any), will be used together with the "to-be-recorded action" data to construct the flow event record.

[0116] The flow event construction step aims to integrate the “to-be-recorded behavior” data and the “changed semantic fingerprint” (if any) into a complete flow event record, forming a node on the flow path. The system receives the “to-be-recorded behavior” data and the “changed semantic fingerprint” (if any) as input. The system creates a structured “flow snapshot” data object. The “flow snapshot” data object will serve as a basic unit on the flow path. For example, for the “to-be-recorded behavior” data of the user forwarding the traced information, the flow path mapping module creates a “flow snapshot”.

[0117] The flow record appending step aims to temporarily store the constructed “flow snapshot” data in the buffer zone to be written to the distributed ledger, preparing for subsequent batch chain operation and improving system efficiency. The system maintains an in-memory buffer zone. When the system completes the construction of the “flow snapshot”, the “flow snapshot” data is appended to the tail of the buffer zone queue. The system can set the size threshold and time threshold of the buffer zone. When the number of “flow snapshots” in the buffer zone reaches the threshold (e.g. 100), or the time interval since the last chain operation exceeds the threshold (e.g. 5 minutes), the system triggers batch chain operation. Before the “flow snapshots” in the buffer zone are written to the distributed ledger, they are in the “to-be-chained record” state. Through the buffer zone mechanism, frequent flow event record operations can be combined into batch write operations, reducing the write pressure of the distributed ledger and improving the overall throughput of the system. For example, the system appends the constructed “flow snapshot” JSON data to the in-memory buffer zone queue. When the number of snapshots in the queue reaches 100, or the time since the last chain operation exceeds 5 minutes, the system will trigger batch chain operation to write the 100 “flow snapshot” data to the distributed ledger at once.

[0118] The distributed ledger writing step aims to permanently store the flow event data in the "to-be-chained record" in a tamper-proof and traceable manner in the preset distributed ledger system. The system uses a consortium chain or a private chain as the distributed ledger, such as Hyperledger Fabric, Ethereum private chain, etc. The system establishes a connection with the distributed ledger system and calls the transaction writing interface of the ledger system. The system packs all "flow snapshot" data in the "to-be-chained record" buffer into one or more transactions and submits them to the distributed ledger system. Each transaction contains a batch of flow event records. After the distributed ledger system receives the transaction, it is verified by the consensus nodes (such as PBFT consensus), packaged into a new block, and appended to the end of the blockchain. Each flow event record is assigned a unique transaction hash value or block height as its on-chain identity. After being written to the distributed ledger, the flow event record becomes a "chain flow record" with tamper-proof and traceability. Any modification to the flow record will not pass the consensus verification, thereby ensuring the credibility of the flow path data. For example, the system packs 100 "flow snapshot" data in the buffer into a transaction and submits it to the Hyperledger Fabric consortium chain. The Orderer node in the Fabric network sorts and packages the transaction, submits it to the Peer node for endorsement and verification, and finally the transaction is written to a new block and appended to the Fabric chain. The 100 flow event records become "chain flow records" and are permanently stored in the blockchain.

[0119] The flow trajectory updating step aims to retrieve all "on-chain flow records" associated with a specific "source point certificate" from the distributed ledger and arrange them in chronological order to form the complete flow trajectory data of the information. When the flow path of the information needs to be queried, the system receives a query request containing the "source point certificate" identifier of the target information. The system establishes a connection with the distributed ledger system and calls the query interface of the ledger system. The system uses the "source point certificate" identifier as an index to retrieve all "on-chain flow records" associated with the "source point certificate" from the distributed ledger. The distributed ledger system returns all flow records related to the "source point certificate". The system sorts the retrieved "on-chain flow records" in ascending order according to the "event_timestamp" field in the records to form a time-ordered flow event list. The sorted flow event list is the complete "flow trajectory data" of the information. The flow trajectory data can be output in a structured format such as JSON or XML.

[0120] Preferably, the content change analysis according to the behavior to be recorded includes:

[0121] An operation type judgment is performed on the to-be-recorded behavior, and an operation type result is obtained.

[0122] According to the operation type result, content version acquisition is performed, and original version data and modified version data are obtained.

[0123] Fine-grained difference detection is performed on the original version data and the modified version data, and a content difference segment is obtained.

[0124] Semantic impact evaluation is performed on the content difference segment, and a semantic change degree is obtained.

[0125] The modified semantic fingerprint is generated according to the semantic change degree, and a changed semantic fingerprint is obtained.

[0126] In the embodiment of the application, the operation type judgment step is the entrance of the content change analysis process, which aims to quickly determine whether the to-be-recorded behavior belongs to the content modification operation, so as to decide whether the subsequent content change analysis is needed. The system receives the to-be-recorded behavior data as input and parses the operation_type field therein. The system predefines an operation type enumeration value set, including MODIFY (modify), QUOTE_MODIFY (quote and modify), FORWARD (forward), SHARE (share), COPY (copy), etc. The system performs exact matching between the operation_type field value in the to-be-recorded behavior and the predefined modification operation type enumeration value (for example, MODIFY and QUOTE_MODIFY). If the matching is successful, the operation type result is determined to be a modification operation (for example, a Boolean value TRUE), indicating that the subsequent content change analysis process is needed. If the matching is not successful, the operation type result is determined to be a non-modification operation (for example, a Boolean value FALSE), indicating that the content change analysis is not needed, and the subsequent steps will be skipped. The operation type judgment result will be used as a process control condition to determine whether the subsequent steps such as content version acquisition, difference detection, semantic impact evaluation and semantic fingerprint generation are performed. For example, the system receives the to-be-recorded behavior, the operation type of which is MODIFY, and performs matching between the to-be-recorded behavior and the predefined modification operation type MODIFY. If the matching is successful, the operation type result is determined to be a modification operation, and the subsequent process will continue to perform content change analysis.

[0127] The content version acquisition step aims to acquire the information content before and after the modification when the operation type is a modification operation, providing a data basis for subsequent difference detection and semantic analysis. The system receives the "operation type result" as input. If the "operation type result" is "modification operation" (for example, Boolean value "TRUE"), the system starts the content version acquisition process. The system retrieves the original version data before the modification from the information storage system according to the "source point certificate" identifier of the information being operated in the "to-be-recorded behavior". The retrieval method can be: querying the database record according to the source point certificate ID, or loading the original file from the content storage service according to the source point certificate ID. At the same time, the system obtains the modified version data from the user's modification request. The acquisition method can be: parsing the modified content from the API request parameters, or subscribing to the modified content from the message queue. The system outputs the retrieved original version data and the obtained modified version data as "original version data" and "modified version data" respectively. If the "operation type result" is "non-modification operation" (for example, Boolean value "FALSE"), skip the content version acquisition step, and "original version data" and "modified version data" are both empty. For example, the operation type judgment result is "modification operation", the system retrieves the document content before the modification as "original version data" from the database according to the source point certificate ID "CERT_12345", and obtains the modified document content submitted by the user from the API request as "modified version data", preparing for subsequent difference detection.

[0128] The fine-grained difference detection step aims to accurately identify the differences between the original version data and the modified version data, including the specific content segments of addition, deletion, and modification, to provide fine-grained difference information for semantic impact assessment. The system receives the "original version data" and "modified version data" as input. The system uses a line and word-based text difference comparison algorithm, such as the Myers difference algorithm or the LCS (Longest Common Subsequence) algorithm, for fine-grained difference detection. The system first compares the original version data and the modified version data at the line level to identify added lines, deleted lines, modified lines, and unchanged lines. For modified lines, the system further compares at the word level to identify added words, deleted words, modified words, and unchanged words. The system outputs the line-level and word-level difference information in a structured "content difference segment" data format. The "content difference segment" data can be represented in JSON or XML format, containing difference types ("ADD", "DELETE", "MODIFY", "EQUAL"), difference content (text segments), and difference location information (line number, word index, etc.). The "content difference segment" data will be used as input for the semantic impact assessment step. For example, the system performs fine-grained difference detection on the original document and the modified document, identifying that the 3rd line is deleted, the 5th-7th lines are added content, and the "error" word in the 10th line is modified to "correct". The system structures these difference information into "content difference segments".

[0129] The semantic impact evaluation step aims to analyze the degree of impact of the "content difference segment" on the overall semantics of the information, quantify the size of the semantic change, and provide a reference for subsequent disposal decisions. The system receives the "content difference segment" data as input. The system uses a semantic similarity-based method to evaluate the semantic impact. The system first calls the information fingerprint extraction module on the original version data and the modified version data respectively, and recalculates their semantic fingerprints to obtain "original version semantic fingerprint" and "modified version semantic fingerprint". Then, the system uses a semantic similarity calculation method, such as cosine similarity, Hamming distance, or Jaccard similarity coefficient, to calculate the similarity score between "original version semantic fingerprint" and "modified version semantic fingerprint". The higher the similarity score, the smaller the degree of semantic change; the lower the similarity score, the greater the degree of semantic change. The system can output the semantic similarity score, or map the similarity score to a predefined semantic change degree level (such as "no change", "slight change", "moderate change", "significant change") as the "semantic change degree" output result. And the final provenance verification report generation. For example, the system calculates the semantic fingerprint of the original document as "SF_ORIGIN", the semantic fingerprint of the modified document as "SF_MODIFIED", and then calculates the cosine similarity score of the two semantic fingerprints as 0.95. The system presets a similarity threshold, for example 0.9, if the similarity score is higher than 0.9, it is considered that the degree of semantic change is "slight change". Therefore, the system outputs the "semantic change degree" as "slight change".

[0130] The modified semantic fingerprint generation step is the final step of the content change analysis process, aiming to generate a new semantic fingerprint for the modified information content, for updating the flow path record and supporting subsequent tracing and verification based on the modified content. The system receives the "semantic change degree" as input. The system judges the "semantic change degree". If the "semantic change degree" reaches the preset "significant change" level threshold (for example, the semantic similarity score is lower than 0.7, or the semantic change degree level is "significant change"), the system considers that the content modification has caused substantial changes in the core semantics of the information, and a new semantic fingerprint needs to be generated for the modified information. The system calls the information fingerprint extraction module to re-execute the complete semantic fingerprint extraction process on the "modified version data" to obtain the "changed semantic fingerprint". If the "semantic change degree" does not reach the "significant change" level threshold (for example, the semantic similarity score is higher than 0.7, or the semantic change degree level is "no change" or "slight change"), the system considers that the content modification has not caused substantial changes in the core semantics of the information, and the semantic fingerprint of the original information can be reused without generating a new "changed semantic fingerprint", at which time the "changed semantic fingerprint" field is empty. The generated "changed semantic fingerprint" (if any) will be part of the flow event record, used to update the flow path of the information, and used in subsequent tracing and verification processes. For example, the "semantic change degree" output by the semantic impact evaluation step is "significant change", and the system determines that a new semantic fingerprint needs to be generated. The system calls the information fingerprint extraction module to re-calculate the semantic fingerprint of the modified document content to obtain a new semantic fingerprint "SF NEW", and outputs "SF NEW" as the "changed semantic fingerprint".

[0131] Preferably, the fine-grained difference detection on the original version data and the modified version data comprises:

[0132] Performing line-level preprocessing on the original version data and the modified version data to obtain line-segmented original version and line-segmented modified version;

[0133] Performing line-level difference comparison on the line-segmented original version and the line-segmented modified version to obtain line-level difference results;

[0134] Performing word-level preprocessing on the line-level difference results to obtain original lines for word-level comparison and modified lines for word-level comparison;

[0135] Performing word-level difference comparison on the original lines for word-level comparison and the modified lines for word-level comparison to obtain word-level difference results;

[0136] Structuring the line-level difference results and the word-level difference results into difference fragments to obtain content difference fragments.

[0137] In the embodiment of the present application, the line-level preprocessing operation aims to split the original version data and the modified version data into independent sequences of text lines, laying the foundation for subsequent line-level difference comparison. The text line segmentation program receives the original version data and the modified version data as input. The program uses the newline character as the line separator, traverses the entire original version data and the modified version data, and when a newline character is encountered, the text content before the newline character is extracted as an independent text line. The program arranges all extracted text lines in the order of their appearance in the original text to form a line-segmented original version list and a line-segmented modified version list, respectively. For example, if the original version data is a string containing multiple lines of text, the line-level preprocessing program will split the string into multiple string elements according to the newline character and store these string elements in a list to form a line-segmented original version. The modified version data undergoes the same processing procedure to obtain a line-segmented modified version. The preprocessed line-segmented version data provides structured input data for subsequent line-level difference comparison operations.

[0138] The line-level difference comparison operation aims to identify the text lines that have changed between the original version and the modified version and record the type of change. The line-level difference comparison program receives the line-segmented original version list and the line-segmented modified version list as input. The program uses the Longest Common Subsequence (LCS) algorithm to compare the two line lists and identify added lines, deleted lines, and modified lines. The LCS algorithm uses a dynamic programming method to find the longest common subsequence in two sequences, and lines not included in the longest common subsequence are determined to be difference lines. The program records the difference type of each line, such as "added" (a line added in the modified version), "deleted" (a line deleted in the original version), "modified" (a line with changed content), and "unchanged" (a line with unchanged content). The line-level difference result is output in a structured data format, such as JSON format, containing the text content of each line and its corresponding difference type label. For example, if a line in the original version is deleted in the modified version, the line text content will be labeled as "deleted" in the line-level difference result; if a line has changed content in the modified version, the line will be labeled as "modified" and the original version line content and the modified version line content will be recorded simultaneously.

[0139] The word-level preprocessing operation focuses on the text lines marked as "modified" type in the line-level difference comparison result, and prepares for the subsequent word-level difference comparison. The word-level preprocessing program receives the line-level difference result as input. The program iterates through the line-level difference result and filters out the line records with the difference type of "modified". For each line record of "modified" type, the program extracts the corresponding original version line text and the modified version line text respectively. The word-level preprocessing program performs a word segmentation operation on the extracted original version line text and the modified version line text. The word segmentation operation uses a statistical-based word segmentation model, such as an HMM model or a CRF model, to segment the continuous text line into independent word units. The preprocessing program removes stop words in the word segmentation result. The stop word list is predefined and includes high-frequency but semantically insignificant words such as "of", "is", "in", etc. The program outputs the processed word list as the original line for word-level comparison and the modified line for word-level comparison, providing input data at the word level for the subsequent word-level difference comparison. For example, if a line in the line-level difference result is marked as "modified" and the original version line is "information security is an important issue" and the modified version line is "network security is a core issue", the word-level preprocessing program will perform word segmentation and stop word removal operations on the two lines of text respectively, and output the word list ["information", "security", "important", "issue"] as the original line for word-level comparison and the word list ["network", "security", "core", "issue"] as the modified line for word-level comparison.

[0140] The word-level difference comparison operation identifies changes at the word level and records the change type for the original line for word-level comparison and the modified line for word-level comparison after word-level preprocessing. The word-level difference comparison program receives the original line list for word-level comparison and the modified line list for word-level comparison as input. The program uses an edit distance algorithm, such as the Levenshtein distance algorithm or the Wagner-Fischer algorithm, to calculate the edit distance between the two word sequences for each pair of original line list and modified line list. The edit distance algorithm calculates the minimum number of single-character edit operations (including insertion, deletion, or replacement) required to convert one string to another string using dynamic programming. Based on the results of the edit distance algorithm, the program identifies added words, deleted words, and replaced words. The program records the difference type of each word, such as "added" (word added in the modified version line), "deleted" (word deleted in the original version line), "replaced" (word replaced), and "unchanged" (word remains unchanged). The word-level difference result is output in a structured data format, such as nested JSON format, which details the word-level difference information for the "modified" type line based on the line-level difference result, including the original word, the modified word, and the difference type label.

[0141] The difference fragment structuring procedure is responsible for integrating the results of the line-level difference comparison and the word-level difference comparison, and organizing them into structured content difference fragments, so as to facilitate the subsequent semantic impact assessment and traceability check report generation. The difference fragment structuring procedure receives the line-level difference results and the word-level difference results as input. The procedure iterates through each line record in the line-level difference results, and processes it differently according to its difference type.

[0142] When the difference type of a line record is "unchanged", the procedure determines that the content of the line has not changed, and therefore no difference fragment needs to be generated. The procedure continues to process the next line record.

[0143] When the difference type of a line record is "added", the procedure determines that the line is an added line in the modified version. The procedure then creates an "added line fragment". The fragment structurally represents the information of the added line, including the following fields: a "fragment type" field, marked as "added line"; a "line number" field, recording the line number of the added line in the modified version; and a "content" field, storing the complete text content of the added line. For example, if the line-level difference results indicate that line 5 is an added line in the modified version, with the content "This system adopts blockchain technology", the procedure generates an added line fragment with "fragment type" as "added line", "line number" as 5, and "content" as "This system adopts blockchain technology".

[0144] When the difference type of a line record is "deleted", the procedure determines that the line is a deleted line in the original version. The procedure then creates a "deleted line fragment". The fragment structurally represents the information of the deleted line, including the following fields: a "fragment type" field, marked as "deleted line"; a "line number" field, recording the line number of the deleted line in the original version; and a "content" field, storing the complete text content of the deleted line. For example, if the line-level difference results indicate that line 10 is a deleted line in the original version, with the content "Traditional centralized management mode", the procedure generates a deleted line fragment with "fragment type" as "deleted line", "line number" as 10, and "content" as "Traditional centralized management mode".

[0145] When the difference type of a row record is "modified", the program determines that the content of the row is modified, and the program further parses the word-level difference result to obtain the difference information of the row at the word level. The program creates a "modified row fragment". The fragment structurally represents the information of the modified row, including the following fields: a "fragment type" field marked as "modified row"; a "row number" field recording the row number of the modified row in the original version and the modified version (the row numbers are usually the same); a "row-level difference type" field marked as "modified"; and a "word difference list" field storing a list of difference information at the word level. For the "word difference list" field of the "modified row fragment", the program further traverses each word difference record corresponding to the row in the word-level difference result. If the word difference type is "unmodified", the program ignores the word and continues to process the next word. If the word difference type is "added", the program creates an "added word fragment" and adds it to the "word difference list". The "added word fragment" includes the following fields: a "word type" field marked as "added word"; a "word content" field storing the added word text; and a "word position" field recording the word index position of the added word in the modified version row. If the word difference type is "deleted", the program creates a "deleted word fragment" and adds it to the "word difference list". The "deleted word fragment" includes the following fields: a "word type" field marked as "deleted word"; a "word content" field storing the deleted word text; and a "word position" field recording the word index position of the deleted word in the original version row. If the word difference type is "replaced", the program creates a "replaced word fragment" and adds it to the "word difference list". The "replaced word fragment" includes the following fields: a "word type" field marked as "replaced word"; an "original word" field storing the original word text to be replaced; a "modified word" field storing the modified word text after replacement; and a "word position" field recording the word index position of the replaced word in the original version row and the word index position of the replaced word in the modified version row.

[0146] The program arranges all generated "added row fragments", "deleted row fragments", and "modified row fragments" in the order of their row numbers in the text to form a final content difference fragment list. The content difference fragment list is output in a structured data format, such as a JSON array, and each array element is a difference fragment object. The structured content difference fragment provides detailed and accurate change information for the subsequent semantic impact evaluation module, so as to facilitate the system to analyze the potential impact of content changes on information semantic integrity and traceability chain.

[0147] Preferably, the information integrity verification module includes the following functions:

[0148] According to the source point certificate, the verification request receiving is performed to obtain to-be-verified information; the current semantic fingerprint is reconstructed according to the to-be-verified information to obtain a current semantic fingerprint;

[0149] The current semantic fingerprint and the to-be-verified information are compared according to the source point fingerprint to obtain a fingerprint comparison result;

[0150] The flow path is traced back according to the to-be-verified information and the flow track data to obtain a verified path;

[0151] The behavior consistency of the verified path is verified according to the current semantic fingerprint to obtain a behavior verification result;

[0152] An abnormal mode of the verified path is identified to obtain an abnormal behavior report;

[0153] The fingerprint comparison result, the behavior verification result and the abnormal behavior report are summarized to obtain a to-be-signed report; the to-be-signed report is used to generate a verification report to obtain a traceability verification report.

[0154] In the embodiment of the application, the verification request receiving program continuously collects information of a preset verification request receiving port. The port follows a predefined communication protocol, for example, an HTTPS protocol, and provides a verification service interface to the outside. When a verification request is received, the system immediately parses the request data packet. The source point certificate must be included in the request data packet. The source point certificate is an identity of information traceability, used to associate the to-be-verified information with the original information. The system first verifies the validity of the source point certificate, for example, checks the certificate signature, the validity period and whether it is a legal certificate issued by the system. After the certificate verification is passed, the system extracts the to-be-verified information from the request data packet. The to-be-verified information is digital information content that needs to be verified for integrity, and the data format of the to-be-verified information is consistent with the data format of the original information. The system delivers the to-be-verified information successfully received and the corresponding source point certificate to the subsequent semantic fingerprint reconstruction link for processing.

[0155] The current semantic fingerprint reconstruction program receives the information to be verified as input. The program reuses the processing logic and algorithm of the information fingerprint extraction module to recalculate and generate the semantic fingerprint of the information to be verified. The program first performs text preprocessing operations on the information to be verified, including word segmentation, denoising, and stop word removal, to obtain preprocessed text. Then, the program extracts semantic features from the preprocessed text using the same semantic feature extraction methods as the original information fingerprint extraction stage, such as TF-IDF algorithm, topic model, named entity recognition, and dependency syntax analysis, to obtain a multi-dimensional semantic feature set. The program then converts the semantic feature set into a semantic vector representation, using the same vector construction methods as the original information fingerprint extraction stage, such as word vector model and graph embedding technology. Finally, the program encodes the semantic vector using the same semantic hashing algorithm and parameter configuration as the original information fingerprint extraction stage, such as the local sensitive hashing algorithm, to obtain a fixed-length semantic hash code. The reconstruction program encapsulates the generated semantic hash code, as well as the algorithm version and parameter configuration used in the reconstruction process, to generate the current semantic fingerprint. The current semantic fingerprint serves as the semantic identity of the information to be verified.

[0156] The source point fingerprint comparison program receives the current semantic fingerprint and the information to be verified and the source point credential as input. The program extracts the source point semantic fingerprint of the original information from the source point credential. The comparison program uses the Hamming distance calculation method to calculate the Hamming distance between the current semantic fingerprint and the source point semantic fingerprint. Hamming distance measures the number of different characters at corresponding positions between two equal-length binary strings. The system presets a fingerprint comparison threshold, which is set in advance according to the system's tolerance for semantic similarity. The program compares the calculated Hamming distance with the preset threshold. If the Hamming distance is less than or equal to the preset threshold, it is determined that the current semantic fingerprint and the source point semantic fingerprint match successfully, and the fingerprint comparison result is "consistent". If the Hamming distance is greater than the preset threshold, it is determined that the current semantic fingerprint and the source point semantic fingerprint do not match, and the fingerprint comparison result is "inconsistent". The fingerprint comparison result is output in the form of a Boolean value, and can also be accompanied by the Hamming distance value.

[0157] The flow path backtracking procedure receives the information to be verified and the flow trajectory data as inputs. The procedure first queries all flow event records associated with the source point credential in the flow trajectory data storage system according to the source point credential in the information to be verified. The flow trajectory data storage system, such as a distributed ledger or a relational database, stores all flow path information of the information from the origin node. The query operation indexes based on the source point credential to retrieve all on-chain flow records or database records related to the source point credential. The procedure sorts the retrieved flow event records in chronological order to restore the complete flow path of the information from the source point to the current state. The procedure performs preliminary verification on the backtracked flow path, such as checking the timestamp order of the flow events, whether the event association relationship is complete, and whether there is a chain break. Further, the procedure performs integrity verification on each flow event record in the flow path. Assuming that each flow event record contains the hash value of the event data and the hash value of the previous event (forming a chain structure), the procedure recalculates the hash value of the current event data and compares it with the hash value stored in the record to verify whether the event data has been tampered with. At the same time, the procedure verifies whether the hash value of the previous event stored in the current event record is consistent with the actual hash value of the previous event, to verify the continuity and integrity of the flow chain. If the hash verification of any flow event fails, the flow path is determined to be an invalid path, and the flow path backtracking operation fails. If the hash verification of all flow events is successful, and the time order and association relationship of the flow events are correct, the procedure marks the flow path as a "verified path". The verified path is output in a structured data form, such as an ordered list of flow event records, each element in the list representing a flow event that has passed integrity verification, containing detailed information such as event occurrence time, event type, event operator, pre-change semantic fingerprint, post-change semantic fingerprint, event data hash value, etc. The verified path, as a reliable record of the history of information flow, is passed to the subsequent behavior consistency verification link.

[0158] The behavior consistency verification procedure receives the current semantic fingerprint and the verified path as input. The procedure traverses each flow event record in the verified path, and for each event, the procedure analyzes the event type and the semantic fingerprint change information recorded by the event. The procedure compares the "pre-change semantic fingerprint" recorded in the current event record with the "post-change semantic fingerprint" in the previous event record to verify whether the evolution trajectory of the semantic fingerprint is logical. For "modify" type flow events, the procedure further compares the current semantic fingerprint with the "post-change semantic fingerprint" recorded in the event record. Ideally, if the flow path record is complete and the information is not tampered with, the information state pointed to by the final "verified path" should be consistent with the content of the "to-be-verified information", therefore, the "current semantic fingerprint" obtained by reconstructing the "to-be-verified information" should match the "post-change semantic fingerprint" recorded in the last "modify" event (or the starting event if there is no modification) in the "verified path". The procedure compares the "current semantic fingerprint" with the "post-change semantic fingerprint" of the last valid event in the "verified path", and the comparison method can use semantic fingerprint similarity calculation, such as Hamming distance calculation, and set a similarity threshold. If the similarity is higher than the threshold, it is determined that the behavior consistency verification passes, and the behavior verification result is "consistent". If the similarity is lower than the threshold, it is determined that the behavior consistency verification does not pass, and the behavior verification result is "inconsistent", indicating that the actual information state deviates from the flow path recorded by the traceability system, and there may be abnormal situations such as unexpected modification of information content or incomplete flow path record. The behavior verification result is output in the form of a Boolean value, and can be accompanied by the semantic fingerprint similarity value and detailed information of inconsistency.

[0159] The abnormal pattern recognition engine receives the verified path and the behavior verification results as inputs. The engine pre-defines multiple abnormal behavior patterns, such as: "unauthorized modification" pattern: the occurrence of modification events by unauthorized users in the verified path; "jumping flow transfer" pattern: the lack of necessary intermediate flow transfer links in the verified path; "suspected content tampering" pattern: the behavior consistency verification result is "inconsistent", and the fingerprint similarity is lower than the significant threshold; "malicious sharing diffusion" pattern: information is shared to high-risk or unauthorized target objects; "operation time abnormality" pattern: the flow transfer event occurrence time is inconsistent with normal working hours or operation habits. The engine traverses the verified path and combines the behavior verification results to detect whether there is a pre-defined abnormal behavior pattern one by one. The detection methods include rule matching, statistical analysis, machine learning anomaly detection algorithm, etc. For example, for the "unauthorized modification" pattern, the engine checks the operator identity of each modification event, compares it with the permission list, and judges whether it is an authorized user. For the "suspected content tampering" pattern, the engine directly refers to the results of the behavior consistency verification. For the "jumping flow transfer" pattern, the engine analyzes the flow transfer event sequence and checks whether there is a missing expected intermediate state or link. If any abnormal behavior pattern is detected, the engine generates a corresponding abnormal behavior report. The abnormal behavior report describes the abnormal type, abnormal occurrence time, involved flow transfer events, potential risk level, and suggested disposal measures in detail. If no abnormal behavior pattern is detected, an empty abnormal behavior report is generated, indicating that no abnormality is found. The abnormal behavior report is output in a structured data form, for example, the abnormal pattern recognition engine analyzes the verified path and finds that the operator identity of one of the "modification" events is "unauthorized user", the engine determines that the "unauthorized modification" abnormal pattern is triggered, and generates an abnormal behavior report, the report type is "unauthorized modification", the risk level is "high", and the suggested measures are "immediately roll back the modification operation and lock the unauthorized user account".

[0160] The verification result summary and report generation program receives the fingerprint comparison results, behavior verification results, and abnormal behavior reports as inputs. The program integrates and summarizes these three parts of the verification results to form a complete report to be signed. The report to be signed is organized in a structured data form, such as JSON or XML format,

[0161] After the signed report is generated, the verification report generation link is entered. The verification report generation program receives the signed report as input. In order to ensure the non-tamperability and authority of the traceability verification report, the system will digitally sign the signed report. The digital signature process uses asymmetric encryption technology, such as the RSA algorithm or the ECDSA algorithm. The system uses the private key of the verification server to encrypt the hash value of the signed report, generating a digital signature. The digital signature and the original text of the signed report constitute the final traceability verification report. The data format of the traceability verification report can be a PDF document, a JSON file, or an XML file. The report contains the complete content of the signed report and additional digital signature information. In order to facilitate the verification of the authenticity of the traceability verification report, the report usually contains the public key information of the verification server, or provides a way to obtain the public key. The verifier who receives the traceability verification report can use the public key of the verification server to decrypt the digital signature in the report, obtain the decrypted hash value, and recalculate the hash value of the original report, and compare the two hash values. If they are consistent, it means that the traceability verification report has not been tampered with, and it is indeed verified by the server, ensuring the authenticity and credibility of the report. The final traceability verification report is stored by the system, and the report can be pushed to the requestor according to the requestor's needs, or the report query and download service can be provided. For example, the traceability verification report can be presented in PDF format, with the report cover page displaying the "Traceability Verification Report" title, containing verification information summary, fingerprint comparison conclusion, behavior verification conclusion, abnormal behavior report content, verified flow path summary, verification conclusion summary, etc. The report back page is accompanied by the digital signature of the verification server, as well as the public key acquisition QR code, ensuring the authority and verifiability of the report.

[0162] Preferably, the behavior consensus feedback module includes the following functions:

[0163] The traceability verification report is distributed to obtain a report to be consensus;

[0164] According to the report to be consensus, the consensus process is started to obtain a consensus proposal;

[0165] According to the report to be consensus and the consensus proposal, node evaluation and voting are performed to obtain disposal votes;

[0166] The voting results of the disposal votes are summarized to obtain a consensus vote warehouse;

[0167] According to the preset consensus algorithm and the consensus vote warehouse, a consensus decision is formed to obtain a consensus resolution draft;

[0168] According to the consensus resolution draft, the disposal measures are executed to obtain an execution instruction; according to the execution instruction, the execution result is recorded to obtain a disposal record;

[0169] The consensus resolution draft, the consensus vote warehouse, and the disposal record are finally resolved to obtain disposal resolution data.

[0170] In the embodiment of the present application, the verification report distribution program is responsible for delivering the provenance verification report generated by the information integrity verification module to each node in the consensus network to start the subsequent consensus decision-making process. The distribution program first receives the provenance verification report from the information integrity verification module. The program then constructs a message containing the report, and the message header contains the unique identifier of the report, the report type (provenance verification report), and the target consensus network identifier. The message body encapsulates the complete provenance verification report content, which adopts a predefined structured data format, such as JSON or ProtocolBuffers. The distribution program broadcasts the constructed message to all participating nodes in the consensus network according to the preset consensus network communication protocol, such as a point-to-point communication protocol based on gRPC or ZeroMQ. Each node in the consensus network receives the broadcast message, parses the message header, identifies the message type as a provenance verification report, and stores the report content in the message body to the local message queue as a consensus report, waiting for subsequent consensus process processing. For example, the verification report distribution program encapsulates the generated provenance verification report into a gRPC message, and the target address list of the message is a pre-configured consensus network node IP address list. The program loops through the target address list and sends the gRPC message to the target node one by one to ensure that each consensus node receives the consensus report.

[0171] The consensus process start program monitors the local message queue of the consensus network node and monitors in real time whether there is a new consensus report. When a new consensus report is detected, the program takes the report from the message queue. The program parses the content of the consensus report and extracts key information such as the overall evaluation of the verification conclusion, the fingerprint comparison result, the behavior verification result, and the abnormal behavior report in the report. The program then generates a consensus proposal, which is an instruction to start the consensus voting process. The consensus proposal contains the summary information of the consensus report, such as the report ID, the verification object information, the overall evaluation of the verification conclusion, and the target and scope of the consensus. The target of the consensus is usually the conclusion of the provenance verification report to form a consensus resolution, for example, if the verification report indicates that the information integrity verification fails, the target of the consensus may be to determine the disposal measures to be taken. The scope of the consensus defines the range of nodes participating in the consensus voting, such as all consensus nodes or specific role nodes. The consensus process start program broadcasts the generated consensus proposal to the consensus network to notify all related nodes to start the consensus voting process for the provenance verification report.

[0172] The node evaluation and voting program runs on each node in the consensus network. The program receives the consensus proposal broadcast from the consensus process initiator and obtains the locally stored consensus-to-be reports. The program first determines whether it is a node participating in the consensus voting according to the target and scope of the consensus proposal. If it is determined to be a participating node, the program starts to evaluate the traceability verification report. The evaluation process is mainly based on the total evaluation of the verification conclusion, the fingerprint comparison result, the behavior verification result and the abnormal behavior report in the consensus-to-be report. The node independently judges the conclusion of the report according to the preset evaluation strategy and the information it masters, and forms a disposal opinion according to the judgment result. The disposal opinion usually shows the voting selection of different disposal measures, such as "maintain the status quo", "alarm", "manual intervention", "data rollback" and the like. The program encapsulates the disposal opinion of the node and the node identity information to generate a disposal vote. The disposal vote is signed by using a digital signature technology to ensure the non-tamperability and traceability of the vote. The node evaluation and voting program sends the generated disposal vote to the voting result aggregation program to participate in the subsequent voting result statistics and consensus decision formation. For example, after the consensus node receives the consensus proposal for a traceability verification report, the node program automatically reads the report and analyzes the report conclusion as "information integrity verification failed, there is unauthorized modification anomaly". The node program determines that the abnormal behavior risk level is "high" according to the preset risk evaluation strategy, and votes for the disposal measures as "data rollback" and "alarm", generates a disposal vote containing the voting selection and the node signature, and sends it to the voting result aggregation node.

[0173] The vote result aggregation program is responsible for collecting and aggregating the disposal votes from all participating nodes in the consensus network to form a consensus vote pool. The program continuously monitors a pre-configured vote receiving port and receives disposal votes sent by various consensus nodes. After receiving a disposal vote, the program first verifies the digital signature of the vote to ensure its validity and trustworthiness. Valid votes that pass the verification are stored in a local consensus vote pool data structure. The consensus vote pool typically uses a hash table or linked list data structure to store all valid votes for a report using the report ID as the index. The program continuously collects votes until the pre-configured vote deadline is reached or the pre-configured minimum number of voting nodes threshold is met. When the voting end conditions are met, the vote result aggregation program stops receiving new votes and begins to analyze the votes in the consensus vote pool to provide a data foundation for the subsequent consensus decision-making stage. For example, the vote result aggregation program is deployed on a designated node in the consensus network and is responsible for receiving vote information from all consensus nodes. After receiving a "data rollback" vote for report XXX sent by node A, the program verifies the signature and stores the vote in the consensus vote pool with report XXX as the key value. The program continues to receive votes from node B, node C, and other nodes until the voting time ends, at which point the program stops receiving votes and begins to analyze the voting results.

[0174] The consensus decision-making program receives the consensus vote pool as input and calculates and decides the voting results in the consensus vote pool according to the pre-configured consensus algorithm to form a consensus resolution draft. The program first extracts all valid votes from the consensus vote pool. The program then analyzes the voting results according to the pre-configured consensus algorithm. The program calculates the voting data in the consensus vote pool according to the selected consensus algorithm to obtain a consensus determination result. The consensus determination result explicitly indicates the final adopted disposal measure, such as "perform a data rollback operation," "send an alarm notification," "start a manual review process," or "maintain the current state." The program integrates the consensus determination result and the voting statistical data (such as the vote distribution of various disposal measures, the list of nodes participating in the vote, etc.) to generate a consensus resolution draft. The consensus resolution draft is the preliminary result of consensus decision-making and needs to go through subsequent execution and solidification stages before it can take effect. The consensus resolution draft is output in a structured data format, such as JSON, containing information such as the consensus algorithm type, the consensus determination result, the voting statistical data, the list of voting nodes, and the resolution draft generation time. For example, if the consensus algorithm is simple majority voting and the consensus vote pool shows that the "alarm" measure has the most votes, the consensus decision-making program generates a consensus resolution draft with the content "Consensus resolution: adopt disposal measure 'alarm', voting results: 'alarm' 5 votes,'manual intervention' 3 votes,'maintain the status quo' 2 votes, nodes participating in the vote: [node A, node B, node C, node D, node E, node F, node G, node H, node I, node J]."

[0175] The treatment measure execution program receives the consensus resolution draft as input. The program parses the consensus resolution draft and identifies the final treatment measure formed by the consensus decision. According to different treatment measure types, the program calls corresponding execution modules or components to perform specific treatment operations. For example, if the consensus resolution is "data rollback", the program calls the data rollback module and passes relevant parameters (such as information ID to be rolled back, rollback target version, etc.) to perform the data rollback operation and restore the information data to a previous version state. If the consensus resolution is "alarm", the program calls the alarm notification component and sends alarm notifications to relevant responsible persons or monitoring systems according to the preset alarm strategy. The notification content includes alarm type, alarm object, alarm level, and link to the traceability verification report, etc. The execution program records the results of the treatment measure execution and generates a treatment record. The treatment record describes the type of executed treatment measure, execution time, execution result (success or failure), log information during execution, and operator information, etc. The treatment record provides a basis for subsequent audit and traceability. The execution instruction is a specific command to drive the execution of the treatment measure. According to different treatment measures, the content and form of the execution instruction are also different. For example, if the treatment measure is "data rollback", the execution instruction may include a SQL rollback statement or an API call instruction. If the treatment measure is "alarm", the execution instruction may include a mail sending instruction or a message queue pushing instruction. The treatment record is output in a structured data format, such as JSON format, including treatment measure type, execution time, execution status, execution log, and operator, etc. For example, if the consensus resolution draft indicates to execute "data rollback" operation, the treatment measure execution program calls the data rollback module and records the execution process log "start data rollback…data version verification passed…data rollback success…", finally generates the treatment record, records the treatment measure as "data rollback", the execution status as "success", the execution time as the current time, and contains detailed execution log.

[0176] The final resolution solidification program receives the consensus resolution draft, the consensus vote warehouse, and the disposal record as input. The program persists the key data in the consensus decision-making process, such as the consensus resolution draft, the consensus vote warehouse, and the disposal record, to form the final disposal resolution data. The final resolution data is usually stored in a high-reliability, tamper-proof data storage medium, such as a distributed ledger system or a special audit database. The data solidification process uses a hash anchoring technology to anchor the hash value of the disposal resolution data to a blockchain or other trusted timestamp service, ensuring the non-tamperability of the data and the authority of the timestamp. The final solidified disposal resolution data is the final output result of the behavior consensus feedback link in the information traceability management process, providing irrefutable evidence for subsequent audits, supervision, and dispute resolution. The disposal resolution data contains the complete process information of the consensus decision, including the consensus proposal, the voting vote, the voting result statistics, the consensus resolution draft, the final disposal measures, and the disposal execution record, etc., forming a complete decision chain, realizing the transparency and traceability of the behavior consensus feedback process. The disposal resolution data is stored in a structured data form,

[0177] Preferably, the consensus decision-making according to the preset consensus algorithm and the consensus vote warehouse comprises:

[0178] Voting result statistics are performed on the consensus vote warehouse to obtain voting statistics data;

[0179] Consensus algorithm application is performed according to the preset consensus algorithm and the voting statistics data to obtain a consensus determination result;

[0180] Disposal measure determination is performed according to the consensus determination result to obtain a final disposal measure;

[0181] Consensus resolution draft generation is performed on the consensus determination result, the final disposal measure, and the voting statistics data to obtain a consensus resolution draft.

[0182] In the embodiment of the application, the voting result statistics program receives consensus vote warehouse data as input, which contains disposal votes of all consensus nodes. The program first traverses the consensus vote warehouse, and for each vote, parses the voting node identity and the disposal measure selected by the voting node. The program uses a hash mapping table or dictionary data structure, with the disposal measure type as the key and the vote counter as the value, to initialize the data structure. The program traverses all votes, and whenever a vote is encountered, the selected disposal measure type is extracted, and the vote counter value corresponding to the disposal measure type in the hash mapping table is incremented by one. After the program completes the traversal of all votes, the hash mapping table stores the final vote count statistics of various disposal measures. The voting statistics data is output in a structured data form, such as JSON format, containing each disposal measure type and its corresponding vote count.

[0183] The consensus algorithm application module receives the voting statistics data and the preset consensus algorithm rule as input. In this embodiment, the preset consensus algorithm is the simple majority voting algorithm. The rule of the simple majority voting algorithm is that among all the candidate treatment measures, the treatment measure with the highest number of votes will be determined as the consensus decision result. The consensus algorithm application module first parses the voting statistics data to obtain the number of votes for each treatment measure. The program compares the number of votes for each treatment measure and finds the treatment measure with the highest number of votes. If there are multiple treatment measures with the same number of votes and all are the highest, the program selects according to the preset priority rule. The priority rule can be preset, for example, the risk level or execution cost of the treatment measure is sorted, and the highest priority measure is selected. If there is no priority rule, the program can randomly select one of the treatment measures with the highest number of votes. The program outputs the finally selected treatment measure as the consensus decision result.

[0184] The treatment measure determination module receives the consensus decision result as input. The consensus decision result is a text string output by the consensus algorithm application module, indicating the type of treatment measure selected by the consensus network voting, such as "alarm", "manual intervention" or "data rollback", etc. The treatment measure determination module directly converts the consensus decision result into the final treatment measure instruction executable by the system. The module is pre-configured with a mapping relationship between the treatment measure type and the specific execution instruction. For example, if the consensus decision result is "alarm", the treatment measure determination module maps it to the "send alarm notification" instruction; if the consensus decision result is "manual intervention", it is mapped to the "start manual review process" instruction; if the consensus decision result is "data rollback", it is mapped to the "execute data rollback operation" instruction. The final treatment measure is output in the form of instructions that can be recognized and executed by the system internally, such as enumeration type, instruction object or API call parameters, etc. For example, the consensus decision result is "alarm". The treatment measure determination module queries the preset treatment measure mapping table and finds that the instruction corresponding to "alarm" is "SEND_ALARM_NOTIFICATION". The module outputs the final treatment measure instruction as the enumeration value SEND_ALARM_NOTIFICATION, which will be passed to the treatment measure execution module to drive the execution of the alarm notification function.

[0185] The consensus resolution draft generation module receives the consensus decision result, the final handling measure, and the voting statistics as inputs. The module integrates these input data to generate a structured consensus resolution draft document. The consensus resolution draft document adopts a predefined format, such as JSON or XML, and contains the following key information: a "consensus algorithm type" field, which records the consensus algorithm adopted in this consensus decision, such as "simple majority voting algorithm"; a "consensus decision result" field, which records the decision result of the consensus algorithm, i.e., the handling measure type selected by voting, such as "alarm"; a "final handling measure" field, which records the final handling measure instruction determined by the system, such as the enumerated value SEND_ALARM_NOTIFICATION; and a "voting statistics" field, which embeds the complete voting statistics,

[0186] Therefore, embodiments should be considered in all respects as illustrative and not restrictive, the scope of the application being indicated by the appended claims rather than by the description given above, therefore all variations falling within the meaning and the scope of the equivalent requirements of the application file are intended to be encompassed by the present application.

[0187] The foregoing is considered as illustrative only of the principles of the application. Numerous modifications and adaptations will be apparent to those skilled in the art in view of the above descriptions of the embodiments. This specification and the embodiments are not therefore to be taken in a limiting sense, but are made within the spirit of the scope of the application, and including all equivalent arrangements and methods. The scope of the application should be determined by the appended claims and the above specification, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A digital information provenance management system, characterized by, The information fingerprint extraction module includes an NLP processing server and a cache server, and is used to obtain original information; text preprocessing is performed on the original information to obtain preprocessed text; semantic feature extraction is performed on the preprocessed text to obtain semantic features; semantic vector construction is performed on the semantic features to obtain semantic vectors; semantic hash coding is performed on the semantic vectors to obtain semantic hash codes; and semantic fingerprint generation is performed on the semantic hash codes to obtain semantic fingerprints; The origin node consensus module includes a consensus node server, which is used to perform consensus processing on the semantic fingerprints based on the origin node to obtain a consensus result; and source point certificate generation is performed according to the consensus result to obtain a source point certificate; The flow path mapping module includes a behavior data collector, which is used to trigger a flow behavior according to the source point certificate to obtain a behavior to be recorded; content change analysis is performed according to the behavior to be recorded to obtain a changed semantic fingerprint; The flow path mapping module includes a behavior data collector, which is used to trigger a flow behavior according to the source point certificate to obtain a behavior to be recorded; content change analysis is performed according to the behavior to be recorded to obtain a changed semantic fingerprint; The information integrity verification module includes a verification server and an abnormal pattern detection engine, and is used to receive a verification request according to the source point certificate to obtain information to be verified; The information integrity verification module includes a verification server and an abnormal pattern detection engine, and is used to receive a verification request according to the source point certificate to obtain information to be verified; The behavior consensus feedback module includes a consensus node server and a monitoring and disposal component, which is used to perform node consensus voting according to the traceability verification report to obtain a consensus vote warehouse; consensus decision formation is performed according to a preset consensus algorithm and the consensus vote warehouse to obtain a consensus resolution draft; and resolution measures are executed according to the consensus resolution draft to obtain disposal resolution data, so as to realize digital information traceability management operation. The semantic feature extraction on the preprocessed text includes: initial keyword extraction is performed on the preprocessed text to obtain an initial keyword list; topic distribution mining is performed on the preprocessed text to obtain a topic probability distribution; 2. The digitalized information provenance management system of claim 1, wherein, named entity recognition is performed on the preprocessed text to obtain a named entity set; dependency syntax analysis is performed on the preprocessed text to obtain a dependency relationship graph; semantic feature fusion and enhancement are performed on the initial keyword list, the topic probability distribution, the named entity set and the dependency relationship graph to obtain semantic features. The origin node consensus module includes the following functions: origin information encapsulation is performed on the semantic fingerprints to obtain information to be consensus; network broadcast submission is performed on the information to be consensus to obtain a broadcast request; 3. The digitalized information provenance management system of claim 1, wherein, initial verification is performed on the broadcast request to obtain information to be verified; consensus proposal and voting are performed on the information to be verified to obtain consensus votes; consensus result confirmation is performed on the consensus votes according to a preset consensus algorithm to obtain a consensus result; source point certificate generation is performed according to the consensus result to obtain a source point certificate. The flow path mapping module includes the following functions: flow behavior triggering is performed according to the source point certificate to obtain a behavior to be recorded; ​ 4. The digitalized information provenance management system of claim 1, wherein, ​ ​ According to the behavior to be recorded, content change analysis is performed to obtain a changed semantic fingerprint; According to the behavior to be recorded and the changed semantic fingerprint, a flow event is constructed to obtain a flow snapshot; The flow snapshot is subjected to flow record addition to obtain a to-be-chained record; According to the preset distributed ledger, the to-be-chained record is subjected to distributed ledger writing to obtain a chain flow record; According to the chain flow record and the source point certificate, a flow track is updated to obtain flow track data.

5. The digitalized information provenance management system of claim 4, wherein, The content change analysis according to the behavior to be recorded comprises: An operation type judgment is performed on the behavior to be recorded to obtain an operation type result; According to the operation type result, content version acquisition is performed to obtain original version data and modified version data; Fine-grained difference detection is performed on the original version data and the modified version data to obtain a content difference segment; A semantic change degree is evaluated on the content difference segment to obtain a semantic change degree; The modified semantic fingerprint is generated according to the semantic change degree to obtain a changed semantic fingerprint.

6. The digitalized information provenance management system of claim 5, wherein, The fine-grained difference detection on the original version data and the modified version data comprises: Row-level preprocessing is performed on the original version data and the modified version data to obtain a row-split original version and a row-split modified version; Row-level difference comparison is performed on the row-split original version and the row-split modified version to obtain a row-level difference result; Word-level preprocessing is performed on the row-level difference result to obtain a to-be-word-level comparison original row and a to-be-word-level comparison modified row; Word-level difference comparison is performed on the to-be-word-level comparison original row and the to-be-word-level comparison modified row to obtain a word-level difference result; Difference segment structuring is performed on the row-level difference result and the word-level difference result to obtain a content difference segment.

7. The digitalized information provenance management system of claim 1, wherein, The information integrity verification module comprises the following functions: According to the source point certificate, a verification request is received to obtain to-be-verified information; The current semantic fingerprint is reconstructed according to the to-be-verified information to obtain a current semantic fingerprint; The source point fingerprint is compared according to the current semantic fingerprint and the to-be-verified information to obtain a fingerprint comparison result; According to the to-be-verified information and the flow track data, a flow path is backtracked to obtain a verified path; According to the current semantic fingerprint, the behavior consistency of the verified path is verified to obtain a behavior verification result; An abnormal mode is identified according to the verified path to obtain an abnormal behavior report; The fingerprint comparison result, the behavior verification result and the abnormal behavior report are summarized to obtain a to-be-signed report; the to-be-signed report is subjected to a verification report generation to obtain a traceability verification report.

8. The digitalized information provenance management system of claim 1, wherein, The behavior consensus feedback module comprises the following functions: The traceability verification report is subjected to a verification report distribution to obtain a to-be-consensus report; According to the to-be-consensus report, a consensus process is started to obtain a consensus proposal; According to the to-be-consensus report and the consensus proposal, node evaluation and voting are performed to obtain a disposal vote; The disposal vote is subjected to a voting result summary to obtain a consensus vote pool; According to the preset consensus algorithm and the consensus vote pool, a consensus decision is formed to obtain a consensus resolution draft; According to the consensus resolution draft, a disposal measure is executed to obtain an execution instruction; according to the execution instruction, an execution result is recorded to obtain a disposal record; The consensus resolution draft, the consensus vote warehouse and the disposal record are finally solidified to obtain disposal resolution data.

9. The digitalized information provenance management system of claim 8, wherein, The consensus decision formation according to the preset consensus algorithm and the consensus vote warehouse comprises: The voting result statistics of the consensus vote warehouse are obtained to obtain voting statistics data; The consensus algorithm application according to the preset consensus algorithm and the voting statistics data is performed to obtain a consensus determination result; The disposal measure determination according to the consensus determination result is performed to obtain a final disposal measure; The consensus resolution draft is generated according to the consensus determination result, the final disposal measure and the voting statistics data to obtain a consensus resolution draft.

Images