Data monitoring processing system and method based on blockchain hash pointer verification

Abstract

The present application belongs to the field of data processing, and particularly relates to a data monitoring processing system and method based on blockchain hash pointer verification, aiming to solve the problems of data redundancy, weak tamper-proofing capability and insufficient abnormal identification accuracy caused by fixed weight fusion strategy of the existing centralized monitoring system; the system comprises collection, preprocessing, fusion calculation and feedback nodes constituting a monitoring feedback chain; the collection node dynamically clips the collection field based on the object growth stage, and constructs a chain verification structure through double hash operation; the preprocessing node calls a dynamic weight distribution matrix based on the timing context; the fusion calculation node generates a monitoring index through weighted fusion, and completes abnormal identification based on the dynamic threshold set by the reference object of the same growth stage; the feedback node forms a full-link verification closed loop through bidirectional hash pointers. The present application can reduce the storage redundancy on the chain, improve the abnormal monitoring accuracy and stability under the premise of ensuring data unforgeability.

Description

Technical Field

[0001] This invention belongs to the field of data processing, and in particular relates to a data monitoring and processing system and method based on blockchain hash pointer verification. Background Technology

[0002] Existing data monitoring systems mostly adopt a centralized server combined with a fixed field form collection architecture. They use a preset static weighted model to fuse and calculate the indicators of each monitoring dimension to generate monitoring results. However, such technical solutions face the following structural contradictions in actual deployment: At the data acquisition and storage layer, key performance indicators of monitored objects at different growth stages exhibit significant heterogeneity. Fixed field templates cannot be dynamically tailored according to object profiles, resulting in on-chain nodes needing to transmit and store a large amount of low-information-entropy redundant data. Simultaneously, existing solutions rely on centralized comparison mechanisms for cross-validation of acquired data and external data sources, lacking underlying verification methods for data tampering and abnormal changes; data credibility depends entirely on a single point of commitment from the acquisition end. At the intermediate fusion layer, existing models lack adaptive adjustment mechanisms for the sensitivity differences of various feature dimensions under different time periods and operating environments. For example, the contribution of the same monitoring dimension fluctuates significantly at different growth stages, and fixed-weight fusion strategies dilute the identification strength of key signals. Therefore, how to construct a data processing architecture that can perform integrity verification of acquired data based on a chained hash pointer structure, dynamically adjust the set of acquired fields according to the object's growth stage, and adaptively allocate multi-dimensional feature fusion weights based on the time context, in order to reduce node storage redundancy and improve the real-time accuracy of anomaly identification while ensuring data immutability, has become a pressing technical problem to be solved in this field. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention proposes a data monitoring and processing system and method based on blockchain hash pointer verification. The system includes acquisition, preprocessing, fusion calculation, and feedback nodes forming a monitoring feedback chain. The acquisition nodes dynamically trim acquisition fields based on the object's growth stage and construct a chain-like verification structure through double hash operations. The preprocessing node retrieves a dynamic weight allocation matrix based on the time-series context. The fusion calculation node generates a monitoring index through weighted fusion and determines dynamic thresholds based on reference objects at the same growth stage to complete anomaly identification. The feedback node forms a closed-loop verification chain through bidirectional hash pointers. This invention can reduce on-chain storage redundancy and improve the accuracy and stability of anomaly monitoring while ensuring data immutability.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A data monitoring and processing system based on blockchain hash pointer verification includes a monitoring feedback chain; the monitoring feedback chain includes:

[0006] The data collection node is configured to: acquire unstructured document data and corresponding object profile identifiers uploaded by the terminal of the monitored object, and generate structured panel data; perform a first hash operation on the structured panel data to generate a first hash value; determine the growth stage category to which the monitored object belongs based on the object profile identifier, and prune the set of fields to be filled to generate a dimensionality-reduced subset of data collection fields based on the field correlation threshold corresponding to the growth stage category;

[0007] The preprocessing node is configured to: call the hash pointer stored in the block header to perform integrity verification on the structured panel data and generate a normalized feature value sequence; and retrieve a preset weight allocation matrix based on the time-series context identifier corresponding to the current acquisition cycle.

[0008] The fusion computing node is configured to: perform weighted fusion on the normalized feature value sequence based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix to obtain the comprehensive monitoring index time-series data of the monitored object; input the comprehensive monitoring index time-series data into a preset trend deviation detection model, and output a monitoring result containing an anomaly level identifier and a deviation direction identifier based on the baseline threshold range defined by the comprehensive monitoring index distribution characteristics of reference objects under the same growth stage category.

[0009] Specifically, the time-series context identifier is composed of a growth stage identifier and an operating environment stage identifier, and the weight allocation matrix records the dynamic weight coefficients of each monitoring dimension under different time-series context combinations.

[0010] The dynamic weighting coefficients are obtained by iteratively training historical panel data through a pre-built time-series sensitivity analysis model, and are used to characterize the difference in the contribution of the same monitoring dimension to the comprehensive monitoring results under different growth stages and operating environment stages; the monitoring feedback chain also includes: a feedback node, configured to: perform a hash operation on the monitoring results to generate a second hash value, and write the second hash value into the header of the next block associated with the current block.

[0011] Specifically, the data acquisition nodes generate structured panel data, which is configured as follows:

[0012] Based on the object profile identifier, a corresponding structured data table template is matched from a preset template library. The template includes field names, data types, units, value ranges, and field correlation benchmark values.

[0013] The semantic-rule hybrid parsing engine is invoked to extract key numerical fields from the unstructured document;

[0014] The extracted key numerical fields are mapped to the structured data table template according to the field name to generate structured panel data, where unmatched template fields are filled with null value identifiers.

[0015] Specifically, the data acquisition nodes are also configured as follows:

[0016] The generated first hash value is uniquely bound to the current collection period. The structured panel data and the first hash value are associated and stored in the block body of the current block in the form of key-value pairs. The key is a combination of the current collection period identifier and the identifier of the monitored object, and the value is the structured panel data and the first hash value.

[0017] A second hash operation is performed on the subset of collected fields to generate a second hash value. The second hash value is written into the block header of the current block, and the first hash value is used as a forward hash pointer in the block header to point to the block body hash of the previous block, forming a chained hash verification structure.

[0018] Specifically, the preprocessing node is also configured as follows:

[0019] Obtain the structured panel data output by the acquisition node, and match at least one corresponding external data source from the preset external data source configuration table according to the growth stage category code in the object profile identifier;

[0020] Using the timestamp of the first preset period configured by the acquisition node as the alignment reference, a time-series alignment operation is performed on the structured panel data and the external data source to generate an aligned multidimensional data matrix with the acquisition period timestamp as the primary key.

[0021] Specifically, the preprocessing node performs integrity checks, and is configured as follows:

[0022] Re-execute the first hash operation on the currently acquired structured panel data to generate a hash value to be verified; read the second hash value from the block header of the current block, and compare whether the hash value to be verified is consistent with the second hash value:

[0023] If they match, the integrity check is considered successful; if they do not match, a data integrity error alarm is triggered, the current preprocessing process is stopped, and a check failure record containing the block identifier and the collection period identifier is output to the management terminal.

[0024] Specifically, the fusion computing node defines a baseline threshold range, which is configured as follows:

[0025] Based on the growth stage category code of the monitored object, a list of object identifiers of all reference objects belonging to the same growth stage category is retrieved from the reference object registry stored on the blockchain.

[0026] Obtain the time series data of the comprehensive monitoring index of each reference object within the most recent preset sliding window length of collection period, and calculate the lower quartile and upper quartile of the comprehensive monitoring index of all reference objects at each time position within the sliding window;

[0027] Calculate the interquartile range (ICM), and based on the ICM and a preset tolerance boundary coefficient, define the baseline threshold interval corresponding to the current time position.

[0028] Specifically, the trend deviation detection model is also configured as follows:

[0029] Based on the relative position of the comprehensive monitoring index of the current collection period and the benchmark threshold range, the deviation direction determination logic is executed, and the corresponding deviation direction identifier is output.

[0030] Calculate the deviation of the current comprehensive monitoring index from the benchmark threshold range, and output the abnormal level label according to the numerical range of the deviation and the preset level classification rules; when the deviation direction label is no deviation, the abnormal level label is forcibly set to the normal level.

[0031] Specifically, the feedback node is also configured as follows:

[0032] The preset monitoring result storage smart contract is invoked to write the monitoring result and the corresponding second hash value into the distributed ledger, and an association is established between the monitoring result record and the hash pointer of the block where the original collected data is located.

[0033] Read the anomaly level identifier and deviation direction identifier from the monitoring results, generate the corresponding task generation instruction according to the preset task triggering rule table, and output the task generation instruction to the management terminal according to the corresponding transmission method matched by the type of management terminal.

[0034] Data monitoring and processing methods based on blockchain hash pointer verification include:

[0035] The system acquires unstructured document data uploaded by the monitored object's terminal and the corresponding object profile identifier, and generates structured panel data; performs a first hash operation on the structured panel data to generate a first hash value; determines the growth stage category to which the monitored object belongs based on the object profile identifier, and prunes the set of fields to be filled to generate a dimensionality-reduced subset of collected fields based on the field correlation threshold corresponding to the growth stage category;

[0036] The hash pointer stored in the block header is invoked to perform integrity verification on the structured panel data, generating a normalized feature value sequence; based on the time-series context identifier corresponding to the current acquisition cycle, the preset weight allocation matrix is ​​retrieved;

[0037] Based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix, the normalized feature value sequence is weighted and fused to obtain the comprehensive monitoring index time-series data of the monitored object; the comprehensive monitoring index time-series data is input into a preset trend deviation detection model, and a benchmark threshold range is defined based on the comprehensive monitoring index distribution characteristics of reference objects under the same growth stage category, and a monitoring result including anomaly level identifier and deviation direction identifier is output;

[0038] A hash operation is performed on the monitoring result to generate a second hash value, and the second hash value is written into the header of the next block associated with the current block.

[0039] Compared with the prior art, the beneficial effects of the present invention are:

[0040] This invention dynamically prunes low-relevance fields based on the growth stage of the data collection nodes, and hashes only a subset of the collected fields after dimensionality reduction onto the blockchain. This significantly reduces the storage redundancy of blockchain nodes while ensuring data traceability. By using the hash pointer stored in the block header to construct a two-way verification closed loop, any tampering at any stage from the original panel data to the final monitoring results can be accurately located, fundamentally eliminating the trust risk of single-point dependence. The preprocessing node introduces a temporal context identifier combining the growth stage and the operating environment stage, and retrieves a weight allocation matrix pre-trained based on an attention-based long short-term memory network. This allows the multi-dimensional feature fusion weights to be dynamically adjusted according to the object's state, overcoming the drawback of fixed weights diluting key signals. The fusion calculation node defines the baseline threshold range using the interquartile range within a sliding window of a group of reference objects at the same growth stage. Based on the deviation of the comprehensive monitoring index, it outputs the anomaly level and direction identifier, effectively suppressing false alarms and false negatives at different growth stages with fixed thresholds. Finally, the feedback node hashes the monitoring results and writes them into the next block header to form a closed-loop evidence storage system. It also automatically triggers differentiated handling tasks based on the anomaly level, achieving a reliable, high-precision, and low-redundancy intelligent monitoring system across the entire chain from data acquisition and fusion calculation to response handling. Attached Figure Description

[0041] Figure 1 This is a node diagram of the data monitoring and processing system based on blockchain hash pointer verification according to Embodiment 1 of the present invention;

[0042] Figure 2 This is a flowchart of the data acquisition node execution process in Embodiment 1 of the present invention;

[0043] Figure 3 This is a flowchart of the preprocessing node execution in Embodiment 1 of the present invention;

[0044] Figure 4 This is a flowchart of the execution process of the fusion computing node in Embodiment 1 of the present invention. Detailed Implementation

[0045] Example 1

[0046] Please see Figure 1 The present invention provides an embodiment of a data monitoring and processing system based on blockchain hash pointer verification, comprising a monitoring feedback chain consisting of acquisition nodes, preprocessing nodes, fusion computing nodes, and feedback nodes; wherein:

[0047] Further explanation is needed; please refer to [link / reference]. Figure 2 In this embodiment, the data acquisition node is configured as follows:

[0048] Furthermore, in this embodiment, the first preset period is pre-configured differently based on the growth stage category of the monitored object. For monitored objects in different growth stages such as startup, growth, and maturity, weekly, bi-weekly, and monthly collection periods are set respectively to adapt to the monitoring data update frequency and business reporting patterns of monitored objects at different growth stages. The growth stage category coding adopts a preset enumeration value coding rule, assigning a unique and non-repeatable numerical code to each growth stage to ensure that the mapping relationship between the object profile identifier and the growth stage category is uniquely determined. Furthermore, in this embodiment... The object profile identifier is configured with a growth stage adaptive update mechanism. Based on the continuous periodic operating data of the monitored object, it can automatically and dynamically determine and update the growth stage category code, solving the technical problems of template matching, field pruning, weight allocation mismatch with the actual development status of the enterprise caused by the solidification of growth stages. The growth stage update determination cycle is a multiple of the first preset cycle of the monitored object: 12 collection cycles for start-up objects, 24 collection cycles for growth objects, and 36 collection cycles for mature objects, ensuring a balance between the stability and timeliness of growth stage determination. Further, in one specific implementation of this embodiment, after the collection node completes the data normalization of the current collection cycle, it synchronously executes the growth stage update verification process, specifically:

[0049] The first step is to retrieve the time-series data of the core operating indicators of the monitored object for the most recent 12 consecutive collection periods. The core operating indicators include four preset dimensions: operating revenue, net asset size, R&D investment ratio, and personnel size. For each dimension, the original value of the indicator for each period within the 12 collection periods and the month-on-month growth rate of the indicator for the 12 periods are extracted to form a 12×8 dimension feature matrix.

[0050] The second step involves inputting the feature matrix into a pre-trained growth stage classification model, which is a random forest classification model. The input is the 12×8 dimensional feature matrix, and the output is the probability value of the monitored object belonging to each pre-defined growth stage category. The growth stage category code corresponding to the highest probability value is taken as the growth stage category code output by the model. The construction and training of the random forest classification model can be obtained by those skilled in the art based on historical operating data and corresponding known growth stage labels, using cross-validation and grid search to determine hyperparameters such as the number of decision trees and maximum depth. This is a conventional technical method that can be configured according to historical data and the needs of the implementation scenario.

[0051] The third step is to trigger a growth stage change verification if the growth stage category code output by the model is inconsistent with the current code in the object profile identifier. This verification requires manual review and confirmation by more than 2 / 3 of the total number of management nodes in the blockchain network through digital signatures before the object profile update smart contract can be called to update the growth stage category code in the object profile identifier.

[0052] The fourth step involves writing the updated object profile identifier, the basis for the change including the digital signatures of each management node, and the review records into the blockchain's object profile notarization ledger, ensuring that the entire change process is traceable and tamper-proof. For example, for the monitored enterprise with the unified social credit code 9132****5678, after the data collection node completes data regularization in the 2025W16 cycle, it retrieves the original values ​​and month-on-month growth rates of four indicators—operating revenue, net asset size, R&D investment ratio, and personnel size—for 12 cycles from 2025W05 to 2025W16, forming a 12×8-dimensional feature matrix. After inputting this matrix into the growth stage classification model, the output growth stage category code remains 01 (early stage), consistent with the current object profile identifier, and does not trigger the change process. If the model output code is 02 (growth stage), then the object profile identifier needs to be reviewed and confirmed by more than 2 / 3 of the management nodes before the update is completed, and all change records are uploaded to the blockchain for notarization.

[0053] Furthermore, in one specific implementation of this embodiment, the acquisition node is configured with a front-end data access gateway, and the front-end data access gateway performs operations according to the following logic:

[0054] Multi-format compatibility access: Supports unified access of unstructured documents in PDF, Word, Excel, and scanned image formats, while also being compatible with data access via HTTP, MQTT, FTP, and other transmission protocols; Identity legitimacy verification: Verifies the digital signature attached to the object profile identifier using the public key of the monitored object pre-stored in the blockchain distributed ledger; if the signature verification passes, the reported data is allowed; if the signature verification fails, the reported data is directly intercepted, and an object identity forgery anomaly alarm is output, solving the technical problem of illegal terminals forging object profiles to report false data;

[0055] To further explain, this embodiment merges and deduplicates multiple batches of reported data from the same monitored object within the current collection period according to the time window corresponding to the first preset period, generating a single unstructured document to be processed. This solves the technical problems of time-series data disorder and duplicate collection caused by multiple terminals and multiple batches of reporting. For example, for a monitored enterprise in the early stage, the corresponding growth stage category code is 01, and the first preset period is set to weekly. The collection node obtains the Excel document and PDF version of the business summary uploaded by the enterprise terminal through the front-end data access gateway, which contain weekly operating data and R&D investment details. After verifying the digital signature attached to the object profile identifier uploaded by the enterprise through the pre-stored public key of the enterprise, the multiple documents uploaded by the enterprise in three batches within the current week are merged and deduplicated to generate a single unstructured document to be processed.

[0056] Based on the object profile identifier, a corresponding structured data table template is matched from a preset template library. The template includes field names, data types, units, value ranges, and field correlation benchmark values. Further, in this embodiment, the preset template library is hierarchically constructed according to growth stage categories. Each growth stage category code corresponds to a unique set of structured data table templates. The field correlation benchmark value within the template represents the basic contribution reference value of that field at the corresponding growth stage, forming a one-to-one mapping relationship with subsequent field correlation thresholds, ensuring logical consistency between template matching and subsequent field pruning. This is one specific implementation of this embodiment. The method involves setting up a pre-defined template library with subdivided industry tag dimensions. Each set of structured data table templates specific to a growth stage is further subdivided into sub-templates corresponding to different national economic industry classification codes. These sub-templates, based on general monitoring fields, add specific industry-specific monitoring fields and matching field correlation benchmark values. The template matching execution logic is as follows: the data collection node first matches the main template based on the growth stage category code in the object profile identifier, and then matches the corresponding industry sub-template based on the industry category code in the object profile identifier. This solves the technical problem that general templates cannot adapt to the monitoring needs of subdivided industries, improving the scenario adaptability and field matching accuracy of template matching. For example, for a startup company monitored with a growth stage category code of 01 and an industry category code of the manufacturing major category, the data collection node first matches the startup main template based on the growth stage category code 01, and then matches the high-end manufacturing industry sub-template based on the manufacturing major category code. This sub-template includes specific monitoring fields such as R&D expenses, number of patent applications, and number of core technical personnel, as well as corresponding field correlation benchmark values.

[0057] The semantic-rule hybrid parsing engine is invoked to extract key numerical fields from the unstructured document. The parsing engine sequentially performs the following steps: matching predefined field name variants based on regular expressions, identifying numerical values ​​and their contextual semantic tags based on lightweight named entity recognition, and outputting a queue for manual annotation when the matching confidence is lower than a first confidence threshold. Further, this embodiment employs a dual-track parsing architecture prioritizing rules and providing semantic fallback. The predefined field name variants cover various expressions of the same monitoring indicator, including official full names, abbreviations, English abbreviations, and industry slang, ensuring high field recognition coverage in the unstructured document. The lightweight named entity recognition uses a pre-trained, fine-tuned lightweight BERT model based on business data, accurately identifying the semantic, statistical period, and unit contextual information corresponding to the numerical values. The first confidence threshold is preset to 90%, determined by balancing the accuracy requirements of business parsing in this field with the cost of manual annotation. When the matching confidence of field recognition is lower than this threshold, [the process is repeated]. The corresponding document fragments are output to the queue for manual annotation to avoid data errors introduced by low-confidence recognition results. Further, in one specific implementation of this embodiment, the semantic-rule hybrid parsing engine is also configured with a document preprocessing module. Before performing regular expression matching and named entity recognition, preprocessing is performed according to the following logic: Format normalization: OCR error correction and noise reduction are performed on the content of scanned documents converted to text; layout parsing and content restoration are performed on documents with nested tables and multi-column layouts, converting the table content in unstructured documents into key-value pair formatted text fragments; Dynamic rule base adaptation: A custom rule extension interface is configured to support real-time updates of the regular expression rule base based on the newly added field descriptions. Updated rule base content must be verified by consensus nodes before taking effect; Confidence level determination: For field recognition results, rule matching confidence and semantic recognition confidence are output separately, and the lowest value of the two is taken as the final matching confidence, ensuring the rigor of confidence determination and solving the misjudgment problem caused by a single confidence level determination. For example, when the semantic-rule hybrid parsing engine parses the business reports uploaded by the monitored enterprises, it uses regular expressions to match variations of predefined field names such as R&D investment, R&D expenses, and R&D input. It uses a lightweight BERT model to identify the numerical value, indicator semantics, and statistical period corresponding to the current period's R&D investment amount of 2.3 million yuan in the document. If the final matching confidence of a certain field is 87%, which is lower than the first confidence threshold of 90%, the document fragment corresponding to that field is output to the queue for manual annotation.

[0058] The extracted key numerical fields are mapped to the structured data table template according to the field name to generate structured panel data, wherein unmatched template fields are filled with null value identifiers. It is further noted that the null value identifiers in this embodiment adopt preset standardized null value filler characters, which are different from the numerical value 0 and blank characters. In the subsequent normalization processing and fusion calculation stages, the system will automatically identify the null value identifier and perform weight reallocation of the corresponding dimension to avoid null values ​​causing unexpected interference to the calculation results of the comprehensive monitoring index, while ensuring the integrity of the table structure of the structured panel data. To further explain, one specific implementation of this embodiment is as follows: Before performing the field mapping operation, the acquisition node first performs data cleaning on the extracted key numerical fields. Based on the predefined units and value ranges in the structured data table template, the key numerical fields undergo unified unit conversion and outlier filtering, replacing outlier values ​​that exceed the value range with standardized null value identifiers. After the field mapping is completed, the acquisition node also performs a mandatory field integrity check on the generated structured panel data, checking whether there are null value identifiers in the preset mandatory fields in the template. If a mandatory field has a null value identifier, a field missing alarm is output; if the mandatory fields are complete, the structured panel data generation is completed, thereby ensuring the compliance and data quality of the structured panel data and avoiding distortion of subsequent monitoring results due to low-quality data. For example, the data collection node maps the extracted key numerical fields such as operating revenue, R&D expenses, and number of patent applications to the high-end manufacturing industry sub-template according to the field name. It fills the field of industry-university-research cooperation number that is not matched in the template with standardized null value identifiers, and replaces the abnormal value of total liabilities that exceeds the preset value range with standardized null value identifiers. After completing the field mapping, it performs integrity verification on the required fields such as operating revenue and total assets. After the verification passes, it generates the structured panel data of the enterprise for the current period.

[0059] A first hash operation is performed on the structured panel data to generate a first hash value bound to the current collection period. The structured panel data and the first hash value are then stored in the block body of the current block as key-value pairs. The key is a combination of the current collection period identifier and the identifier of the monitored object, and the value is the structured panel data and the first hash value. Further, in this embodiment, the first hash operation uses the SHA-256 irreversible cryptographic hash algorithm, which conforms to the blockchain distributed ledger verification specification. The operation is performed on all bytes of the structured panel data, and the generated first hash value is strongly bound to the timestamp and collection period identifier of the current collection period, ensuring that the hash values ​​of the same monitored object in different collection periods are unique and non-repeating. The key-value pair uses a fixed concatenation format of "unique ID of the monitored object + collection period identifier," ensuring that the storage primary key of each piece of structured panel data in the distributed ledger is globally unique, avoiding data storage conflicts, and facilitating subsequent data traceability and retrieval.

[0060] Furthermore, the first hash operation in this embodiment adopts the Merkle hash tree operation mode, and the specific execution logic and variable rules include:

[0061] Before performing a hash operation, it is necessary to confirm that the structured panel data has completed field mapping, data cleaning, and required field integrity verification, has a complete field name-value key-value pair structure, and has been bound with a unique monitored object identifier and collection period identifier. If the verification fails, the hash operation will be stopped and a data format abnormality alarm will be output.

[0062] The validated structured panel data is sequentially split into several consecutive data blocks according to a preset fixed size of 64KB. The remaining data that is less than 64KB at the end after splitting is retained as an independent data block according to the actual byte size, without zero padding, to avoid introducing redundant bytes that could cause hash value distortion.

[0063] For each data block that has been split, perform an irreversible cryptographic hash operation of SHA-256 that conforms to the blockchain distributed ledger verification specification. The input is the full byte stream of a single data block, and the output is the leaf node hash value of a fixed length of 256 bits. All leaf node hash values ​​are arranged in the order of data block splitting to form the leaf layer of the Merkle hash tree.

[0064] For the hash values ​​of nodes in the current layer, group them in pairs in order. Concatenate the hash values ​​of two adjacent nodes in each group in byte order. Perform SHA-256 hash operation on the concatenated byte stream again to generate the hash value of the parent node of the previous layer. If the total number of nodes in the current layer is odd, copy the hash value of the last node in the layer and concatenate it with its own bytes. Perform SHA-256 hash operation to generate the corresponding parent node hash value. Ensure that the total number of nodes in each layer is even. Repeat this merging operation until a unique root node hash value is generated, which is the Merkle root hash value.

[0065] The generated Merkle root hash value is concatenated with the current collection period identifier and the monitored object identifier in a fixed order. The concatenated byte stream is then subjected to another SHA-256 hash operation to generate the final first hash value. This first hash value is strongly bound to the current collection period and the monitored object, ensuring that the first hash value of the same monitored object in different collection periods and different monitored objects in the same collection period is globally unique and cannot be repeated.

[0066] The Merkle hash tree operation mode described above can support multi-threaded parallel hash operations on large-volume structured panel data, reducing the operation time by more than 70% compared to the single hash operation mode for full data. At the same time, it can support fast tampering location and verification of single-field data without having to re-perform hash operations on the full data.

[0067] Furthermore, the key-value pair storage of the block body in this embodiment is configured with an access control policy based on ciphertext policy attribute base encryption. The specific execution logic and judgment rules include:

[0068] The structured panel data stored in the block is encrypted using a preset CP-ABE encryption algorithm, and a predefined access control policy is bound during encryption. The access control policy uses node attributes as the core judgment dimension, and the node attributes include four core dimensions: node role code, permission level identifier, management scope of the monitored object, and effective access time window. For example, the key of the key-value pair adopts a fixed concatenation format of "the bound monitored object identifier is 9132******5678, and the collection period identifier is 2025W16", where the unique ID of the monitored object is a fixed-length 18-digit unified social credit code, and the collection period identifier is a fixed format of "year + W + week number", ensuring that the stored primary key is globally unique and has no hash collision risk. The value of the key-value pair is a fixed-format structure consisting of the encrypted structured panel data byte stream, the first hash value, the encryption algorithm identifier, the access control policy identifier, and the data version number.

[0069] When any node initiates a read request for this key-value pair, the system performs verification according to the following logic:

[0070] The first step is to obtain the attribute certificate of the node that initiated the request and verify the validity of the signature of the node's private key attached to the attribute certificate. If the signature verification fails, the access request is rejected directly, and an "access denied" warning is output.

[0071] The second step, if the signature verification passes, further parses the access control policy bound to the encrypted data, and verifies whether the node's attributes fully meet all the requirements of the access control policy. If the node attributes meet the access control policy, the structured panel data and the first hash value in the corresponding key-value pair are decrypted and returned. If the node attributes do not meet the access control policy, the access request is rejected, a permission mismatch alarm is output, and the node identifier, request time, and request block height of the illegal access request are completely recorded in the blockchain operation audit ledger, realizing full-link traceability of access behavior.

[0072] The above access control strategies enable fine-grained permission management of structured panel data, ensuring the security of access to on-chain stored data.

[0073] For example, for the monitored startup with the Unified Social Credit Code of 9132******5678, the data collection node performs the following processing on its structured panel data for the 16th week of 2025:

[0074] The structured panel data has been confirmed to have completed field mapping and data cleaning, containing complete key-value pair data of 6 core fields: operating revenue, R&D expenses, number of patent applications, R&D personnel ratio, total assets, and total liabilities. The bound monitored object identifier is 9132******5678, the collection period identifier is 2025W16, the integrity verification of the required fields has passed, and the Merkle hash tree operation has been started.

[0075] The full byte stream of the structured panel data is split into three complete 64KB data blocks and one 28KB tail data block, for a total of four data blocks.

[0076] Perform SHA-256 hash operation on each of the four data blocks, and generate four leaf node hash values ​​in the order of splitting, denoted as H1, H2, H3, and H4 respectively, which constitute the leaf layer of the Merkle hash tree;

[0077] Layer-by-layer hash merging: The four hash values ​​of the leaf layer are grouped into pairs. The first pair, H1 and H2 bytes, are concatenated and then subjected to SHA-256 operation to generate the parent node hash value H12. The second pair, H3 and H4 bytes, are concatenated and then subjected to SHA-256 operation to generate the parent node hash value H34. The H12 and H34 bytes are concatenated and then subjected to SHA-256 operation again to generate the unique Merkle root hash value H_root.

[0078] The Merkle root hash value H_root, the monitored object identifier 9132******5678, and the collection period identifier 2025W16 are concatenated in a fixed order. The concatenated byte stream is then subjected to SHA-256 operation to generate the final first hash value H_final, which is strongly bound to the 2025W16 collection period.

[0079] Using "9132******5678-2025W16" as the key, and a structure consisting of encrypted structured panel data, the first hash value H_final, the encryption algorithm identifier, the access control policy identifier, and the data version number as the value, it is associated and stored in the block body of the current block with a block height of 1257; the access control policy bound to the encrypted data is "node role code = post-investment management position and permission level identifier ≥ 2 and the management scope of the monitored object includes 9132******5678 and the access time is within the valid range of 2025";

[0080] When a post-investment management node with operational management authority initiates a read request, the system first verifies the signature validity of the node's attribute certificate, then verifies that its attributes fully meet the access control policy requirements, decrypts and returns the complete data in the key-value pair; when an ordinary node without corresponding management authority initiates a read request, the system verifies that its attributes do not meet the access control policy, directly rejects the access request, outputs an access mismatch alarm, and records the illegal access request in the blockchain operation audit ledger.

[0081] Based on the growth stage category code, the correlation threshold vector of each field under that growth stage is obtained from the field correlation threshold mapping table. The field correlation is pre-calculated using the information gain algorithm on historical panel data, representing the degree of contribution of the field to the comprehensive monitoring index. Further, in this embodiment, the field correlation threshold mapping table is pre-constructed through offline training and written into the blockchain configuration contract after consensus. Each growth stage category code corresponds to a set of correlation threshold vectors with dimensions consistent with the total number of fields. The information gain algorithm uses the numerical fluctuations of each field in the historical panel data as input features and the actual results of the comprehensive monitoring index for the corresponding period as output labels to calculate the information gain value of each field to the monitoring results. This value is the field correlation. The higher the field correlation value, the higher the degree of contribution of the field to the comprehensive monitoring index, thus providing a quantitative basis for field pruning.

[0082] Furthermore, one specific implementation of this embodiment involves configuring a fixed-period incremental update mechanism for the field correlation threshold mapping table. The specific execution logic is as follows: at each preset update interval, the data acquisition node calls a preset incremental training module to recalculate the field correlation of each field based on newly added historical panel data using an information gain algorithm, and incrementally updates the correlation threshold vector. The preset update interval and the proportion of consensus nodes required for the update to take effect can be configured by those skilled in the art according to actual business scenarios. For example, the update interval can be configured to 3 months to adapt to the business pattern of most industries disclosing operating data quarterly. Simultaneously, it can be required that the updated correlation threshold vector be agreed upon by more than 2 / 3 of the consensus nodes in the blockchain network before it can be written into the blockchain configuration contract to replace the original threshold vector. This configurable update mechanism effectively adapts to the field contribution deviation problem caused by changes in industry environment and business rules, ensuring the timeliness and accuracy of the field correlation threshold. For example, for a startup company with a growth stage category code of 01, the data collection node obtains the correlation threshold vector corresponding to the startup stage from the field correlation threshold mapping table. The field correlation of the number of patent applications is calculated to be 0.82 using the information gain algorithm, and the corresponding correlation threshold is 0.60. The field correlation of the proportion of R&D personnel is 0.75, and the corresponding correlation threshold is 0.55.

[0083] The system obtains the set of fields to be filled corresponding to the current collection period. This set is the union of all fields in the structured data table template. Specifically, in this embodiment, the set of fields to be filled is the complete set of all fields in the matched structured data table template, including basic information fields, core monitoring fields, and extended auxiliary fields. This covers all possible monitoring dimensions at this growth stage, ensuring the completeness and accuracy of the baseline set for field trimming and preventing the loss of core monitoring dimensions before trimming. Further, in one specific implementation of this embodiment, when obtaining the set of fields to be filled, the collection node performs a verification operation according to the following logic: First, it reads the version number of the currently matched structured data table template and compares it with the latest valid version number of the template stored in the blockchain configuration contract. If the current template version is lower than the latest valid version, it automatically retrieves the latest version template file and generates the set of fields to be filled based on the full fields of the latest template. Simultaneously, the collection node verifies the validity of the fields in the template, filtering out obsolete fields marked as disabled, ensuring the completeness and timeliness of the set of fields to be filled and avoiding field omissions or redundancy caused by template iteration. For example, for the matched high-end manufacturing industry startup sub-template, the collection node obtains a full set of fields including operating revenue, R&D expenses, number of patent applications, proportion of R&D personnel, and number of industry-university-research cooperation, as the set of fields to be filled in for the current collection period.

[0084] Each field in the set of fields to be filled is traversed, and its correlation degree is compared with the corresponding correlation degree threshold. Fields with correlation degrees lower than the threshold are filtered out, generating a dimensionality-reduced subset of collected fields. Furthermore, the traversal in this embodiment adopts a field-by-field serial comparison execution logic. For each field, only high-contribution fields with correlation degrees greater than or equal to the correlation degree threshold of the corresponding growth stage are retained, while low-information-entropy redundant fields with correlation degrees lower than the threshold are filtered out. This reduces the storage and transmission overhead of on-chain nodes from the data collection source, while ensuring that the retained field subset can fully support the accurate calculation of subsequent comprehensive monitoring indices. To further explain, one specific implementation of this embodiment is as follows: the fields in the set of fields to be filled have preset mandatory retention labels. For mandatory retention fields that must be filled due to regulatory or compliance requirements, regardless of whether their field relevance is lower than the corresponding threshold, no filtering operation is performed, and they are directly retained in the subset of collected fields. At the same time, after traversal and comparison, the collection node performs core field integrity verification on the generated subset of collected fields to check whether the preset core monitoring fields are completely retained. If a core field is missing, a field verification alarm is triggered; if the core field is complete, the subset of collected fields is generated. This reduces field redundancy while avoiding compliance risks and the problem of missing core monitoring dimensions. For example, the collection node traverses each field in the set of fields to be filled, retains fields with a field relevance greater than or equal to the corresponding threshold such as operating revenue, R&D expenses, number of patent applications, and R&D personnel ratio, filters out non-core auxiliary fields with a relevance lower than the threshold, and retains the field of total corporate liabilities with the mandatory retention label, generating a dimensionality-reduced subset of collected fields.

[0085] Furthermore, the generation process of the field subset in this embodiment is configured with a full-link traceable consistency verification mechanism to ensure that the cropped field subset is completely consistent with the corresponding fields of the original structured panel data, avoiding problems such as malicious tampering of fields, value replacement, and field omission during the cropping process, while providing a traceable cropping basis for subsequent full-link data verification. To further explain, one specific implementation of this embodiment is as follows: after generating the subset of collected fields, the collection node performs the following additional verification and evidence storage operations: First, a field pruning detail list is generated, which includes six core information categories: the set of fields to be filled in, the names of the fields to be retained, the names of the filtered fields, the correlation values ​​of each field, the corresponding correlation thresholds, and the reasons for filtering. Second, a SHA-256 hash operation is performed on the field pruning detail list to generate a pruning detail hash value. Third, the pruning detail hash value and the subset of collected fields are concatenated byte-wise, and then a second hash operation is performed to ensure that the second hash value simultaneously covers the integrity of both the subset of collected fields and the pruning rules. Fourth, the field pruning detail list and the pruning detail hash value are associated and stored in the block body of the current block, forming a one-to-one correspondence with the structured panel data, ensuring that the pruning process is traceable throughout the entire chain. For example, for the subset of fields collected in the 2025W16 period of the aforementioned monitored startup companies, the collection node generates a field pruning detail list, which clearly records all 12 fields in the set, retains 6 core fields, filters 6 low-relevance fields and their corresponding field relevance values, performs a hash operation on the list to generate a pruning detail hash value, concatenates it with the subset of collected fields and performs a second hash operation, and stores the pruning detail list and hash value in the block body with a block height of 1257, forming a binding association with the company's structured panel data.

[0086] A second hash operation is performed on the subset of collected fields to generate a second hash value, and the second hash value is written into the block header of the current block. At the same time, the first hash value is used as a forward hash pointer in the block header to point to the block body hash of the previous block, forming a chained hash verification structure. Furthermore, in this embodiment, the second hash operation uses the same SHA-256 irreversible cryptographic hash algorithm as the first hash operation, ensuring the uniformity of hash operation rules and the consistency of verification logic. The block header is the core storage area in the blockchain block with immutable characteristics. Writing the second hash value into the block header ensures that the digital fingerprint of the core collection field cannot be maliciously tampered with, providing a reliable comparison benchmark for data integrity verification in subsequent preprocessing stages. The forward hash pointer cryptographically binds the first hash value of the current block with the block body hash of the previous block, forming a chain-like verification structure between blocks. Tampering with the collection data in any block will cause the corresponding hash value to become invalid. The system can quickly identify abnormal data through this chain structure, providing underlying technical support for the whole-process data credibility verification and traceability. Furthermore, in one specific implementation of this embodiment, when writing... Before adding the forward hash pointer, the collecting node first performs block data synchronization verification with the consensus nodes in the blockchain network to confirm the final consensus block height and block body hash value of the previous block, avoiding incorrect forward hash pointer pointing due to block forks. At the same time, the second hash value written into the block header and the forward hash pointer are combined with the block height and collecting cycle identifier of the current block to generate a block header checksum, ensuring that the hash pointer and hash value in the block header cannot be tampered with separately, further strengthening the anti-tampering capability and data verification reliability of the chain hash verification structure. For example, the collecting node performs SHA-256 hash operation on the generated subset of collecting fields to generate a second hash value, writes the second hash value into the block header of the current block, and uses the first hash value of the current block as the forward hash pointer to point to the block body hash of the previous block with a block height of 1256, forming a chain hash verification structure that links the previous and next blocks.

[0087] Please see Figure 3 It should be further noted that the preprocessing node in this embodiment is configured as follows:

[0088] The system acquires the structured panel data output by the acquisition node and matches at least one corresponding external data source from a preset external data source configuration table based on the growth stage category code in the object profile identifier. The external data source includes at least one of the following: aggregated statistical data of reference object groups at the same growth stage, environmental sensor time-series data, and statistical characteristic values ​​of historical benchmark intervals. Further, the aggregated statistical data of reference object groups at the same growth stage refers to the average, median, standard deviation, and quantile of all reference objects that belong to the same "growth stage category code - industry category code" combination as the monitored object and are registered in the blockchain reference object registry, within a preset historical time window. Specific data sources can be selected and accessed by those skilled in the art from the corresponding industry association database or statistical public data platform according to monitoring needs. The environmental sensor time-series data refers to IoT sensors deployed at the monitored object's business premises or key nodes in the related industrial chain. The time-series data collected by the device network, including timestamped production equipment operating parameters, energy consumption data, and environmental indicators, are used to reflect the actual operational activity and production capacity of the monitored object, solving the problem of a single monitoring dimension caused by relying on a single self-reported financial data. The statistical characteristic value of the historical benchmark interval refers to the historical lower quartile, upper quartile, and interquartile range of the comprehensive monitoring index, which is calculated based on the comprehensive monitoring index generated by all reference objects in the same growth stage and industry as the monitored object in each collection period within a previously preset long period. This value is used to provide historical prior reference for subsequent dynamic threshold setting.

[0089] Furthermore, the preset external data source configuration table in this embodiment is constructed according to a two-dimensional combination dimension of growth stage category code and industry category code, and stored in key-value pair format. The primary key is a fixed concatenated string of "growth stage category code - industry category code", and the key value is the set of data source access configurations under this combination. Each access configuration includes seven core fields: unique data source identifier, interface address, data access protocol, data field mapping rules, data update frequency, asymmetric encryption access permission certificate based on the national cryptographic SM2 algorithm, and data validity time window. This ensures the matching accuracy and access security between the external data source and the monitored object. The external data source also includes at least one of the following: industrial and commercial change database, intellectual property disclosure database, industry policy database, and regional industry operation database, to achieve cross-verification of enterprise self-reported data and publicly authoritative data, and to solve the technical problem of lack of third-party verification of the authenticity of self-reported data.

[0090] Further explanation is provided: In one specific implementation of this embodiment, the preprocessing node is configured with a data source trustworthiness verification module. After matching the corresponding external data source, the verification is performed according to the following fixed logic: First, the digital signature attached to the acquired external data source data packet is verified using the pre-stored official public key of the data source; Second, if the signature verification passes, the timestamp of the data packet is further verified to see if it is within the preset valid time window corresponding to the current collection period. The span of the valid time window can be configured differently by those skilled in the art based on the data update frequency and timeliness requirements of each data source; Third, if the timestamp verification passes, the data source data is determined to be valid and allowed to enter the subsequent processing flow; If any of the above steps fails, the data source data packet is directly discarded, a corresponding level of data source anomaly alarm is output, and the complete field information of the anomaly access record is written into the blockchain operation audit ledger to ensure that the data source access process is traceable.

[0091] For example, for a startup monitored with a unified social credit code of 9132****5678, a growth stage category code of 01, and an industry category code of C34 (high-end manufacturing), the preprocessing node uses "01-C34" as the primary key and matches three external data sources from the external data source configuration table: the corresponding patent publication database, the manufacturing SME prosperity database, and the regional high-end manufacturing industrial park policy database. The patent publication database provides alternative innovation output indicators from the environmental sensor time-series data; the manufacturing SME prosperity database provides aggregated statistical data for the reference object group at the same growth stage; and the regional high-end manufacturing industrial park policy database provides industry policy data related to the business environment. After the preprocessing node verifies the data packet signature using the official public keys of each data source and confirms that the data packet timestamp is within the valid time window corresponding to the 2025W16 collection cycle, it obtains the company's current invention patent application publication data, aggregated statistical data on R&D investment of companies in the same industry at the same growth stage, and current high-end manufacturing industry special support policy data, as supplementary dimension data for subsequent fusion calculations.

[0092] Performing a time-series alignment operation on the structured panel data and the external data source specifically includes: using the timestamp of the first preset period configured by the acquisition node as the alignment benchmark, mapping the timestamp of the external data source to each acquisition moment of the first preset period through linear interpolation or nearest neighbor matching, generating an aligned multidimensional data matrix with the acquisition period timestamp as the primary key, where the row index is the acquisition period identifier and the column index is the union of the monitoring dimension and the external data dimension; further, it should be noted that the selection rules for linear interpolation and nearest neighbor matching in this embodiment are pre-configured in the time-series alignment module, and the triggering logic is as follows: For continuous numerical data with a sampling frequency of twice or more than the first preset period, linear interpolation is used for time-series mapping. For discrete enumerated data and categorical data with a sampling frequency of less than half the first preset period, nearest neighbor matching is used for time-series mapping to avoid time-series data distortion caused by mismatch between interpolation method and data type. Each column dimension of the aligned multidimensional data matrix is ​​accompanied by a unique dimension identifier, which corresponds one-to-one with the unique field identifier in the structured data table template and the unique field identifier in the external data source, ensuring the traceability and verifiability of data in each dimension of the matrix. To further explain, one specific implementation of this embodiment is as follows: after the time-series alignment operation is completed, the preprocessing node performs integrity verification on the aligned multidimensional data matrix according to the following logic: First, calculate the effective data ratio of each column dimension in the matrix, that is, the ratio of the amount of non-empty data to the total amount of data in that column; Second, for dimensions with an effective data ratio greater than a preset missing rate threshold, use the moving average of the time-series data from the previous four consecutive collection periods of the same dimension to fill in missing values; Third, for dimensions with an effective data ratio less than or equal to the preset missing rate threshold, mark them as invalid dimensions and remove them from the matrix, while outputting a dimension data missing alarm; The preset missing rate threshold is preset to 30%, which is determined based on a balance between the statistical representativeness requirements of time-series data and the accuracy requirements of subsequent fusion calculations. For example, for the monitored enterprises with the aforementioned 2025W16 collection cycle and the first preset cycle being weekly, the preprocessing node uses April 15, 2025 as the base timestamp for the weekly collection cycle; for patent application data updated daily, since the sampling frequency is more than twice that of the weekly cycle, a linear interpolation method is used to map the daily data to the weekly base time; for manufacturing SME business climate data updated monthly, since the sampling frequency is less than half of the weekly cycle, a nearest neighbor matching method is used to map the monthly data to the weekly base time; finally, a 9-column multidimensional data matrix is ​​generated with 2025W16 as the row index and 6 self-reported monitoring dimensions and 3 external data dimensions as column indexes; for the R&D investment dimension, which has 85% of the effective data in the matrix, missing values ​​are filled using the moving average of the previous 4 weeks; for non-core dimensions with 22% of the effective data and below the 30% threshold, they are marked as invalid dimensions and removed.

[0093] Furthermore, the multidimensional data matrix after time-series alignment in this embodiment is configured with a cross-verification mechanism for self-reported data and external authoritative data sources. This mechanism can quantify and generate a credibility score for the self-reported data of the monitored object, identifying the problem of falsified or concealed self-reported data from the source, and solving the technical deficiency of existing solutions that only verify data integrity but not data authenticity. The credibility score will be synchronously input into the subsequent fusion calculation stage, and the dimension weights corresponding to low-credibility data will be adaptively adjusted to avoid the distortion of the comprehensive monitoring index caused by false data. Further, one specific implementation of this embodiment is as follows: after completing time-series alignment, the preprocessing node executes the following cross-verification and scoring process: First, for the overlapping dimensions in the multidimensional data matrix where both self-reported data and external authoritative data exist, calculate the relative deviation rate between the self-reported values ​​and the external data source values. The relative deviation rate is calculated as: |self-reported value - external data source value| / MAX(self-reported value, external data source value) × 100%. Second, for each overlapping dimension, calculate the dimension credibility score based on the relative deviation rate. A deviation rate ≤ 5% earns 100 points, and 5% < deviation rate earns 100 points. The first step is to calculate the arithmetic mean of the credibility scores of all overlapping dimensions, which is used as the overall data credibility score for the monitored object in the current collection period. The score range is 0-100. The second step is to calculate the overall data credibility score of the monitored object in the current collection period. If the overall credibility score is lower than the preset qualified threshold of 60 points, a data authenticity anomaly alarm is triggered, the current preprocessing process is stopped, and the details of the dimensions with excessive deviation rate and the credibility score are written into the blockchain abnormal event storage ledger. If the score is ≥60 points, the credibility score is synchronously output to the fusion computing node for subsequent weight adaptive adjustment. For example, for the multidimensional data matrix of the aforementioned monitored enterprises in the 2025W16 period, the preprocessing node performs cross-verification on the two overlapping dimensions of patent application quantity and R&D investment. The deviation rate between the self-reported value of patent application quantity and the published data in the patent publication database is 0, which scores 100 points; the deviation rate between the self-reported value of R&D investment and the industry statistical data is 8%, which scores 60 points; the overall credibility score is calculated to be 80 points, which is higher than the qualified threshold of 60 points. The score is then output to the fusion computing node for weight adaptation in subsequent fusion computing.

[0094] Integrity verification is performed on the structured panel data by calling the second hash value stored in the block header. Specifically, this includes: re-performing the first hash operation on the currently acquired structured panel data to generate a hash value to be verified; reading the second hash value from the block header of the current block; and comparing whether the hash value to be verified is consistent with the second hash value. If they are consistent, the integrity verification is deemed to have passed. If they are inconsistent, a data integrity anomaly alarm is triggered, the current preprocessing process is terminated, and a verification failure record containing the block identifier and the collection period identifier is output to the management terminal. Further, in this embodiment, the first hash operation adopts a Merkle hash tree operation mode completely consistent with the collection node. The data block division rules, hash algorithm, concatenation rules, and execution logic of the collection node are 100% matched, ensuring the uniformity of the hash operation rules and resolving the verification misjudgment problem caused by inconsistent hash operation rules between preceding and subsequent nodes. The verification failure record includes the monitored object identifier, collection period identifier, block height, hash value to be verified, the second hash value stored in the block header, verification failure timestamp, and full information of the exception type code, ensuring that the exception record is completely traceable and tamper-proof. To further explain, one specific implementation of this embodiment is as follows: when the hash value to be verified is inconsistent with the second hash value, the preprocessing node immediately initiates a single-field tampering location process. The specific execution logic is as follows: First, according to the 64KB fixed block rule consistent with the collection node, the current structured panel data is divided into blocks, and the leaf node hash value of each data block is recalculated; Second, the original leaf node hash value sequence generated by the collection node is retrieved from the blockchain block body; Third, the leaf node hash values ​​are compared one by one according to the block order, the corresponding data block with inconsistent hash values ​​is located, and the field name, original reported value, and currently obtained value corresponding to the data block are parsed, and the above information is added to the verification failure record; Fourth, the complete verification failure record is synchronously written into the blockchain's abnormal event storage ledger, and an alarm of the corresponding level is triggered according to the abnormality type. For example, for the structured panel data of the monitored enterprises in the aforementioned 2025W16 collection cycle, the preprocessing node re-executes the Merkle hash tree operation to generate a hash value to be verified according to the same 64KB block division rule and SHA-256 hash algorithm as the collection node. The hash value is inconsistent with the second hash value stored in the block header at block height 1257. Then, the tampering location process is initiated. By comparing the hash values ​​of the leaf nodes block by block, the tampering is located. The hash value of the operating revenue field corresponding to the second data block is inconsistent. The original reported value is 523,000 yuan, and the current value is 1,523,000 yuan. The tampering information is added to the verification failure record, triggering a first-level data tampering alarm, stopping the current preprocessing process, and writing the complete verification failure record into the blockchain abnormal event storage ledger.

[0095] After successful verification, the original values ​​of each monitoring dimension are normalized according to preset unit conversion rules. These unit conversion rules are pre-stored in the structured data table template at the field level, including conversion type identifiers and conversion parameters. The normalization process uses Min-Max normalization to map the original values ​​of each monitoring dimension to the [0, 1] interval, generating a normalized feature value sequence. Furthermore, the unit conversion rules in this embodiment are divided into two categories: dimension unification conversion and numerical range conversion. Dimension unification conversion is used to convert numerical values ​​of the same dimension from different units to preset standard units. The conversion parameters include conversion... The conversion factor and offset are used to transform values ​​of different magnitudes into a unified magnitude that can be compared horizontally, ensuring that values ​​of different dimensions have a basis for fusion calculation; the maximum and minimum value parameters of the Min-Max normalization method are taken from the 1% and 99th percentiles of the historical full data of the first three complete natural years under the growth stage category and industry category of the monitored object, so as to eliminate the influence of extreme outliers on the normalization boundary and avoid the signal dilution problem caused by excessive concentration of feature value distribution; the maximum and minimum value parameters are updated incrementally in sync with the field correlation threshold vector, with an update cycle of 3 months. To further explain, one specific implementation of this embodiment is as follows: before performing normalization, the preprocessing node first performs a preprocessing operation. The specific logic is as follows: First, identify the standardized null value identifiers in the structured panel data. For fields filled with standardized null value identifiers, generate a preset 0xFF null value feature marker at the corresponding position in the normalized feature value sequence. This feature marker does not participate in the Min-Max normalization operation. Second, use the box plot method to perform outlier filtering on the original values ​​of each dimension. Based on the lower quartile and upper quartile of the historical data of the same growth stage and industry in this dimension, values ​​that exceed the range of "lower quartile - 1.5 times the interquartile range" and "upper quartile + 1.5 times the interquartile range" are judged as outliers and replaced with standardized null value identifiers to avoid distortion of the normalization results caused by outliers. For example, regarding the R&D investment field of the aforementioned monitored enterprises in the early-stage high-end manufacturing industry, the preprocessing node first converts the original value of 2.3 million yuan (in ten thousand yuan) into a standard unit of 2,300,000 yuan (in yuan) according to the unit conversion rules; the value is verified to be within a reasonable range and without outliers using a box plot method; based on the 1st quantile of 120,000 yuan and the 99th quantile of 5,000,000 yuan of the historical R&D investment data of the early-stage high-end manufacturing industry, a Min-Max normalization operation is performed, and the normalized feature value is calculated to be 0.449, which is mapped to the interval [0, 1]; for the industry-university-research cooperation frequency field filled with standardized null value identifiers, a 0xFF null value feature marker is generated at the corresponding position in the normalized feature value sequence.

[0096] Based on the temporal context identifier corresponding to the current acquisition period, a preset weight allocation matrix is ​​retrieved; wherein: the temporal context identifier is generated by combining the growth stage identifier and the operating environment stage identifier in an enumerated value concatenation manner, the growth stage identifier is obtained from the object profile identifier, and the operating environment stage identifier is obtained in real time by a preset environment stage classifier based on the external environment parameters of the current acquisition period; the weight allocation matrix uses the temporal context identifier as the row index and the monitoring dimension identifier as the column index, and records the dynamic weight coefficients of each monitoring dimension under different temporal context combinations; the dynamic weight coefficients are obtained by iteratively training historical panel data through a pre-constructed temporal sensitivity analysis model. Furthermore, the time-series sensitivity analysis model employs a long short-term memory network based on an attention mechanism. The construction and training process of this network is as follows: First, a deep neural network is constructed, consisting of an input layer, a double-stacked LSTM layer, a self-attention mechanism layer, and a fully connected output layer. The input layer receives a normalized feature value sequence defined as a matrix of dimension T×N, where T represents the number of acquisition cycles within a preset backtracking time window, and N represents the total number of monitoring dimensions. The number of hidden units in each layer of the double-stacked LSTM layer is set to 64 or 128 to capture the temporal dependencies between multiple monitoring dimensions. The self-attention mechanism layer calculates attention weights on the output of the LSTM at each time step to highlight the differences in the contribution of different acquisition cycles to the current comprehensive monitoring index. The fully connected output layer finally outputs the probability distribution of the weight coefficients for each monitoring dimension, and the sum of all weight coefficients is 1. During training, historical normalized feature value sequences are used as input features, and a comprehensive monitoring index verified by experts for the corresponding period is used as a supervision signal. Mean squared error is used as the loss function, and the Adam optimizer iteratively updates the network parameters using a backpropagation algorithm. Hyperparameters involved in network training, such as batch size, learning rate, backtracking time window T, and number of hidden units, can be configured and optimized by those skilled in the art based on the scale of historical panel data and computing power conditions through grid search and cross-validation. Iterative training continues until the loss function converges to obtain the trained model. The trained weight coefficient matrix is ​​then written into the blockchain's weight configuration contract after consensus is reached, along with a version number and the effective block height.

[0097] Furthermore, in this embodiment, the operating environment stage identifier adopts a preset enumeration value encoding rule, divided into five categories: policy easing period, industry upswing period, industry stable period, industry downturn period, and policy tightening period. Each category corresponds to a unique, non-repeatable numerical code from 01 to 05, ensuring the global uniqueness of the temporal context identifier. The preset environment stage classifier uses a pre-trained random forest classification model. The model's construction and training process involves using historical monthly collection periods as sample units, extracting the input features for each sample. These input features include the collected corresponding industry monthly Purchasing Managers' Index (PMI) value, the sentiment analysis score calculated using a preset NLP sentiment analysis dictionary based on the corresponding industry policy text released within that period, and the national SME financing... The environmental index comprises three standardized numerical features. A training dataset is constructed using operational environment stage identifiers retrospectively calibrated by economic or industry experts based on macroeconomic data and industry prosperity reports for the current period. Based on this training dataset, a random forest model is trained using the Gini coefficient as the feature selection criterion. Hyperparameters involved in the training process, such as the number of decision trees, maximum depth, and minimum number of sample splits, can be configured by those skilled in the art through cross-validation and grid search to obtain the model with optimal classification performance. The trained random forest classification model is deployed in the preprocessing node for real-time inference of external environmental parameters for the new collection period, outputting the corresponding operational environment stage identifier to achieve real-time classification of the operational environment.

[0098] In the weight allocation matrix, within the same row corresponding to the same temporal context identifier, the sum of all dynamic weight coefficients is strictly equal to 1, thereby ensuring the logical consistency of the weighted fusion calculation. Furthermore, in one specific implementation of this embodiment, when the preprocessing node retrieves the weight allocation matrix, it performs a double validity check according to the following logic:

[0099] The first step is version validity verification, which involves reading the latest version of the weight allocation matrix from the blockchain weight configuration contract, where the effective block height is less than or equal to the current block height, and automatically filtering out historical version matrices that have not yet reached their effective time or have been marked as expired.

[0100] The second step is consensus validity verification. First, the multi-signatures of the consensus nodes attached to the weight allocation matrix are extracted. The authenticity and validity of each signature are cryptographically verified one by one to confirm that it was indeed signed by the corresponding authorized consensus node using its private key and that the content has not been tampered with. Then, the number of distinct consensus nodes corresponding to all valid signatures that have passed verification is counted, and the proportion of this number to the total number of authorized consensus nodes in the entire network is calculated. Only when the calculated proportion reaches or exceeds the preset threshold of the blockchain network can the weight allocation matrix be determined to have been recognized by the legally required number of consensus nodes, be regarded as a trustworthy and valid matrix, and be officially retrieved locally for subsequent fusion calculations. The preset threshold in this embodiment can be flexibly configured by those skilled in the art according to the actual security level of the blockchain network. A typical configuration is more than two-thirds. If either of the above two verification steps fails, the system immediately stops the current retrieval process and outputs an invalid weight matrix alarm. At the same time, it automatically backtracks to the previous valid version of the weight allocation matrix that has passed all dual verifications to ensure the continuity and reliability of the fusion calculation process.

[0101] In one specific implementation of this embodiment, the consensus node refers to a core participant node deployed in the blockchain network and authorized through a configuration file or on-chain governance contract during system initialization. These nodes are assigned specific governance weights and decision-making authority within the network, and their core responsibility is to perform distributed consensus verification on critical configuration changes that affect the overall operation of the system.

[0102] For example, for the aforementioned monitored enterprises, the preprocessing node obtains the growth stage identifier as 01 from the object profile identifier. It then inputs the current high-end manufacturing industry PMI value, industrial policy sentiment analysis score, and financing environment index into the random forest classification model via an environment stage classifier. The model determines the operating environment stage identifier as 02 (industry upturn period), and combines them to generate time-series context identifiers 01-02. The latest version V1.2 weight allocation matrix with an effective block height less than 1257 is read from the blockchain weight configuration contract. After verifying that the number of consensus node signatures meets the preset ratio requirement, the row data corresponding to time-series context identifiers 01-02 in the matrix is ​​retrieved to obtain the dynamic weight coefficients for each monitoring dimension. Specifically, the R&D investment dimension is 0.28, the patent application dimension is 0.25, the operating revenue dimension is 0.22, the asset-liability dimension is 0.12, the R&D personnel ratio dimension is 0.08, and the policy adaptation dimension is 0.05. The sum of all weight coefficients is 1.

[0103] At the end of each acquisition cycle, the preprocessing node associates the normalized feature value sequence, the time-series context identifier, and the version number of the current weight allocation matrix with the data and outputs them to the fusion computing node. Further, in this embodiment, all data output by the preprocessing node uses "unique ID of the monitored object - acquisition cycle identifier" as the global association primary key to ensure a strong binding relationship between the normalized feature value sequence, the time-series context identifier, and the version number of the weight allocation matrix, avoiding mismatch problems during multi-object, multi-cycle data transmission. The output data is encoded using a fixed TLV (type-length-value) format to ensure that the fusion computing node can accurately parse each segment of data, resolving the parsing compatibility issue of cross-node data transmission. To further explain, one specific implementation of this embodiment is as follows: Before outputting data, the preprocessing node performs pre-transmission processing according to the following logic: First, it performs a SHA-256 hash operation on the full TLV format data output to generate a transmission verification hash value; Second, it encapsulates the transmission verification hash value and the output data together into a transmission data packet and sends it to the fusion computing node; Third, it writes the complete record of this data transmission, including the sending node identifier, receiving node identifier, global association primary key, transmission timestamp, and transmission verification hash value, into the node interaction audit ledger of the blockchain; Fourth, if no receipt confirmation is received from the fusion computing node within the preset 300ms timeout period, a retransmission mechanism is triggered, with a maximum of 3 retransmissions. If the number of retransmissions is exceeded, an alarm for abnormal communication of the output node is triggered. For example, for the monitored enterprises in the aforementioned 2025W16 collection cycle, the preprocessing node uses "9132****5678-2025W16" as the global association primary key, and associates and binds the normalized feature value sequence, time series context identifiers 01-02, and weight allocation matrix version number V1.2. After encoding it into TLV format, it performs SHA-256 hash operation to generate a transmission verification hash value, encapsulates it into a data packet, and sends it to the fusion computing node. After receiving the receipt confirmation acknowledgment from the fusion computing node, it writes the full record of this transmission into the blockchain node interaction audit ledger, completing this data output process.

[0104] Please see Figure 4 It should be further noted that the fusion computing node in this embodiment is configured as follows:

[0105] The following data is obtained from the output of the preprocessing node: the normalized feature value sequence for the same monitored object, the corresponding time-series context identifier, and the corresponding weight allocation matrix version number. The fusion computing node associates data through a combination key of the monitored object identifier and the acquisition period identifier to ensure that the data of the same monitored object is correctly assigned in different acquisition periods. Further, in this embodiment, the combination key adopts a fixed concatenation format of "unique ID of monitored object - acquisition period identifier" that is completely consistent with the output data of the preprocessing node, ensuring the uniqueness and consistency of cross-node data association and solving the technical problems of data mismatch and time-series disorder caused by inconsistent primary key formats during multi-node data transmission. The fusion computing node is equipped with a data access verification module, which can perform pre-verification of the integrity and consistency of received data to prevent invalid data from entering the subsequent fusion computing process. To further explain, one specific implementation of this embodiment is as follows: After receiving the data packet output by the preprocessing node, the fusion computing node performs pre-verification and data association according to the following logic: First, perform hash verification on the received data packet, compare the recalculated transmission verification hash value with the hash value attached to the data packet. If the comparison is inconsistent, trigger a data transmission anomaly alarm, discard the data packet, and send a retransmission request to the preprocessing node; Second, if the comparison is consistent, parse the data packet and extract the global association primary key, normalized feature value sequence, time-series context identifier, and weight allocation matrix version number; Third, using the global association primary key as an index, associate and bind the data of the current collection period with the existing data of the monitored object in the historical collection periods, and establish a time-series data linked list sorted by the collection period timestamp to ensure that the data of the same monitored object in different collection periods are correctly assigned in chronological order. For example, for the monitored enterprise with the unified social credit code 9132******5678, after the fusion computing node receives the data packet output by the preprocessing node, it first completes the transmission hash verification, and parses it to obtain the global association primary key "9132******5678-2025W16", the normalized feature value sequence, the time series context identifier 01-02, and the weight allocation matrix version number V1.2. Using this primary key as an index, the data of the 2025W16 period is associated and bound with the historical data of the enterprise from the 2025W12 to the 2025W15 period, and a time series data linked list sorted by weekly time is established to ensure that the data belongs correctly.

[0106] Based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix, a weighted fusion is performed on the normalized feature values ​​of each monitoring dimension. Specifically, a fusion method of weighted summation followed by arithmetic mean is adopted, which requires that the sum of the dynamic weight coefficients of all monitoring dimensions under the same time-series context identifier equals one. Furthermore, the weighted fusion process in this embodiment is equipped with null value feature adaptive processing logic, which can identify and adapt null value feature markers in the normalized feature value sequence, avoiding distortion of the fusion calculation results caused by null dimensions. Simultaneously, a weight validity verification module is configured to perform compliance verification on the retrieved dynamic weight coefficients, ensuring that the weight allocation conforms to the mathematical logic requirements of the fusion calculation. To further explain, one specific implementation of this embodiment is as follows: before performing weighted fusion, the fusion computing node first performs dual verification and preprocessing: First, weight legality verification: retrieve the dynamic weight coefficients of the corresponding version number and corresponding time context identifier in the blockchain weight configuration contract, and verify whether the sum of all weight coefficients is strictly equal to 1. If the verification fails, a weight anomaly alarm is triggered, and the weight coefficients of the previous valid version are called; Second, null value feature preprocessing: identify the 0xFF null value feature marker in the normalized feature value sequence, and for the dimension marked as null, redistribute its corresponding dynamic weight coefficients proportionally to the non-null value dimensions in the same sequence to ensure that the sum of the weight coefficients of the non-null value dimensions after redistribution is still strictly equal to 1. For example, for the normalized feature value sequence of the monitored enterprise in the 2025W16 period, the fusion computing node first verifies that the sum of the dynamic weight coefficients corresponding to the time context identifiers 01-02 is 1. After the verification is passed, the industry-university-research cooperation dimension is identified as a null feature marker of 0xFF. The 0.05 weight coefficient corresponding to this dimension is proportionally allocated to the other 5 non-null dimensions. After the reallocation, the sum of the weight coefficients of each non-null dimension is still 1, providing a compliant computing basis for subsequent weighted fusion.

[0107] For the current data collection period, the normalized feature value of each monitoring dimension is multiplied by its corresponding dynamic weight coefficient to obtain the weighted contribution value of each monitoring dimension. Then, the weighted contribution values ​​of all monitoring dimensions are summed to obtain the comprehensive monitoring index for this collection period. This index is a dimensionless value between zero and one. Furthermore, the comprehensive monitoring index in this embodiment is equipped with boundary verification and correction logic to verify the compliance of the calculation results, ensuring that the final output index value strictly falls within the [0, 1] range, thus resolving the issue of index out-of-bounds errors caused by extreme values. Simultaneously, the entire calculation process of the comprehensive monitoring index is recorded in the local node's calculation log, which includes a hash value of the calculation process, ensuring that the calculation process is traceable and reproducible. To further explain, one specific implementation of this embodiment is as follows: the fusion computing node performs the comprehensive monitoring index calculation according to fixed logic: First, in dimensional order, the normalized feature value of each non-null dimension is multiplied by the corresponding dynamic weight coefficient after reallocation to generate the weighted contribution value of each dimension; Second, the weighted contribution values ​​of all dimensions are summed to obtain the initial value of the comprehensive monitoring index; Third, boundary verification is performed on the initial value. If the initial value is less than 0, it is corrected to 0; if the initial value is greater than 1, it is corrected to 1, and finally, the final value of the comprehensive monitoring index in the interval [0, 1] is generated; Fourth, the full parameters, intermediate values, and final values ​​of the calculation process are hashed to generate the calculation process verification hash value, which is bound and stored with the comprehensive monitoring index. For example, for the data of the monitored enterprise in the 2025W16 period, the fusion computing node multiplies the normalized feature value of R&D investment dimension 0.449 with the corresponding weight 0.29 to obtain a weighted contribution value of 0.1302. After calculating the weighted contribution values ​​of the other 5 dimensions in turn, the values ​​are summed to obtain the initial value of the comprehensive monitoring index of 0.612. After boundary verification, it is confirmed that the index is within the range of [0, 1]. Finally, the comprehensive monitoring index for this period is 0.612. At the same time, the calculation process verification hash value is generated and stored in conjunction with the comprehensive monitoring index.

[0108] The comprehensive monitoring index from multiple consecutive collection periods is arranged chronologically to generate time-series comprehensive monitoring index data. The number of collection periods involved in the arrangement is determined by a preset sliding window length, denoted as W. The specific value of W can be configured by those skilled in the art based on the data update frequency of the monitored object's growth stage and the sensitivity of anomaly detection to historical trends; for example, it can be configured to 5 or 7 collection periods. Furthermore, in this embodiment, the sliding window adopts a fixed-step unidirectional sliding mode, with a fixed step size of one collection period, synchronized with the collection interval corresponding to the first preset period, ensuring the continuity and comparability of the time-series data. Simultaneously, a historical data reliability verification logic is provided, which performs hash traceability verification on the comprehensive monitoring index of each historical period to be included in the sliding window, preventing tampered historical data from entering the trend deviation detection process.

[0109] Further explanation is provided below. In one specific implementation of this embodiment, the fusion computing node generates comprehensive monitoring index time-series data according to the following logic: First, read the preset sliding window length W, where W is 7 in this embodiment, and the sliding step is 1 collection cycle; Second, using the current collection cycle as the last time position of the sliding window, trace back to obtain the comprehensive monitoring index of the monitored object for (W-1) consecutive historical collection cycles, i.e., 6 historical cycle indices; Third, for the comprehensive monitoring index of each historical cycle, retrieve the calculation process verification hash value stored in the corresponding block for integrity verification. If the verification of a certain historical cycle fails, it is determined that the comprehensive monitoring index of that cycle has been tampered with. The data repair strategy used here can be configured according to the system fault tolerance requirements, such as directly removing the historical cycle data and replenishing an earlier cycle, or using the comprehensive monitoring index of the two adjacent cycles that passed verification for linear interpolation replacement; Fourth, arrange the (W-1) historical cycle indices that passed verification or were repaired and the comprehensive monitoring index of the current collection cycle in ascending order according to the time sequence of the collection cycles to generate comprehensive monitoring index time-series data with a window length of W. For example, for the aforementioned monitored enterprise in the 2025W16 period, the fusion computing node sets the sliding window length W=7, and traces back to obtain the comprehensive monitoring index for 6 periods from 2025W10 to 2025W15. After the hash verification of the index for each period passes, it is arranged in ascending order of time with the comprehensive monitoring index of the 2025W16 period, generating the time series data of the comprehensive monitoring index of 0.581, 0.593, 0.605, 0.598, 0.602, 0.608, and 0.612. It should be further explained that, in the specific application scenario of monitoring the post-investment operation and growth status of high-end manufacturing enterprises in the early stage of this embodiment, 2025W16 specifically refers to the 16th week of 2025, that is, the weekly monitoring period from April 13, 2025 to April 19, 2025. This is the unique time identifier for the system to execute the complete post-investment monitoring process. Within this period, the system completes the entire closed-loop operation of collecting and uploading the enterprise's weekly operating data, R&D investment data, and patent data to the blockchain, performing structured processing, hash storage, data integrity verification, normalization processing, comprehensive monitoring index calculation, trend deviation detection, and uploading and storing the monitoring results to the blockchain.

[0110] The time series data of the comprehensive monitoring index is input into a preset trend deviation detection model. The trend deviation detection model first performs a baseline threshold interval calculation. Further, the trend deviation detection model in this embodiment is an unsupervised anomaly detection model based on the statistical interquartile range method. Its construction process does not require pre-labeling of training samples and can directly adapt to the anomaly identification needs of monitored objects at different growth stages and in different industries. The core construction steps of this model include: First, using the distribution of the comprehensive monitoring index of a reference object group at the same growth stage and industry as the monitored object at each time position within the sliding window as a benchmark; second, calculating the lower quartile Q1 and upper quartile Q3 at each time position, and calculating the interquartile range IQR = Q3 - Q1; finally, based on Q1, Q3, and a preset tolerance boundary coefficient k, defining the baseline threshold interval corresponding to the current time position as [Q1 - k]. IQR, Q3 + k [IQR]. The tolerance boundary coefficient k is an adjustable parameter used to control the width of the normal fluctuation range. Increasing the value of k widens the threshold range, reduces anomaly detection sensitivity, and decreases the false alarm rate; decreasing the value of k narrows the threshold range, increases sensitivity, and decreases the false negative rate. The specific value of k can be configured differently by those skilled in the art based on risk management preferences for different industries and growth stages, as well as tolerance for abnormal fluctuations. A typical configuration is to set k to 1.5.

[0111] Furthermore, the model includes an input data validity check logic before execution to ensure that the length and numerical range of the input time series data meet the model's input requirements. In one specific implementation of this embodiment, after the fusion computing node inputs the comprehensive monitoring index time series data into the trend deviation detection model, the model first performs a pre-verification of the input data: First, it checks whether the number of data points in the input time series data is consistent with the preset sliding window length W. If inconsistent, an input data anomaly alarm is triggered, and model execution is suspended. Second, it checks whether each comprehensive monitoring index value in the time series data is within the [0, 1] interval. If there are out-of-bounds values, a data anomaly alarm is triggered, and model execution is suspended. Third, after all pre-verifications pass, the model starts the baseline threshold interval calculation process, using reference object group data from the same growth stage and industry as the calculation baseline, and generates a dynamic baseline threshold interval adapted to the current scenario using the aforementioned interquartile range method. For example, for the aforementioned generated comprehensive monitoring index time series data with a window length W of 7, the trend deviation detection model first verifies that the data length is 7 and all values ​​are within the [0, 1] interval. After passing the verification, the baseline threshold interval calculation process is started.

[0112] Based on the growth stage category code of the monitored object, all reference objects belonging to the same growth stage category are queried from the reference object registry stored on the blockchain. After access qualification verification, a list of valid reference object identifiers is generated. The reference object registry is written to the blockchain during system initialization and updated through a consensus mechanism when a new reference object is added. Further, in this embodiment, the reference object registry adopts a two-dimensional hierarchical storage structure of "growth stage category code - industry category code". In addition to the growth stage category, the industry category of the reference object is further subdivided to ensure that the industry attributes and growth stage attributes of the reference object group and the monitored object are completely matched, solving the problem of threshold calculation distortion caused by the heterogeneity between the reference object and the monitored object. Adding, modifying, and deleting entries in the registry must be confirmed by the signatures of a preset proportion of consensus nodes in the blockchain network before taking effect, ensuring that the registry data is tamper-proof. This preset proportion can be configured by those skilled in the art according to the security level of the blockchain network; a typical configuration is more than 2 / 3.

[0113] Further explanation is provided: In one specific implementation of this embodiment, the fusion computing node queries and generates a list of valid reference object identifiers according to the following logic: First, extract the growth stage category code 01 and industry category code C34 from the object profile identifiers of the monitored object; Second, using "01-C34" as the retrieval primary key, query the object identifiers of all reference objects that simultaneously match the growth stage category code and industry category code from the reference object registry stored on the blockchain, and generate an initial list of reference object identifiers; Third, perform access qualification verification on each reference object in the initial list of reference object identifiers, filtering out invalid reference objects that have no valid monitoring data within a preset number of continuous collection cycles. The preset number of continuous collection cycles can be configured by those skilled in the art according to the timeliness requirements of monitoring data and the reporting frequency of operating data of the industry in which the monitored object is located. A typical configuration is to set the number of cycles to 3 collection cycles; Fourth, determine the object identifiers of the remaining reference objects after filtering as the final list of valid reference object identifiers participating in the calculation of the benchmark threshold range.

[0114] For example, for the aforementioned monitored enterprises, the fusion computing node extracts the growth stage category code 01 and the industry category code C34. Using "01-C34" as the primary key, it queries the blockchain reference object registry to obtain an initial reference object identifier list containing 126 reference objects in the same growth stage and industry. After filtering out 8 objects with no valid data in the last 3 collection periods through access qualification verification, a valid reference object identifier list containing 118 reference object identifiers is generated.

[0115] Acquire the time-series data of the comprehensive monitoring index for each reference object within the most recent collection period of the specified sliding window length. For each time position within the sliding window, such as the first, second, and last positions, calculate the lower quartile and upper quartile of the comprehensive monitoring index for all reference objects at that time position. The lower quartile refers to the value at the 1 / 4 position after the data is sorted in ascending order, and the upper quartile refers to the value at the 3 / 4 position. Further, in this embodiment, the lower and upper quartiles are calculated using linear interpolation to ensure the smoothness and accuracy of the quartile calculation results when the number of reference objects is not an integer multiple of 4, avoiding threshold range distortion caused by quartile calculation bias. Simultaneously, outlier filtering is performed on the comprehensive monitoring index data of the reference objects at each time position to remove extreme outliers before quartile calculation, improving the anti-interference capability of the baseline data. To further explain, one specific implementation of this embodiment is as follows: the fusion computing node performs quantile calculation according to the following logic: First, for each reference object in the list of valid reference objects, obtain its comprehensive monitoring index time series data within the most recent 7 collection periods, and construct a reference object time series data matrix, where the matrix row index is the reference object identifier and the column index is the 7 time positions within the sliding window; Second, for each time position within the sliding window, extract the comprehensive monitoring index values ​​of all reference objects at that position, and use the box plot method to remove extreme outliers that exceed the range of "lower quartile - 3 times the interquartile range" and "upper quartile + 3 times the interquartile range"; Third, sort the filtered values ​​in ascending order, and use linear interpolation to calculate the lower quartile Q1 and upper quartile Q3 corresponding to that time position respectively, and complete the quantile calculation for the 7 time positions within the sliding window in sequence. For example, for the 7th time position within the sliding window (i.e., the position corresponding to the current collection cycle), the fusion computing node extracts the comprehensive monitoring index of 118 reference objects at that position. After removing 3 extreme outliers, the remaining 115 values ​​are arranged in ascending order, and the lower quartile Q1 is calculated to be 0.421 and the upper quartile Q3 is 0.587 using linear interpolation.

[0116] Then, the interquartile range (ICM) is calculated, which is the difference between the upper quartile and the lower quartile. The lower limit of the baseline threshold interval for the current time position is set to the lower quartile minus 1.5 times the ICM, and the upper limit of the baseline threshold interval is the upper quartile plus 1.5 times the ICM. The aforementioned 1.5 times is a preset tolerance boundary coefficient used to distinguish between normal fluctuations and abnormal deviations. Further, the tolerance boundary coefficient in this embodiment can be pre-configured differently according to the growth stage category and industry risk level of the monitored object. For high-risk industries and early-stage objects, the tolerance boundary coefficient can be lowered to tighten the threshold interval and improve the sensitivity of anomaly identification; for low-risk industries and mature objects, the tolerance boundary coefficient can be raised to widen the threshold interval and reduce the false alarm rate. Simultaneously, threshold interval boundary verification logic is set to ensure that the lower limit of the threshold interval is not less than 0 and the upper limit is not greater than 1, meeting the numerical range requirements of the comprehensive monitoring index. To further explain, one specific implementation of this embodiment is as follows: the fusion computing node calculates the baseline threshold interval according to the following logic: First, for each time position within the sliding window, calculate the interquartile range IQR = Q3 - Q1; Second, based on the growth stage category code 01 and industry category code C34 of the monitored object, retrieve the pre-configured tolerance boundary coefficient 1.5; Third, calculate the lower limit of the baseline threshold interval for that time position = MAX(0, Q1 - 1.5 × IQR) and the upper limit of the interval = MIN(1, Q3 + 1.5 × IQR), ensuring that the threshold interval is strictly within the range of [0, 1]; Fourth, sequentially complete the calculation of the baseline threshold interval for the 7 time positions within the sliding window. For example, for the 7th time position within the sliding window, the fusion computing node calculates the interquartile range (IQR) as 0.587 - 0.421 = 0.166. Based on a tolerance boundary coefficient of 1.5, the lower limit of the interval is calculated as MAX(0, 0.421 - 1.5 × 0.166) = 0.172, and the upper limit of the interval is calculated as MIN(1, 0.587 + 1.5 × 0.166) = 0.836. Finally, the baseline threshold interval corresponding to the current acquisition cycle is generated as [0.172, 0.836].

[0117] For the comprehensive monitoring index of the current collection period, the lower and upper limits of the benchmark threshold interval corresponding to the last time position within the sliding window are obtained. Further, in this embodiment, the time positions within the sliding window correspond one-to-one with the temporal positions of the collection period, with the last time position fixed as the current collection period to be detected. This ensures that the benchmark threshold interval is completely aligned temporally with the comprehensive monitoring index of the current period, resolving the deviation judgment error problem caused by temporal misalignment. Simultaneously, the obtained lower and upper limits of the threshold interval are bound and stored with the hash value of the corresponding quantile calculation process, ensuring that the threshold data is traceable and verifiable. Further, one specific implementation of this embodiment is as follows: the fusion computing node obtains the threshold interval according to the following logic: First, determine that the last time position within the sliding window is the temporal position corresponding to the current collection period 2025W16; second, retrieve the pre-calculated lower limit of the benchmark threshold interval (0.172) and upper limit (0.836) for that time position; third, verify the hash value of the threshold interval calculation process, and after confirming that the data has not been tampered with, use it as the deviation judgment benchmark for the comprehensive monitoring index of the current collection period. For example, for the comprehensive monitoring index of the aforementioned monitored enterprise in the 2025W16 period of 0.612, the fusion computing node obtains the lower limit of the benchmark threshold interval of 0.172 and the upper limit of 0.836 corresponding to the last time position in the sliding window. After verifying the validity of the hash value in the calculation process, it is used as the benchmark interval for deviation judgment.

[0118] The deviation direction determination logic is as follows: if the current comprehensive monitoring index is less than the lower limit of the benchmark threshold range, the deviation direction is determined to be negative; if the current comprehensive monitoring index is greater than the upper limit of the benchmark threshold range, the deviation direction is determined to be positive; if the current comprehensive monitoring index is greater than or equal to the lower limit of the benchmark threshold range and less than or equal to the upper limit of the benchmark threshold range, the deviation direction is determined to be no deviation. Furthermore, the deviation direction determination logic in this embodiment includes a boundary value precise matching rule. For values ​​at the upper and lower limits of the range, the preset determination logic is strictly followed to avoid ambiguity in boundary value determination. Simultaneously, a continuous deviation marking logic is included, which can mark the deviation direction of the monitored object for multiple consecutive collection cycles, providing auxiliary basis for subsequent anomaly level determination and solving the problem of misjudgment of a single deviation. Further explanation is provided: In one specific implementation of this embodiment, the fusion computing node performs deviation direction determination according to the following fixed logic: First, the current comprehensive monitoring index is compared with the lower and upper limits of the benchmark threshold interval; Second, if the comprehensive monitoring index < the lower limit of the interval, the deviation direction is determined to be a negative deviation; if the comprehensive monitoring index > the upper limit of the interval, the deviation direction is determined to be a positive deviation; if the lower limit of the interval ≤ the comprehensive monitoring index ≤ the upper limit of the interval, the deviation direction is determined to be no deviation; Third, the deviation direction identifier determined this time is associated with the deviation direction identifiers of the monitored object in the previous 3 collection cycles, marking the continuous deviation state and storing it in the determination result. For example, for the comprehensive monitoring index of 0.612 in the 2025W16 cycle of the aforementioned monitored enterprise, the fusion computing node compares and confirms that 0.172 ≤ 0.612 ≤ 0.836, which meets the determination rule of values ​​within the interval. Finally, the deviation direction identifier is determined to be no deviation, and the enterprise is marked as having been in a no-deviation state for 4 consecutive collection cycles.

[0119] Furthermore, the trend deviation detection model in this embodiment is also equipped with a continuous deviation trend accumulation early warning mechanism, which can accumulate and identify the same-direction deviation trend of the monitored object in multiple consecutive collection cycles. Even if the comprehensive monitoring index of a single collection cycle is within the benchmark threshold range and the deviation direction is marked as no deviation, if multiple consecutive cycles show a continuous same-direction trend deviation, an early warning of the corresponding level will be triggered. This solves the technical problem that the existing solution can only identify a single large deviation and cannot identify the potential risk of a continuous small trend deterioration, and greatly improves the foresight of post-investment risk monitoring. Further explanation is provided: In one specific implementation of this embodiment, after the trend deviation detection model completes the single-cycle deviation direction determination, it simultaneously performs continuous deviation trend accumulation verification: First, it retrieves the deviation direction identifiers and comprehensive monitoring index values ​​for the five most recent preset consecutive collection cycles of the monitored object to construct a trend verification sequence; Second, it uses the least squares method to linearly fit the comprehensive monitoring index in the trend verification sequence, calculates the slope of the fitted trend line, where a negative slope represents a continuous downward trend and a positive slope represents a continuous upward trend; Third, it uses the least squares method to linearly fit the comprehensive monitoring index in the trend verification sequence, calculates the slope of the fitted trend line, and if the absolute value of the slope of the fitted trend line is greater than a preset cumulative trend threshold, and the comprehensive monitoring index in each cycle of the trend verification sequence shows a monotonically increasing or monotonically decreasing trend in the same direction, then it is determined to be... A continuous cumulative deviation trend exists; wherein, the cumulative trend threshold can be configured by those skilled in the art based on the sensitivity to continuous small trend changes, and the lower the threshold setting, the higher the warning sensitivity; fourth step, if a continuous cumulative deviation trend is determined to exist, then based on the magnitude of the absolute value of the slope, a corresponding cumulative warning label is generated by comparing it with the preset cumulative warning level threshold. The specific division range of the cumulative warning level threshold can be configured by those skilled in the art based on the granularity of the business risk level division. A typical configuration is as follows: when the absolute value of the slope is less than 0.05 and greater than or equal to 0.03, a first-level cumulative attention label is generated; when the absolute value of the slope is less than 0.08 and greater than or equal to 0.05, a second-level cumulative warning label is generated; when the absolute value of the slope is greater than or equal to 0.08, a third-level cumulative alarm label is generated; finally, the cumulative warning label is synchronously added to the monitoring results.For example, for the aforementioned monitored enterprise, the data for the most recent 5 periods [0.598, 0.602, 0.608, 0.612, 0.615] of its comprehensive monitoring index for 5 periods from 2025W12 to 2025W16 are retrieved. The slope of the fitted trend line is 0.0038. The absolute value of this slope is less than the preset cumulative trend threshold of 0.03, so no cumulative warning is triggered. If the comprehensive monitoring index of an enterprise for the most recent 5 consecutive periods is [0.600, 0.580, 0.560, 0.540, 0.520], and the slope of the fitted trend line is -0.04, the absolute value of which is 0.04 is within the range of greater than or equal to 0.03 and less than 0.05, then a first-level cumulative attention mark is generated, and this mark is added to the monitoring results of the current period.

[0120] After determining the deviation direction, an anomaly level is determined. First, the deviation of the current comprehensive monitoring index from the baseline threshold range is calculated. The deviation range is calculated as follows: first, the median value between the lower and upper limits of the threshold range is calculated (i.e., the sum of the lower and upper limits divided by two); then, the half-range width between the lower and upper limits of the threshold range is calculated (i.e., the difference between the upper and lower limits divided by two). Next, the absolute value of the difference between the current comprehensive monitoring index and the median value is calculated, and this absolute value is divided by the half-range width to obtain the deviation range value. Further, the deviation range calculation logic in this embodiment has a division-by-zero anomaly protection mechanism. When the half-range width is 0, the deviation range is directly determined to be 0, avoiding program anomalies caused by division by zero during the calculation process. Simultaneously, all intermediate values ​​in the calculation process retain 4 significant digits to ensure consistent calculation accuracy and avoid deviations in the deviation range calculation caused by differences in precision. To further explain, one specific implementation of this embodiment is as follows: the fusion computing node calculates the deviation magnitude according to the following logic: First, perform a division-by-zero anomaly check. If the difference between the upper and lower limits of the threshold interval is 0, directly output the deviation magnitude as 0. Second, if the difference is not 0, calculate the median value of the threshold interval = (lower limit of the interval + upper limit of the interval) / 2, and the half-interval width = (upper limit of the interval - lower limit of the interval) / 2. Third, calculate the absolute value of the difference between the comprehensive monitoring index and the median value, divide the absolute value by the half-interval width to obtain the deviation magnitude value, and retain 4 significant digits in the result. For example, for the threshold range [0.172, 0.836] of the aforementioned monitored enterprise, the fusion computing node first checks that the interval difference is not 0, calculates the median value = (0.172 + 0.836) / 2 = 0.504, and the half-interval width = (0.836 - 0.172) / 2 = 0.332; then calculates |0.612 - 0.504| = 0.108, and finally obtains the deviation range = 0.108 / 0.332 ≈ 0.3253.

[0121] Based on the numerical range of the deviation, an anomaly level identifier is output according to a preset level classification rule. The specific classification rule includes: when the deviation is less than 1, it is classified as level 0, meaning normal; when the deviation is greater than or equal to 1 and less than 2, it is classified as level 1, meaning "attention"; when the deviation is greater than or equal to 2 and less than 3, it is classified as level 2, meaning "warning"; and when the deviation is greater than or equal to 3, it is classified as level 3, meaning "alarm". When the deviation direction identifier is "no deviation", regardless of the calculated deviation value, the corresponding anomaly level identifier is forcibly set to level 0. Furthermore, the anomaly level determination logic in this embodiment has a mandatory rule priority mechanism. The rule "forcibly set to level 0 when there is no deviation" has the highest priority and is executed before the level classification rule based on the deviation magnitude, logically avoiding misjudgment of the anomaly level in the "no deviation" state. Simultaneously, for the numerical boundaries in the level classification rule, clear closed and open interval determination rules are set to ensure that the boundary value determination is unambiguous. To further explain, one specific implementation of this embodiment is as follows: the fusion computing node executes anomaly level determination in priority order: First, it executes the highest priority rule verification. If the deviation direction identifier is "no deviation," it directly forces the anomaly level identifier to be set to level 0, terminating the subsequent determination process. Second, if the deviation direction identifier is "negative deviation" or "positive deviation," it then performs level determination according to the numerical range of the deviation magnitude, following a preset level division rule. For boundary values, it strictly adheres to the rule that "greater than or equal to" is a closed interval and "less than" is an open interval, ensuring unambiguous determination logic. Third, it binds and stores the determined anomaly level identifier with the deviation magnitude and deviation direction identifier. For example, for the aforementioned monitored enterprise, the fusion computing node first verifies that its deviation direction identifier is "no deviation," triggering the highest priority forced rule. Regardless of the calculated deviation magnitude value of 0.3253, it directly forces the anomaly level identifier to be set to level 0, semantically indicating normality.

[0122] The above calculations and judgments are assembled into a complete monitoring result. The monitoring result includes the following seven fields: monitored object identifier, used to uniquely identify the currently monitored object; collection period identifier, used to identify the collection period to which the current data belongs; comprehensive monitoring index value, i.e., the comprehensive monitoring index calculated in the current collection period; lower limit of the benchmark threshold interval, i.e., the lower limit of the benchmark threshold interval corresponding to the current collection period; upper limit of the benchmark threshold interval, i.e., the upper limit of the benchmark threshold interval corresponding to the current collection period; anomaly level identifier, with values ​​of level 0, level 1, level 2, or level 3; and deviation direction identifier, with values ​​of negative deviation, no deviation, or positive deviation. Furthermore, the monitoring results in this embodiment are stored in a fixed-length structured format. The type, length, and value range of each field have predefined specifications to ensure consistency in cross-node data parsing. Simultaneously, a monitoring result integrity verification logic is set up to verify the integrity and compliance of the seven required fields, ensuring that the output monitoring results have no missing fields and no format errors. Further explanation is provided: In one specific implementation of this embodiment, the fusion computing node assembles the monitoring results according to the following logic: First, according to the preset field order, the contents of seven fields are filled in sequentially: monitored object identifier, collection period identifier, comprehensive monitoring index value, lower limit of the benchmark threshold range, upper limit of the benchmark threshold range, anomaly level identifier, and deviation direction identifier; Second, the format and value range of each field are validated to ensure that the monitored object identifier is an 18-digit unified social credit code, the collection period identifier conforms to the preset format, the comprehensive monitoring index and threshold range value are in the [0, 1] range, and the anomaly level identifier and deviation direction identifier are within the preset enumeration value range; Third, after the validation passes, a complete structured monitoring result is generated, and SHA-256 hash operation is performed on the full content of the monitoring result to generate a monitoring result validation hash value, which is then bound and stored with the monitoring result. For example, for the aforementioned monitored enterprise, the fusion computing node assembles the monitoring results according to the field order, and fills in the monitored object identifier 9132******5678, the collection period identifier 2025W16, the comprehensive monitoring index 0.612, the lower limit of the benchmark threshold range 0.172, the upper limit of the benchmark threshold range 0.836, the anomaly level identifier level 0, and the deviation direction identifier no deviation. After all fields are verified to be compliant, a monitoring result verification hash value is generated and stored in conjunction with the monitoring results.

[0123] The fusion computing node outputs the monitoring results to the feedback node. Further, in this embodiment, the data transmission between the fusion computing node and the feedback node adopts the same transmission protocol and verification mechanism as between the preprocessing node and the fusion computing node, ensuring the tamper-proof capability and consistency of the entire data transmission chain. Simultaneously, all data transmission records between nodes are written into the blockchain node interaction audit ledger, achieving full-process data interaction traceability. Further, in one specific implementation of this embodiment, before outputting the monitoring results, the fusion computing node performs pre-transmission processing according to the following logic: First, the assembled monitoring results, monitoring result verification hash value, and global association primary key are encapsulated into a TLV format transmission data packet; second, the sending node identifier, receiving node identifier, global association primary key, transmission timestamp, and transmission verification hash value of this transmission are completely written into the blockchain node interaction audit ledger; third, the data packet is sent to the feedback node. If no receipt confirmation is received from the feedback node within a preset timeout period, a retransmission mechanism is triggered, with a maximum of 3 retransmissions. If the number of retransmissions is exceeded, a node communication anomaly alarm is output. For example, the fusion computing node encapsulates the monitoring results, verification hash value, and global association primary key of the aforementioned monitored enterprise for the 2025W16 period into a transmission data packet, writes the transmission record into the blockchain node interaction audit ledger, and sends it to the feedback node. After receiving the receipt confirmation acknowledgment from the feedback node, the output process of this monitoring result is completed.

[0124] It should be further explained that the feedback node in this embodiment is configured as follows:

[0125] The seven fields contained in the received monitoring results are concatenated into a string in a fixed order to obtain the second hash value. Further, in this embodiment, the fixed concatenation order of the seven fields is: monitored object identifier, collection period identifier, comprehensive monitoring index value, lower limit of the benchmark threshold range, upper limit of the benchmark threshold range, anomaly level identifier, and deviation direction identifier. This concatenation order is written into the blockchain configuration contract during system initialization, is universal across all nodes, and cannot be arbitrarily changed. This solves the technical problem of inconsistent hash value calculation results and cross-node verification failures caused by inconsistent concatenation orders. The hash operation uses the SHA-256 irreversible cryptographic hash algorithm, which is completely consistent with the first and second hash operations, ensuring the uniformity of hash operation rules across the entire chain and avoiding verification misjudgments caused by algorithm differences. During the concatenation process, all fields use a preset fixed character encoding format. Numerical fields retain 4 significant digits, and enumerated fields use preset standard encoding values ​​to avoid hash value distortion caused by format differences. To further explain, one specific implementation of this embodiment is as follows: before performing the hash operation, the feedback node first performs format standardization processing on the seven fields: numerical fields are uniformly retained to have 4 significant digits; enumerated anomaly level identifiers and deviation direction identifiers are converted into preset standard numerical codes; then, these are concatenated in a fixed order to form a UTF-8 encoded string; and the concatenated complete string is subjected to a SHA-256 hash operation to generate a unique second hash value. For example, for the monitored enterprise with a unified social credit code of 9132****5678 and a collection period of 2025W16, the feedback node concatenates the standardized content of the seven fields in a fixed order, generates a complete string, and then performs a SHA-256 hash operation to obtain the second hash value 5f8d2a7c9e3b1d0f4a6c8e0b2d4f6a8c0e2b4d6f8a0c2e4b6d8f0a2c4e6b8d. This hash value is uniquely bound to the monitoring result.

[0126] The block height of the current block is obtained, the next block associated with the current block is determined, and the second hash value is used as the digital fingerprint of the current monitoring result and written into a preset field in the block header of the next block. This preset field is specifically used to store the monitoring result hash value from the feedback node. Further explanation is that in this embodiment, the current block is the block storing the original structured panel data of this collection cycle, and the next block is a new block to be generated in subsequent collection cycles. The block height is a globally unique, continuously increasing block number in the blockchain network, ensuring the uniqueness of the block association relationship. The preset field in the block header is a fixed-length field predefined during system initialization. The field length completely matches the 256-bit length of the SHA-256 hash value. The field position is fixed and cannot be changed. Only the feedback node has write permission for this field, while other nodes only have read permission, solving the technical problems of multi-node write conflicts and chaotic field parsing. To further explain, one specific implementation of this embodiment is as follows: the feedback node first synchronizes the block height with the consensus node in the blockchain network, confirming that the final consensus block height of the block currently storing the original data is 1257, and determines that the associated next block is a new block to be generated with a block height of 1258; the second hash value is written into the predefined monitoring result hash value field in the header of the new block with a block height of 1258. This field is only written by the feedback node when the new block is generated, and cannot be tampered with after being written. For example, for the monitoring results of the aforementioned 2025W16 cycle, the feedback node confirms that the current block height is 1257, and writes the generated second hash value into the preset field in the header of the next block with a block height of 1258, as an immutable digital fingerprint of the monitoring result.

[0127] Simultaneously, a backward hash pointer is established in the block header of the next block, pointing to the block body hash of the current block. This backward hash pointer, together with the forward hash pointer established in the collection node, constitutes a complete bidirectional hash pointer verification link. Specifically, the forward hash pointer written by the collection node in the block header points to the block body hash of the previous block for backward verification; the backward hash pointer written by the feedback node in the next block header points to the block body hash of the current block for backward verification. Further, in this embodiment, the backward hash pointer is taken as the complete hash value of the block body of the current block, which is completely consistent with the first hash value generated by the collection node, ensuring the uniqueness and accuracy of the pointer's pointing. In the bidirectional hash pointer verification link, the forward hash pointer enables the verification capability of tracing back to historical blocks from the current block, while the backward hash pointer enables the verification capability of verifying the current block from subsequent blocks. The combination of the two forms an interlocking full-link verification closed loop, solving the technical problems that a single forward pointer cannot achieve reverse verification of historical blocks by subsequent blocks and the inability to trace tampering behavior across the entire link. To further explain, one specific implementation of this embodiment is as follows: the feedback node reads the block body hash value of the current block from the block header, uses this hash value as a backward hash pointer, and writes it into a preset backward pointer field in the block header of the next block. This backward hash pointer and the forward hash pointer written by the collection node in the current block header, which points to the block body hash of the previous block, form a two-way binding relationship. If the block body data of any block is tampered with, the hash pointer verification of the two blocks will fail, thus achieving two-way location of the tampering behavior. For example, for the current block with block height 1257, the feedback node reads its block body hash value, uses it as a backward hash pointer, and writes it into the next block header with block height 1258. Together with the forward hash pointer in the current block header pointing to block height 1256, they constitute a complete two-way hash pointer verification chain.

[0128] The system invokes a pre-defined smart contract for monitoring result notarization. This smart contract is pre-deployed in the blockchain network and exposes an interface method named "Write Monitoring Result". Further, in this embodiment, the monitoring result notarization smart contract is deployed after reaching consensus among more than 2 / 3 of the consensus nodes in the blockchain network during system initialization. After deployment, the contract code is immutable, ensuring the consistency of contract execution logic. The "Write Monitoring Result" interface method is configured with a node role-based access control policy, ensuring that only the reporting node has the permission to call this interface; calls initiated by other nodes will be directly rejected, solving the technical problem of unauthorized nodes maliciously calling the contract and tampering with the notarized data. The interface method predefines strict requirements for parameter format, type, and quantity; calls that do not meet the requirements will directly trigger a contract anomaly alarm. To further explain, one specific implementation of this embodiment is that the monitoring result notarization smart contract is deployed in all consensus nodes and business nodes of the consortium blockchain. The contract code is uploaded to the blockchain after multi-signature consensus and cannot be modified. The "write monitoring result" interface method is configured with whitelist access control. Only the blockchain address of the feedback node is in the whitelist. Call requests initiated by non-whitelist addresses will be directly intercepted by the contract, and the illegal call record will be written into the blockchain operation audit ledger.

[0129] When calling this interface, the following parameters are passed in: the monitored object identifier, the collection period identifier, the comprehensive monitoring index value, the lower limit of the benchmark threshold range, the upper limit of the benchmark threshold range, the anomaly level identifier, the deviation direction identifier, and the second hash value. After receiving these parameters, the smart contract performs the following operations: verifies whether the data type and value range of the passed parameters conform to preset rules; uses the combination key of the monitored object identifier and the collection period identifier as the primary key, and writes the monitoring result to the monitoring result data table in the distributed ledger; simultaneously, it establishes a hash pointer association from the monitoring result record to the block body where the original collected data is located, that is, it stores the block body hash value of the block where the original collected data is located in the monitoring result record, used to achieve complete traceability verification from the monitoring result to the original collected data. If the write operation is successful, the smart contract returns a confirmation identifier for successful write; if the write operation fails, for example due to a primary key conflict or network anomaly, a write failure alarm is triggered, and the failure record is output to the management terminal. Furthermore, the preset parameter verification rules in this embodiment are completely consistent with the full-link data format specifications. Specifically, these include: the monitored object identifier is in the 18-digit unified social credit code format; the collection period identifier conforms to the preset period encoding specification; the value range of numerical parameters is strictly limited to the [0,1] interval; and the enumeration parameters are preset standard values. This ensures the compliance of the data written to the distributed ledger and solves the problem of evidence invalidation caused by dirty data writing. The combined key adopts a fixed concatenation format of "unique ID of monitored object - collection period identifier" that is completely consistent with the block storage, ensuring that the primary key is globally unique and avoiding primary key conflicts. The hash pointer association establishes a unique traceability link between the monitoring results and the original collected data, solving the technical problem of the monitoring results being disconnected from the original data and the inability to verify the authenticity of the results. To further explain, one specific implementation of this embodiment is as follows: After receiving the interface call parameters, the smart contract executes the operation according to the following logic: First, it verifies the data type, format, and value range of the parameters field by field. If any parameter fails the verification, the execution is terminated directly, and a parameter verification failure flag is returned. Second, after the verification is passed, a combined primary key of "monitored object identifier - collection period identifier" is generated. It first checks whether a record with this primary key already exists in the distributed ledger. If it already exists, it is determined to be a primary key conflict, the execution is terminated, and a write failure alarm is triggered. Third, if there is no primary key conflict, all fields of the monitoring result are written to the monitoring result data table. At the same time, the block height and block body hash value of the block where the original collected data is located are stored in the record to establish a traceability association. Fourth, after the writing is completed, a confirmation flag of successful writing is returned, and the record of this contract execution is written to the blockchain operation audit ledger.For example, regarding the monitoring results of the aforementioned monitored enterprise in the 2025W16 period, when the feedback node calls the contract interface, it passes in the corresponding 8 parameters. After the smart contract completes the parameter verification, it generates the composite primary key "9132******5678-2025W16". After verifying that there is no primary key conflict, it writes the monitoring results into the distributed ledger. At the same time, it stores the block height 1257 where the original data is located and the block body hash value in the record to establish a traceability association. Finally, it returns a confirmation flag indicating that the write was successful.

[0130] The system reads the anomaly level and deviation direction indicators from the monitoring results and generates corresponding task generation instructions according to a preset task triggering rule table. This task triggering rule table is pre-stored in a blockchain configuration contract and updated through a consensus mechanism. Its mapping rules are as follows: When the anomaly level is level 0, no task generation instruction is triggered regardless of the deviation direction indicator value; when the anomaly level is level 1 and the deviation direction indicator is a negative deviation, a task generation instruction of type "mild concern" is triggered, with the instruction prompting management personnel to pay attention to negative trends in the monitored object; when the anomaly level is level 1 and the deviation direction indicator is a positive deviation, a task generation instruction of type "mild concern" is triggered, with the instruction prompting management personnel to pay attention to positive trends in the monitored object; when the anomaly level is level 2 and the deviation direction indicator is a negative deviation, the trigger type is "on-site verification". The task generation instructions include: requiring managers to conduct on-site data verification of the monitored object within a specified time limit; when the anomaly level is identified as Level 2 and the deviation direction is identified as positive, a task generation instruction of type "trend analysis" is triggered, requiring managers to analyze the sustainability and potential risks of the positive deviation; when the anomaly level is identified as Level 3 and the deviation direction is identified as negative, a task generation instruction of type "emergency response" is triggered, requiring managers to immediately activate the emergency plan and intervene; when the anomaly level is identified as Level 3 and the deviation direction is identified as positive, a task generation instruction of type "emergency verification" is triggered, requiring managers to urgently verify the authenticity of the data and assess the impact of excessive deviation. Furthermore, the task triggering rule table in this embodiment adopts versioned management. Each update is accompanied by a unique version number and effective block height. The new version rule can only take effect when the block height reaches the effective block height, solving the technical problem of inconsistent instruction generation logic among multiple nodes caused by asynchronous rule updates. The rule table update operation requires consensus from more than 2 / 3 of the consensus nodes in the blockchain network before it can be written into the configuration contract, ensuring that the rules cannot be maliciously tampered with. The mapping rules are set with strict priorities. The rule with an anomaly level of 0 has the highest priority and is executed before all other rules to avoid the problem of accidental triggering in the absence of deviation. Furthermore, in a specific implementation of this embodiment, the feedback node first reads the latest version of the task triggering rule table with the current effective block height less than or equal to the current block height from the blockchain configuration contract, then reads the anomaly level identifier and deviation direction identifier from the monitoring results, and matches the corresponding mapping rules in priority order. If a rule with a level of 0 is matched, the instruction generation process is directly terminated. If a rule of another level is matched, the corresponding type of task generation instruction is generated according to the rule, and the rule version number, matching basis, and instruction content of the generated instruction are written into the blockchain operation audit ledger.For example, regarding the monitoring results of a monitored enterprise in the 2025W17 period, its anomaly level is identified as Level 2 and its deviation direction is identified as negative deviation. The feedback node reads the latest effective rule table, matches the corresponding mapping rule, and generates a task generation instruction of type "on-site verification". The instruction clearly requires the management personnel to conduct on-site data verification of the enterprise within 7 calendar days.

[0131] The generated task generation instructions are assembled into a complete output message. The task generation instructions include the following fields: unique instruction identifier, instruction type (values ​​include mild concern, on-site verification, trend analysis, emergency handling, or emergency review), monitored object identifier, collection cycle identifier, anomaly level identifier, deviation direction identifier, comprehensive monitoring index value, upper and lower limits of the benchmark threshold range, instruction generation timestamp, and suggested response time limit. Further, in this embodiment, the unique instruction identifier is generated using a fixed format of "block height - monitored object identifier - random number" to ensure global uniqueness and avoid duplicate or missed instruction execution. All fields are encoded using a preset TLV fixed format to ensure accurate parsing of instruction content by different types of management terminals. The suggested response time limit is pre-configured based on instruction type and stored in a task triggering rule table; different instruction types correspond to different response time limit requirements to ensure the timeliness of task handling. To further explain, one specific implementation of this embodiment is as follows: the feedback node assembles the output message according to the following logic: First, a globally unique instruction identifier is generated, which includes the current block height, the identifier of the monitored object, and a 16-bit random number; Second, all required fields, such as instruction type and the identifier of the monitored object, are filled in sequentially according to a preset field order. The suggested response time limit is automatically matched to a preset value based on the instruction type: 15 calendar days for instructions of light concern, 7 calendar days for on-site verification and trend analysis, and 24 hours for emergency handling and emergency review; Third, all fields are encoded into a complete output message in TLV format, and a hash operation is performed on the message to generate an instruction verification hash value, which is then bound to the output message. For example, for the on-site verification instruction for the aforementioned negative deviation of Level 2, the feedback node generates an instruction unique identifier of 1259-9132******5678-8f2d7c9e3b1a0d4f, fills in all the contents in the order of the fields, sets the suggested response time limit to 7 calendar days, encodes the complete output message in TLV format, and generates the corresponding instruction verification hash value.

[0132] Depending on the type of management terminal, the corresponding transmission method is used to output the instruction: if the management terminal is a monitoring screen, the instruction is pushed to the screen front end via WebSocket; if the management terminal is a mobile terminal, the instruction is sent to the specified mobile application via message push service; if the management terminal is a PC client, the instruction data is returned via HTTP interface; if the management terminal is an SMS gateway or email server, the instruction content is output via the corresponding SMS sending interface or email sending interface. Furthermore, all transmission methods in this embodiment are configured with message receipt and retransmission mechanisms to ensure reliable instruction delivery and solve the technical problems of packet loss and missed transmission during instruction transmission; each transmission method is configured with a corresponding encrypted transmission strategy: WebSocket uses the WSS encryption protocol, HTTP uses the HTTPS encryption protocol, and SMS and email use the national cryptographic SM2 algorithm to encrypt content, ensuring data security during instruction transmission; simultaneously, a permission-based push strategy based on administrator roles is configured, pushing instructions only to terminals with the corresponding management permissions for the monitored object to avoid unauthorized instruction pushes. To further explain, one specific implementation of this embodiment is as follows: the feedback node first parses the type of the management terminal and its corresponding permission information, matches the corresponding transmission method and encryption strategy, and executes the instruction push operation; after the push, a timeout monitoring is initiated. If no receipt is received from the terminal within the preset 500ms timeout period, a retransmission mechanism is triggered, with a maximum of 3 retransmissions; if no receipt is received after exceeding the retransmission limit, an instruction push failure alarm is triggered, and the failure record is written to the blockchain operation audit ledger. For example, for the aforementioned on-site verification instruction, the management terminal is the PC client of the post-investment management personnel. The feedback node pushes the instruction data to the corresponding PC client through an HTTPS encrypted HTTP interface. After receiving the receipt returned by the client, the instruction output process is completed; if no receipt is received, a maximum of 3 retransmission operations are performed according to preset rules.

[0133] Furthermore, the task generation instructions in this embodiment are configured with a full lifecycle closed-loop management mechanism, which can realize the on-chain evidence storage of the entire process of task generation, dispatch, disposal, review and archiving. At the same time, the disposal results and effects are fed back to the front-end weight allocation model and trend deviation detection model to realize adaptive iterative optimization of model parameters. This solves the technical problem that the existing solution can only generate disposal instructions and cannot realize disposal closed loop and model self-optimization, forming a complete business closed loop of "monitoring-early warning-disposal-optimization". Further explanation is provided below. In one specific implementation of this embodiment, after the feedback node completes the instruction output, it simultaneously initiates the full lifecycle management process for the task: First, a unique task serial number is assigned to the generated task generation instruction. The task serial number, instruction content, dispatch time, and responsible manager identifier are written into the task management ledger on the blockchain, and the task status is initialized to "pending processing." Second, the task processing progress and results transmitted back from the management terminal are monitored in real time. The task status is updated in real time based on the transmitted content. The status includes "processing," "reviewed," and "archived." Each status change requires the digital signature of the manager, and the change record is completely stored on the blockchain. Third, after the task is archived, the risk mitigation effect and data authenticity verification results are extracted from the processing results and fed back to the weight configuration contract and trend deviation detection model, respectively. Fourth, every six collection cycles, based on the archived task processing data, the dynamic weight coefficients of the weight allocation matrix and the tolerance boundary coefficients of the trend deviation detection model are incrementally optimized. The optimized parameters must be confirmed by more than 2 / 3 of the consensus nodes before taking effect, achieving continuous self-optimization of the model. For example, for the aforementioned Level 2 on-site verification task, the feedback node assigns a unique task serial number RW2025W17001, writes all task information into the blockchain task management ledger, and marks the status as "pending processing". After receiving the on-site review report and processing results from the management personnel, the task status is updated to "archived", and the result of verifying that the enterprise data is true and without anomalies is fed back to the trend deviation detection model for subsequent fine-tuning and optimization of the tolerance boundary coefficient, ensuring that the model's anomaly identification accuracy continues to improve.

[0134] After the feedback node completes the above operations, the complete processing flow of the current collection cycle ends. When a subsequent collection cycle starts, the collection node will read the second hash value and backward hash pointer written by the feedback node from the block header of the previous block when generating a new block. This is used to verify whether the monitoring results of the previous collection cycle have been tampered with, thus forming a complete hash pointer verification closed loop from collection, preprocessing, fusion calculation to feedback and evidence storage. To further explain, the verification logic of the complete hash pointer verification closed loop in this embodiment is as follows: When the collection node generates a new block in a subsequent collection cycle, it first recalculates the hash value of the monitoring result of the previous collection cycle and compares it with the second hash value stored in the block header. At the same time, it verifies whether the backward hash pointer is consistent with the block body hash value of the previous block. Only if both comparisons pass can it be determined that the data of the previous cycle has not been tampered with, thus solving the technical problem that data tampering in the entire process cannot be identified and the verification link is broken. If the verification fails, the collection node will immediately trigger a full-link data tampering alarm, stop the process of the current collection cycle, and write the abnormal record into the blockchain abnormal event storage ledger to ensure the immutability of the data in the entire link. To further explain, one specific implementation of this embodiment is as follows: When the 2025W17 collection cycle starts, before the collection node generates a new block with a block height of 1258, it first reads the second hash value and backward hash pointer written by the feedback node from the header of the previous block with a block height of 1257. The first step is to recalculate the hash value of the monitoring result of the 2025W16 cycle and compare it with the read second hash value to verify whether the monitoring result has been tampered with. The second step is to verify whether the backward hash pointer is consistent with the hash value of the block body at block height 1257, and to verify whether the original collected data has been tampered with. Only after both verifications pass can the collection process of the current cycle be started, forming a closed-loop verification process. For example, when the 2025W17 cycle starts, the collection node executes the above verification process. If both comparison results are consistent, it is determined that the entire process data of the 2025W16 cycle has not been tampered with, and the collection processing process of the current cycle is started normally. If the comparison is inconsistent, a data tampering alarm will be triggered immediately, the process will be stopped, and the abnormal event will be recorded.

[0135] This embodiment achieves reliable assurance and intelligent adaptive evolution of post-investment monitoring data throughout its entire lifecycle through a four-layer on-chain collaborative architecture encompassing data collection, preprocessing, fusion computation, and feedback. In the data collection phase, the front-end data access gateway performs digital signature verification and periodic identity verification based on blockchain public keys, blocking unauthorized terminals from submitting false data by forging identities. Combined with an adaptive update mechanism for growth stages and on-chain evidence storage of detailed field pruning, template matching and field pruning are dynamically adjusted according to the company's actual development, eliminating the mismatch between fixed models and business needs. Merkle hash tree block operations and CP-ABE fine-grained encryption securely upload structured panel data to the blockchain, enabling precise location of single-field tampering and mandatory access control. In the preprocessing phase, external authoritative data sources are introduced and time-series aligned and cross-verified. A quantifiable credibility score is generated to adaptively lower the weight of trusted data, addressing the fundamental deficiency of self-reported data lacking third-party verification. Integrity verification is completed by recalculating the second hash value of the block header, and real-time location of tampered fields is achieved by comparing leaf nodes. The fusion computing nodes dynamically generate threshold ranges using box plots of reference groups of similar growth stages and industries, replacing fixed thresholds to eliminate misjudgments due to industry heterogeneity; the continuous cumulative trend early warning mechanism identifies continuous small deviations in advance, making up for the lag in traditional single-point deviation detection; the deviation magnitude is combined with mandatory priority rules to ensure that the logic for judging anomalies is rigorous and unambiguous. The feedback node writes the hash value of the monitoring result as the second hash value into the header of the next block and establishes a backward hash pointer. Together with the forward hash pointer of the collection node, they form a two-way verification closed loop, ensuring that any tampering with the data in any block will cause the forward and backward pointers to become invalid synchronously, achieving full-link traceability. The monitoring result is notarized by a smart contract and established with a hash association with the original collection block, ensuring that the result is bound to the source data immutably. Differentiated task instructions are triggered based on the anomaly level and deviation direction, and a full lifecycle closed-loop management is established. The handling results are fed back to the weight allocation model and trend detection model, driving the continuous iterative optimization of the weight coefficient and tolerance boundary. Finally, a complete business and technical closed loop is formed, which is trustworthy in collection, traceable in verification, perceptible in deviation, closed-loop in handling, and self-optimizable in model. From the data source to business intervention, the entire process is immutable, auditable, and adaptive.

[0136] Example 2

[0137] Another embodiment of the present invention provides a data monitoring and processing method based on blockchain hash pointer verification, comprising:

[0138] S1. Obtain unstructured document data uploaded by the monitored object's terminal and the corresponding object profile identifier according to the first preset cycle. The object profile identifier includes at least a growth stage category code.

[0139] Based on the object profile identifier, a corresponding structured data table template is matched from a preset template library. The template includes field names, data types, units, value ranges, and field correlation benchmark values.

[0140] The semantic-rule hybrid parsing engine is invoked to extract key numerical fields from the unstructured document. The parsing engine executes the following steps sequentially:

[0141] Based on regular expression matching of variants of predefined field names;

[0142] Recognize numerical values ​​and their contextual semantic labels using lightweight named entity recognition;

[0143] When the matching confidence score is lower than the first confidence threshold, output the queue of entries to be manually labeled.

[0144] The extracted key numerical fields are mapped to the structured data table template according to the field name to generate structured panel data, wherein unmatched template fields are filled with null value identifiers;

[0145] Perform a first hash operation on the structured panel data to generate a first hash value bound to the current collection period. Store the structured panel data and the first hash value in the block body of the current block in the form of key-value pairs, where the key is a combination of the current collection period identifier and the identifier of the monitored object, and the value is the structured panel data and the first hash value.

[0146] Based on the growth stage category code, the correlation threshold vector of each field under the growth stage is obtained from the field correlation threshold mapping table. The field correlation is calculated in advance from historical panel data using the information gain algorithm, which represents the degree of contribution of the field to the comprehensive monitoring index.

[0147] Obtain the set of fields to be filled corresponding to the current collection period, wherein the set of fields to be filled is the union of all fields in the structured data table template;

[0148] Iterate through each field in the set of fields to be filled, compare its field correlation degree with the corresponding correlation degree threshold, filter out fields with correlation degree lower than the threshold, and generate a dimensionality-reduced subset of collected fields.

[0149] A second hash operation is performed on the subset of collected fields to generate a second hash value, and the second hash value is written into the block header of the current block. At the same time, the first hash value is used as a forward hash pointer in the block header to point to the block body hash of the previous block, forming a chained hash verification structure.

[0150] S2. Obtain the structured panel data output by the acquisition node, and match at least one corresponding external data source from the preset external data source configuration table according to the growth stage category code in the object profile identifier. The external data source includes at least one of the following: aggregated statistical data of reference object groups in the same growth stage, environmental sensor time series data, and statistical feature values ​​of historical benchmark intervals.

[0151] Performing a time-series alignment operation on the structured panel data and the external data source specifically includes:

[0152] The alignment reference is based on the timestamp of the first preset period configured on the acquisition node;

[0153] The timestamps of the external data source are mapped to each collection time in the first preset period using linear interpolation or nearest neighbor matching.

[0154] Generate an aligned multidimensional data matrix with the collection period timestamp as the primary key, where the row index is the collection period identifier and the column index is the union of the monitoring dimension and the external data dimension;

[0155] Integrity verification is performed on the structured panel data by invoking the second hash value stored in the block header, specifically including:

[0156] Re-execute the first hash operation on the currently acquired structured panel data to generate a hash value to be verified;

[0157] Read the second hash value from the block header of the current block;

[0158] Compare whether the hash value to be verified is consistent with the second hash value:

[0159] If they match, the integrity check is considered passed.

[0160] If there is a discrepancy, a data integrity error alarm will be triggered, the current preprocessing process will be stopped, and a verification failure record containing the block identifier and the collection period identifier will be output to the management terminal.

[0161] After the verification is passed, the original values ​​of each monitoring dimension are normalized according to the preset unit conversion rules. The unit conversion rules are pre-stored in the structured data table template at the field level, including the conversion type identifier and conversion parameters. The normalization process adopts the Min-Max normalization method to map the original values ​​of each monitoring dimension to the [0, 1] interval and generate a normalized feature value sequence.

[0162] Based on the time-series context identifier corresponding to the current acquisition period, a preset weight allocation matrix is ​​retrieved; where:

[0163] The temporal context identifier is generated by combining the growth stage identifier and the operating environment stage identifier in an enumerated value concatenation manner. The growth stage identifier is obtained from the object profile identifier, and the operating environment stage identifier is obtained in real time by a preset environment stage classifier based on the external environment parameters of the current collection period.

[0164] The weight allocation matrix uses the time-series context identifier as the row index and the monitoring dimension identifier as the column index to record the dynamic weight coefficient of each monitoring dimension under different time-series context combinations.

[0165] The dynamic weight coefficients are obtained by iteratively training historical panel data through a pre-built time-series sensitivity analysis model. The time-series sensitivity analysis model adopts a long short-term memory network based on an attention mechanism, takes the historical normalized feature value sequence as input and the comprehensive monitoring index as a supervision signal, and iteratively updates the weight coefficients through backpropagation. After the weight coefficients are trained, they are written into the weight configuration contract of the blockchain after consensus, along with the version number and the effective block height.

[0166] After each acquisition cycle, the preprocessing node outputs the normalized feature value sequence, the temporal context identifier, and the version number of the current weight allocation matrix to the fusion computing node.

[0167] S3. Obtain the following data output by the preprocessing node: the normalized feature value sequence for the same monitored object, the corresponding time-series context identifier, and the corresponding weight allocation matrix version number. The fusion computing node associates data through a combination key of the monitored object identifier and the acquisition period identifier to ensure that the data of the same monitored object is correctly assigned in different acquisition periods.

[0168] Based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix, a weighted fusion is performed on the normalized feature values ​​of each monitoring dimension. Specifically, a fusion method of weighted summation followed by arithmetic mean is adopted, which requires that the sum of the dynamic weight coefficients of all monitoring dimensions under the same time-series context identifier equals one.

[0169] For the current collection period, the normalized feature value of each monitoring dimension is multiplied by its corresponding dynamic weight coefficient to obtain the weighted contribution value of each monitoring dimension. Then, the weighted contribution values ​​of all monitoring dimensions are summed to obtain the comprehensive monitoring index for this collection period. This index is a dimensionless value between zero and one.

[0170] The comprehensive monitoring index from multiple consecutive collection periods is arranged in chronological order to generate time-series data of the comprehensive monitoring index. The number of collection periods involved in the arrangement is determined by a preset sliding window length, which is a preset positive integer, such as five or seven collection periods.

[0171] The time-series data of the comprehensive monitoring index are input into a preset trend deviation detection model. The trend deviation detection model first performs a baseline threshold interval calculation.

[0172] Based on the growth stage category code of the monitored object, a list of object identifiers belonging to the same growth stage category is retrieved from the reference object registry stored on the blockchain. The reference object registry is written to the blockchain during system initialization and updated via a consensus mechanism when a new reference object is added.

[0173] Acquire the time-series data of the comprehensive monitoring index for each reference object within the most recent collection period of the specified sliding window length. For each time position within the sliding window, such as the first, second, and last positions, calculate the lower quartile and upper quartile of the comprehensive monitoring index for all reference objects at that time position. The lower quartile refers to the value at the 1 / 4 position after the data is sorted in ascending order, and the upper quartile refers to the value at the 3 / 4 position.

[0174] Then, the interquartile range is calculated, which is the difference between the upper quartile and the lower quartile. The lower limit of the baseline threshold interval for the current time position is set to the lower quartile minus 1.5 times the interquartile range, and the upper limit of the baseline threshold interval is the upper quartile plus 1.5 times the interquartile range. The aforementioned 1.5 times is a preset tolerance boundary coefficient used to distinguish between normal fluctuations and abnormal deviations.

[0175] For the comprehensive monitoring index of the current collection period, obtain the lower and upper limits of the benchmark threshold interval corresponding to the last time position within the sliding window.

[0176] The deviation direction determination logic is as follows: if the current comprehensive monitoring index is less than the lower limit of the benchmark threshold range, the deviation direction is determined to be negative; if the current comprehensive monitoring index is greater than the upper limit of the benchmark threshold range, the deviation direction is determined to be positive; if the current comprehensive monitoring index is greater than or equal to the lower limit of the benchmark threshold range and less than or equal to the upper limit of the benchmark threshold range, the deviation direction is determined to be no deviation.

[0177] After determining the direction of deviation, the anomaly level is determined. First, the deviation of the current comprehensive monitoring index from the baseline threshold range is calculated. The deviation is calculated as follows: first, the median value between the lower and upper limits of the threshold range is calculated (the sum of the lower and upper limits divided by two); then, the half-range width between the lower and upper limits of the threshold range is calculated (the difference between the upper and lower limits divided by two). Finally, the absolute value of the difference between the current comprehensive monitoring index and the median value is calculated, and this absolute value is divided by the half-range width to obtain the deviation value.

[0178] Based on the numerical range of the deviation, an anomaly level identifier is output according to a preset level classification rule. The specific classification rule includes:

[0179] When the deviation is less than 1, it is judged as level 0, and the semantics are normal;

[0180] When the deviation is greater than or equal to 1 and less than 2, it is judged as Level 1, and the semantic meaning is "attention".

[0181] When the deviation is greater than or equal to 2 and less than 3, it is judged as Level 2, and the semantic meaning is warning;

[0182] When the deviation is greater than or equal to 3, it is judged as level 3, which means an alarm.

[0183] When the deviation direction indicator is "no deviation", the corresponding anomaly level indicator is forcibly set to level 0, regardless of the calculated deviation magnitude.

[0184] The above calculations and judgments are then assembled into a complete monitoring result. This monitoring result includes the following seven fields:

[0185] The monitored object identifier is used to uniquely identify the currently monitored object;

[0186] Collection period identifier, used to identify the collection period to which the current data belongs;

[0187] The comprehensive monitoring index value is the comprehensive monitoring index calculated in the current data collection period;

[0188] The lower limit of the baseline threshold interval is the lower limit of the baseline threshold interval corresponding to the current collection period.

[0189] The upper limit of the baseline threshold range is the upper limit of the baseline threshold range corresponding to the current collection period.

[0190] Anomaly level identifier, with values ​​of level 0, level 1, level 2, or level 3;

[0191] The deviation direction indicator has values ​​of negative deviation, no deviation, or positive deviation.

[0192] The fusion computing node outputs the monitoring results to the feedback node.

[0193] S4. Concatenate all seven fields of the received monitoring result into a string in a fixed order, perform a hash operation on this string to generate a hash value for the monitoring result. To avoid naming confusion with the second hash value generated in the data acquisition node, the hash value generated by this node is named the second hash value.

[0194] Obtain the block height of the current block and determine the next block associated with it. Use the second hash value as the digital fingerprint of the current monitoring result and write it into a preset field in the block header of the next block. This preset field is specifically used to store the monitoring result hash value from the feedback node.

[0195] Simultaneously, a backward hash pointer is established in the block header of the next block, pointing to the block body hash of the current block. This backward hash pointer, together with the forward hash pointer established in the collection node, forms a complete bidirectional hash pointer verification chain. Specifically, the forward hash written by the collection node in the block header points to the block body hash of the previous block for backward verification; the backward hash pointer written by the feedback node in the next block header points to the block body hash of the current block for backward verification.

[0196] The system invokes a pre-defined smart contract for storing monitoring results. This smart contract has been pre-deployed in the blockchain network and exposes an interface method called "Write Monitoring Results".

[0197] When calling this interface, the following parameters are passed in: the monitored object identifier, the collection period identifier, the comprehensive monitoring index value, the lower limit of the benchmark threshold range, the upper limit of the benchmark threshold range, the anomaly level identifier, the deviation direction identifier, and the second hash value. After receiving the above parameters, the smart contract performs the following operations:

[0198] Verify whether the data type and value range of the input parameters conform to the preset rules;

[0199] Using the combination key of the monitored object identifier and the collection period identifier as the primary key, the monitoring results are written into the monitoring result data table in the distributed ledger;

[0200] At the same time, a hash pointer association is established from the monitoring result record to the block body where the original collected data is located. That is, the block body hash value of the block where the original collected data is located is stored in the monitoring result record, which is used to realize complete traceability verification from the monitoring result to the original collected data.

[0201] If the write operation is successful, the smart contract returns a confirmation flag indicating successful write; if the write operation fails, for example due to a primary key conflict or network anomaly, a write failure alarm is triggered, and the failure record is output to the management terminal.

[0202] The system reads the anomaly level and deviation direction indicators from the monitoring results and generates corresponding task generation instructions according to a preset task triggering rule table. This task triggering rule table is pre-stored in a blockchain configuration contract and updated via a consensus mechanism. Its mapping rules are as follows:

[0203] When the anomaly level is 0, no task generation command will be triggered regardless of the value of the deviation direction indicator.

[0204] When the anomaly level is identified as Level 1 and the deviation direction is identified as negative, a task generation instruction of type "mild concern" is triggered. The instruction content includes prompting managers to pay attention to the negative change trend of the monitored object.

[0205] When the anomaly level is identified as Level 1 and the deviation direction is identified as positive deviation, a task generation instruction of type "mild concern" is triggered. The instruction content includes prompting managers to pay attention to the positive change trend of the monitored object.

[0206] When the anomaly level is identified as Level 2 and the deviation direction is identified as negative deviation, a task generation instruction of type "on-site verification" is triggered. The instruction content includes requiring managers to conduct on-site data verification of the monitored object within a specified time limit.

[0207] When the anomaly level is identified as Level 2 and the deviation direction is identified as positive deviation, a task generation instruction of type "trend analysis" is triggered. The instruction includes a requirement for managers to analyze the sustainability and potential risks of the positive deviation.

[0208] When the anomaly level is identified as Level 3 and the deviation direction is identified as negative, a task generation instruction of type "emergency response" is triggered. The instruction includes a requirement for managers to immediately activate the emergency plan and intervene.

[0209] When the anomaly level is identified as Level 3 and the deviation direction is identified as positive deviation, a task generation instruction of type "urgent review" is triggered. The instruction requires managers to urgently review the authenticity of the data and assess the impact of excessive deviation.

[0210] The generated task generation instructions are assembled into a complete output message. The task generation instructions include the following fields: unique instruction identifier, instruction type (values ​​include mild concern, on-site verification, trend analysis, emergency handling, or emergency review), monitored object identifier, collection cycle identifier, anomaly level identifier, deviation direction identifier, comprehensive monitoring index value, upper and lower limits of the benchmark threshold range, instruction generation timestamp, and suggested response time limit.

[0211] The instruction is output using the corresponding transmission method, depending on the type of management terminal.

[0212] If the management terminal is a large monitoring screen, then commands are pushed to the front end of the screen via WebSocket;

[0213] If the management terminal is a mobile terminal, instructions are sent to the specified mobile application via push notification service;

[0214] If the management terminal is a PC client, the command data is returned via the HTTP interface;

[0215] If the management terminal is an SMS gateway or an email server, the command content is output through the corresponding SMS sending interface or email sending interface.

[0216] After the feedback node completes the above operations, the complete processing flow of the current collection cycle ends. When a subsequent collection cycle starts, the collection node will read the second hash value and backward hash pointer written by the feedback node from the block header of the previous block when generating a new block. This is used to verify whether the monitoring results of the previous collection cycle have been tampered with, thus forming a complete hash pointer verification closed loop from collection, preprocessing, fusion calculation to feedback and evidence storage.

[0217] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

[0218] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A data monitoring and processing system based on blockchain hash pointer verification, characterized in that, Includes a monitoring feedback chain; the monitoring feedback chain includes: The data collection node is configured to: acquire unstructured document data and corresponding object profile identifiers uploaded by the terminal of the monitored object, and generate structured panel data; perform a first hash operation on the structured panel data to generate a first hash value; determine the growth stage category to which the monitored object belongs based on the object profile identifier, and prune the set of fields to be filled to generate a dimensionality-reduced subset of data collection fields based on the field correlation threshold corresponding to the growth stage category; The preprocessing node is configured to: call the hash pointer stored in the block header to perform integrity verification on the structured panel data and generate a normalized feature value sequence; and retrieve a preset weight allocation matrix based on the time-series context identifier corresponding to the current acquisition cycle. The fusion computing node is configured to: perform weighted fusion on the normalized feature value sequence based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix to obtain the comprehensive monitoring index time-series data of the monitored object; input the comprehensive monitoring index time-series data into a preset trend deviation detection model, and output a monitoring result containing an anomaly level identifier and a deviation direction identifier based on the baseline threshold range defined by the comprehensive monitoring index distribution characteristics of reference objects under the same growth stage category.

2. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 1, characterized in that, in, The time-series context identifier is composed of a growth stage identifier and an operating environment stage identifier. The weight allocation matrix records the dynamic weight coefficients of each monitoring dimension under different time-series context combinations. The dynamic weight coefficients are obtained by iteratively training historical panel data through a pre-built time-series sensitivity analysis model, and are used to characterize the difference in the contribution of the same monitoring dimension to the comprehensive monitoring results under different growth stages and operating environment stages. The monitoring feedback chain also includes a feedback node configured to perform a hash operation on the monitoring result to generate a second hash value, and write the second hash value into the header of the next block associated with the current block.

3. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 2, characterized in that, The data acquisition node generates structured panel data, specifically configured as follows: Based on the object profile identifier, a corresponding structured data table template is matched from a preset template library. The template includes field names, data types, units, value ranges, and field correlation benchmark values. The semantic-rule hybrid parsing engine is invoked to extract key numerical fields from the unstructured document; The extracted key numerical fields are mapped to the structured data table template according to the field name to generate structured panel data, where unmatched template fields are filled with null value identifiers.

4. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 3, characterized in that, The acquisition node is also configured as follows: The generated first hash value is uniquely bound to the current collection period. The structured panel data and the first hash value are associated and stored in the block body of the current block in the form of key-value pairs. The key is a combination of the current collection period identifier and the identifier of the monitored object, and the value is the structured panel data and the first hash value. A second hash operation is performed on the subset of collected fields to generate a second hash value. The second hash value is written into the block header of the current block, and the first hash value is used as a forward hash pointer in the block header to point to the block body hash of the previous block, forming a chained hash verification structure.

5. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 4, characterized in that, The preprocessing node is also configured to: Obtain the structured panel data output by the acquisition node, and match at least one corresponding external data source from the preset external data source configuration table according to the growth stage category code in the object profile identifier; Using the timestamp of the first preset period configured by the acquisition node as the alignment reference, a time-series alignment operation is performed on the structured panel data and the external data source to generate an aligned multidimensional data matrix with the acquisition period timestamp as the primary key.

6. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 5, characterized in that, The preprocessing node performs integrity checks and is specifically configured as follows: Re-execute the first hash operation on the currently acquired structured panel data to generate a hash value to be verified; read the second hash value from the block header of the current block, and compare whether the hash value to be verified is consistent with the second hash value: If they match, the integrity check is considered successful; if they do not match, a data integrity error alarm is triggered, the current preprocessing process is stopped, and a check failure record containing the block identifier and the collection period identifier is output to the management terminal.

7. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 6, characterized in that, The fusion computing node is defined with a baseline threshold range, specifically configured as follows: Based on the growth stage category code of the monitored object, a list of object identifiers of all reference objects belonging to the same growth stage category is retrieved from the reference object registry stored on the blockchain. Obtain the time series data of the comprehensive monitoring index of each reference object within the most recent preset sliding window length of collection period, and calculate the lower quartile and upper quartile of the comprehensive monitoring index of all reference objects at each time position within the sliding window; Calculate the interquartile range (ICM), and based on the ICM and a preset tolerance boundary coefficient, define the baseline threshold interval corresponding to the current time position.

8. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 7, characterized in that, The trend deviation detection model is also configured as follows: Based on the relative position of the comprehensive monitoring index of the current collection period and the benchmark threshold range, the deviation direction determination logic is executed, and the corresponding deviation direction identifier is output. Calculate the deviation of the current comprehensive monitoring index from the benchmark threshold range, and output the abnormal level label according to the numerical range of the deviation and the preset level classification rules; when the deviation direction label is no deviation, the abnormal level label is forcibly set to the normal level.

9. The data monitoring and processing system based on blockchain hash pointer verification as described in claim 6, characterized in that, The feedback node is also configured as follows: The preset monitoring result storage smart contract is invoked to write the monitoring result and the corresponding second hash value into the distributed ledger, and an association is established between the monitoring result record and the hash pointer of the block where the original collected data is located. Read the anomaly level identifier and deviation direction identifier from the monitoring results, generate the corresponding task generation instruction according to the preset task triggering rule table, and output the task generation instruction to the management terminal according to the corresponding transmission method matched by the type of management terminal.

10. A data monitoring and processing method based on blockchain hash pointer verification, implemented based on the data monitoring and processing system based on blockchain hash pointer verification as described in any one of claims 1-9, characterized in that, include: Obtain unstructured document data uploaded by the monitored object's terminal and the corresponding object profile identifier, and generate structured panel data; Perform a first hash operation on the structured panel data to generate a first hash value; The growth stage category of the monitored object is determined based on the object profile identifier. Based on the field correlation threshold corresponding to the growth stage category, the set of fields to be filled is pruned to generate a dimensionality-reduced subset of the collected fields. The hash pointer stored in the block header is invoked to perform integrity verification on the structured panel data, generating a normalized feature value sequence; based on the time-series context identifier corresponding to the current acquisition cycle, the preset weight allocation matrix is ​​retrieved; Based on the dynamic weight coefficients corresponding to the current time-series context identifier in the weight allocation matrix, the normalized feature value sequence is weighted and fused to obtain the comprehensive monitoring index time-series data of the monitored object; The time series data of the comprehensive monitoring index is input into a preset trend deviation detection model. Based on the distribution characteristics of the comprehensive monitoring index of reference objects under the same growth stage category, a benchmark threshold range is defined, and the monitoring results containing anomaly level indicators and deviation direction indicators are output. A hash operation is performed on the monitoring result to generate a second hash value, and the second hash value is written into the header of the next block associated with the current block.

Images