Data management method, device and equipment

Abstract

The invention relates to the technical field of Internet of Things, and discloses a data management method, device and equipment, and the method comprises the steps: obtaining original multi-source data of each business, obtaining an encrypted data package based on an encrypted transmission channel and the original multi-source data, writing the encrypted data package into a distributed account book, obtaining a target evidence storage record, and storing the target evidence storage record in a database; and managing the original multi-source data based on the target evidence storage record and a digital twinning algorithm. According to the method, the data is written into the distributed account book and combined with the digital twinning algorithm, a'evidence storage-simulation-management and control 'closed-loop management system is formed, the requirement of the power industry for full-life-cycle supervision of the data is met, the characteristics of an encrypted transmission channel and the distributed account book are fused, and multi-dimensional protection of the data in the links of collection, storage and management is achieved.

Description

Technical Field

[0001] This application relates to the field of Internet of Things technology, and in particular to a data management method, device and equipment. Background Art

[0002] In the power industry, as the core hub of the energy system, power plants involve the coordinated operation of multiple subsystems such as boilers, steam turbines, generator sets, environmental protection equipment, and power grid dispatching during their operation, and need to collect a large amount of multi-source heterogeneous data such as temperature, pressure, vibration, and energy consumption in real time.

[0003] However, the existing technologies have significant defects: First, there are problems in the data acquisition layer such as large differences in equipment brands, inconsistent communication protocols, and blind spots in sensor network coverage, resulting in a common phenomenon of data islands and difficulty in integrating cross-system data; Second, data management lacks a credible guarantee mechanism. The traditional centralized storage architecture is vulnerable to single-point failures, and the encryption intensity during data transmission is insufficient, posing risks of tampering or leakage. In addition, the operation and maintenance decisions of power plants highly rely on historical data analysis, but the existing systems lack a full-life cycle record of data sources, processing processes, and operation traces, making it difficult to support fault backtracking and intelligent diagnosis. Summary of the Invention

[0004] The main purpose of this application is to provide a data management method, device and equipment, aiming to solve the technical problems of multi-source data islands and non-traceability caused by scattered data acquisition and lack of a credible management mechanism in the existing technologies.

[0005] To achieve the above object, this application proposes a data management method, and the method includes:

[0006] Obtain the original multi-source data of each service, and obtain an encrypted data packet based on the encrypted transmission channel and the original multi-source data;

[0007] Write the encrypted data packet into a distributed ledger to obtain a target deposit record;

[0008] Manage the original multi-source data based on the target deposit record and the digital twin algorithm.

[0009] In an embodiment, before the step of writing the encrypted data packet into the distributed ledger to generate a deposit record, it further includes:

[0010] Deploy consortium chain nodes through a blockchain algorithm, and divide the consortium chain nodes into core coordination nodes, regional processing nodes, and edge storage nodes;

[0011] On the core coordination node, perform consensus processing on the encrypted data packet through a consensus algorithm and quantum-secure communication to obtain a consensus processing result;

[0012] Verify the encrypted data packet based on the regional processing node to obtain a verification result;

[0013] Deploy a distributed storage cluster on the edge storage node in combination with a static encryption algorithm;

[0014] Generate a distributed ledger based on the consensus processing result, the verification result, and the distributed storage cluster.

[0015] In one embodiment, the step of generating a distributed ledger based on the consensus processing result, the verification result, and the distributed storage cluster includes:

[0016] Perform a non-linear combination of the consensus elements of the consensus processing result and the verification elements of the verification result based on a weighted fusion algorithm to obtain a composite verification tag, where the composite verification tag includes a device unique code and a time window;

[0017] Based on the composite verification tag, establish a multi-level mapping relationship between the encrypted data packet and the corresponding shard storage unit in the distributed storage cluster;

[0018] Generate a distributed ledger according to the consensus elements, the composite verification tag, and the multi-level mapping relationship.

[0019] In one embodiment, the step of establishing a multi-level mapping relationship between the encrypted data packet and the corresponding shard storage unit in the distributed storage cluster based on the composite verification tag includes:

[0020] Generate a spatio-temporal feature vector according to the device unique code and the time window;

[0021] Extract the key frequency domain features of the encrypted data packet through a wavelet transform function, and map the key frequency domain features to a dynamic perturbation factor by using a chaotic mapping algorithm;

[0022] Obtain a multi-level mapping relationship according to the spatio-temporal feature vector and the dynamic perturbation factor.

[0023] In one embodiment, the step of generating a distributed ledger according to the consensus elements, the composite verification tag, and the multi-level mapping relationship includes:

[0024] Package the consensus elements and the composite verification tag into a transaction unit, and verify the transaction unit through a signature algorithm to obtain a verified transaction unit;

[0025] Generate a transaction hash according to the verified transaction unit, and update the initial surface ledger based on the transaction hash to obtain an updated surface ledger;

[0026] Create a hash pointer chain through the transaction hash and the device unique code, and update the initial intermediate ledger based on the hash pointer chain to obtain an updated intermediate ledger;

[0027] Encrypt the encrypted data packet according to the time window and the device unique code to obtain a double-layer encrypted data packet, and update the initial bottom ledger based on the double-layer encrypted data packet to obtain an updated bottom ledger;

[0028] Generate a distributed ledger according to the updated top ledger, the updated intermediate ledger, the updated bottom ledger, and the multi-level mapping relationship.

[0029] In one embodiment, the step of obtaining the original multi-source data of each service and obtaining an encrypted data packet based on an encrypted transmission channel and the original multi-source data includes:

[0030] Collect the original multi-source data of each service based on the standardized interface of the blockchain light node according to a preset mapping rule;

[0031] Perform hash preprocessing and segmented encryption on the original multi-source data to obtain processed data;

[0032] Based on the encrypted transmission channel, encrypt the processed data through a national cryptography algorithm and a zero-knowledge proof algorithm to obtain an encrypted data packet.

[0033] In one embodiment, the step of writing the encrypted data packet into the distributed ledger to obtain a target certification record includes:

[0034] Write the encrypted data packet into the distributed ledger through a consistent hashing algorithm to generate a first certification record;

[0035] According to the multi-level mapping relationship, associate the first certification record with the encrypted data packet to obtain a structured associated evidence chain;

[0036] Based on the structured associated evidence chain, combine a signature algorithm and a hash pointer chain to generate an intermediate verification record of the distributed ledger, and obtain a second certification record based on the intermediate verification record;

[0037] Aggregate the first certification record and the second certification record through a zero-knowledge proof algorithm to generate a target certification record.

[0038] In one embodiment, the step of managing the original multi-source data based on the target certification record and a digital twin algorithm includes:

[0039] Establish a mapping relationship between the device unique code in the target certification record and the original multi-source data through a digital twin algorithm;

[0040] Construct a simulation scenario based on the mapping relationship, and obtain digital twin simulation results according to the simulation scenario;

[0041] If the digital twin simulation results deviate from the expected threshold, call the preset tags and historical operation logs in the target deposit record, and manage the original multi-source data in combination with the smart contract protocol.

[0042] In addition, to achieve the above object, the present application also proposes a data management device, and the data management device includes:

[0043] A data acquisition module, configured to acquire the original multi-source data of each service, and obtain an encrypted data packet based on the encrypted transmission channel and the original multi-source data;

[0044] A deposit acquisition module, configured to write the encrypted data packet into a distributed ledger to obtain a target deposit record;

[0045] A data management module, configured to manage the original multi-source data based on the target deposit record and the digital twin algorithm.

[0046] In addition, to achieve the above object, the present application also proposes a data management device, and the device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the data management method as described above.

[0047] In addition, to achieve the above object, the present application also proposes a storage medium, and the storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium, and when the computer program is executed by a processor, the steps of the data management method as described above are implemented.

[0048] In addition, to achieve the above object, the present application also provides a computer program product, and the computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the data management method as described above are implemented.

[0049] The technical solution proposed by the present application acquires the original multi-source data of each service, obtains an encrypted data packet based on the encrypted transmission channel and the original multi-source data, writes the encrypted data packet into a distributed ledger to obtain a target deposit record, and manages the original multi-source data based on the target deposit record and the digital twin algorithm. The present application combines writing data into a distributed ledger with a digital twin algorithm to form a "deposit - simulation - control" closed-loop management system, meets the requirements of the power industry for the full life cycle supervision of data, and integrates the characteristics of an encrypted transmission channel and a distributed ledger to achieve multi-dimensional protection of data in the acquisition, storage, and management links. Description of the Drawings

[0050] The accompanying drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with this application, and are used together with the specification to explain the principles of this application.

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or in the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0052] Figure 1 It is a schematic flowchart provided for the first embodiment of the data management method of this application;

[0053] Figure 2 It is a schematic flowchart provided for the second embodiment of the data management method of this application;

[0054] Figure 3 It is a schematic module structure diagram of the data management device in the embodiments of this application;

[0055] Figure 4 It is a schematic device structure diagram of the hardware operating environment involved in the data management method in the embodiments of this application.

[0056] The realization of the purpose, functional features and advantages of this application will be further described in combination with the embodiments with reference to the accompanying drawings. Specific Embodiments

[0057] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not used to limit this application.

[0058] To better understand the technical solutions of this application, the following will be described in detail in combination with the accompanying drawings of the specification and specific embodiments.

[0059] The prior art has significant defects: First, there are problems such as large differences in device brands, inconsistent communication protocols, and blind spots in sensor network coverage in the data acquisition layer, resulting in a common phenomenon of data islands and difficulty in integrating cross-system data; Second, data management lacks a credible guarantee mechanism. The traditional centralized storage architecture is vulnerable to single-point failures, and the encryption intensity during data transmission is insufficient, posing risks of tampering or leakage. In addition, the operation and maintenance decisions of power plants highly rely on historical data analysis, but the existing systems lack a full-life cycle record of data sources, processing processes, and operation traces, making it difficult to support fault backtracking and intelligent diagnosis.

[0060] Therefore, to overcome the above-mentioned deficiencies, the present application provides a solution. By combining writing data into a distributed ledger with a digital twin algorithm, a closed-loop management system of "evidence storage - simulation - control" is formed to meet the power industry's requirements for the full life cycle supervision of data, integrating the characteristics of an encrypted transmission channel and a distributed ledger to achieve multi-dimensional protection of data in the collection, storage, and management links.

[0061] It should be noted that the execution subject of each embodiment of the present application can be a computing service system with data processing, network communication, and program running functions, such as an electronic system, a data management system, etc. that can implement the above functions. Hereinafter, taking a data management system as an example (hereinafter referred to as "system"), the following embodiments will be described.

[0062] Based on this, an embodiment of the present application provides a data management method, referring to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the data management method of the present application.

[0063] In this embodiment, the data management method includes steps S10 to S30:

[0064] Step S10, obtaining the original multi-source data of each service, and obtaining an encrypted data packet based on the encrypted transmission channel and the original multi-source data.

[0065] In an industrial scenario, especially in the power generation field, multi-source data (such as equipment operation parameters, energy dispatch instructions, environmental monitoring data, etc.) is usually scattered in heterogeneous systems, and is vulnerable to network latency, protocol differences, and security risks during the collection process. To solve the data island problem and meet the requirements of trusted management, the present application proposes a data processing mechanism that combines standardized access and end-to-end encryption, aiming to achieve cross-system data integration through a unified interface, and combining encrypted transmission technology to ensure the confidentiality and integrity of data during the collection stage.

[0066] Specifically, the original multi-source data can be collected from each business system, uniformly accessed and preprocessed through a standardized interface. Hash calculation is performed on the original data to solidify the integrity, and then segmented encryption is performed as needed. The processed data is encrypted at the underlying layer using a national cryptography algorithm, and an unreadable encryption proof is generated in combination with a zero-knowledge proof algorithm. Finally, it is encapsulated into an independent encrypted data packet through an encrypted transmission channel (such as the national cryptography SSL / TLS protocol) to ensure the confidentiality, integrity, and non-repudiation of the data during the transmission process.

[0067] It should be noted that the data management method of this application introduces the dynamic rotation key technology in the data encryption link, and realizes periodic or event-triggered key updates through the built-in key management module. Specifically, the system generates a new temporary key according to a preset policy (such as automatically rotating at 0:00 every day or when the single data encryption volume reaches the threshold), and replaces the original key to encrypt sensitive fields (such as device unique encoding, time window). The key generation process combines the quantum random number source and the national cipher algorithm (such as SM4) to ensure the unpredictability of the key. The old and new keys are synchronized to the authorized nodes through a two-way encryption channel, and the old key immediately becomes invalid and is physically erased. This mechanism effectively resists the risk of long-term key leakage, meets the dynamic encryption requirements of relevant policies for critical information infrastructure, and is compatible with lightweight verification technologies such as zero-knowledge proof, balancing security and performance overhead.

[0068] As an implementation manner, step S10 in this embodiment may include: collecting the original multi-source data of each service based on the standardized interface of the blockchain light node; performing hash preprocessing and segmented encryption on the original multi-source data to obtain processed data; based on the encrypted transmission channel, encrypting the processed data through the national cipher algorithm and the zero-knowledge proof algorithm to obtain an encrypted data packet.

[0069] Specifically, based on the standardized interface of the blockchain light node (such as following the remote procedure call transfer protocol), the original multi-source data is collected from each business system according to the preset mapping rule. The preset mapping rule defines the conversion logic of data fields, the format unified standard, and the cross-system data association method, ensuring that data from different sources can be structurally integrated. For example, by calling the RESTful API or database query statement of each business system through the standardized interface of the light node, the required data fields are screened as needed and the format is cleaned, and finally an original data set that conforms to the unified data model is generated.

[0070] Perform hash preprocessing on the integrated original multi-source data, solidify the integrity of the data by calculating the hash value of a fixed length (such as SHA-256), and generate the corresponding hash digest. Subsequently, according to the data sensitivity level and transmission efficiency requirements, the segmented encryption technology (such as AES-256 block encryption) is used to divide the original data into multiple encrypted segments, and each segment is independently encrypted to improve the parallel processing ability and fault tolerance. The processed data includes the original data segment, the hash digest, and the segmented key meta-information, forming a structured data unit.

[0071] Submit the processed data to the target node through a pre-established encrypted transmission channel. During the transmission process, first, apply the national cryptographic algorithm (such as the SM4 symmetric encryption algorithm) to encrypt the entire data unit at the underlying layer to ensure the confidentiality and anti-interception ability of the data on the transmission link; secondly, generate a verifiable proof of the encrypted data based on the zero-knowledge proof algorithm (such as zk-SNARKs), which can verify the legality of the data without revealing the specific content. Finally, combine the national cryptographic encrypted data packet with the zero-knowledge proof and encapsulate it into a complete encrypted data packet to complete the end-to-end secure transmission and non-repudiation guarantee.

[0072] Step S20: Write the encrypted data packet into the distributed ledger to obtain the target evidence record.

[0073] It should be understood that the encrypted data packet can be written into the distributed ledger to generate an initial evidence record. Determine the storage location through the consistent hashing algorithm, and establish the association between the evidence record and the data packet based on the multi-level mapping relationship (such as the device unique code and the time window) to form a structured evidence chain. Generate an intermediate layer verification record using the signature algorithm and the hash pointer chain, and aggregate the initial evidence record and the intermediate layer record through the zero-knowledge proof algorithm to generate the final target evidence record.

[0074] Therefore, as an implementation manner, step S20 in this embodiment may include: writing the encrypted data packet into the distributed ledger through the consistent hashing algorithm to generate the first evidence record; associating the first evidence record with the encrypted data packet according to the multi-level mapping relationship to obtain a structured association evidence chain; based on the structured association evidence chain, combining the signature algorithm and the hash pointer chain to generate an intermediate layer verification record of the distributed ledger, and obtaining a second evidence record based on the intermediate layer verification record; aggregating the first evidence record and the second evidence record through the zero-knowledge proof algorithm to generate the target evidence record.

[0075] It can be understood that writing the encrypted data packet through the consistent hashing algorithm generates the first evidence record. Based on the consistent hashing algorithm (such as CHASH or Rabin-Karp variant), map the hash value of the encrypted data packet to the set of storage nodes in the distributed ledger. The algorithm distributes data through the circular hash space, dynamically adjusts the data distribution according to the node weights, and ensures data redundancy and load balancing. When writing, each node checks whether it is the responsible node according to the hash value. If so, store the data packet locally and generate a digital fingerprint containing the timestamp, node identifier, and hash value to form the first evidence record. This record solidifies the storage location and writing time of the data packet, serving as the basic anchor point for subsequent verification.

[0076] Construct a multi-level index (such as a B+ tree or hash table) based on the device unique encoding and time window, and associate the hash fingerprint in the first evidence record with the storage path of the encrypted data packet. For example, the device unique encoding serves as the first-level key, the time window divides the second-level key, and a composite index key is generated through non-linear combination. During the mapping process, the system verifies the consistency between the spatio-temporal characteristics (such as the generation time range) of the data packet and the evidence record, and writes the association relationship into the distributed index layer to form a structured association evidence chain. This chain connects the evidence record and the original data packet through a traceable pointer mechanism (such as a doubly linked list) to ensure full-link auditability.

[0077] Perform signature processing on the structured association evidence chain. That is, first generate a digital signature for the evidence chain content (including the evidence record hash, mapping relationship, and device encoding) through the private key, and use the public key to verify the signature validity to ensure the identity of the prover. Secondly, extract the hash values of each node in the evidence chain, and construct an intermediate layer verification record through a chained hash pointer (such as SHA-256 concatenation). This record contains the signature result, hash pointer tree, and timestamp, forming an immutable logical chain for proving the legal association between the evidence record and the data packet.

[0078] Input the first evidence record (including data packet storage information) and the second evidence record (verification result of the association evidence chain) into a zero-knowledge proof generator. Use algorithms such as zk-SNARKs to construct a circuit, encode the authenticity conditions of the evidence record as arithmetic constraints, and generate a proof and verification key that meet the conditions. The final target evidence record consists of the original evidence data, proof, and verification key, which can not only verify the logical consistency between the data packet and the evidence record but also avoid exposing the details of the underlying business data, achieving high-level privacy protection and verifiability.

[0079] Step S30, manage the original multi-source data based on the target evidence record and the digital twin algorithm.

[0080] It should be understood that the device unique encoding is extracted from the target evidence record and dynamically bound to the original multi-source data through the digital twin algorithm. A simulation scenario is constructed based on the mapping relationship, simulating the business operation status and generating results for data management.

[0081] As an implementation, step S30 in this embodiment may include: establishing a mapping relationship between the device unique encoding in the target evidence record and the original multi-source data through the digital twin algorithm; constructing a simulation scenario based on the mapping relationship, and obtaining a digital twin simulation result according to the simulation scenario; if the digital twin simulation result deviates from the expected threshold, then call the preset tags and historical operation logs in the target evidence record, and manage the original multi-source data in combination with the smart contract protocol.

[0082] Specifically, extract the device unique code (such as identifiers like IMEI, serial number, etc.) from the target evidence record, and call the metadata corresponding to this code (such as device type, attribute definition) through the standardized interface of the digital twin engine. Based on the field mapping rules in the metadata (such as the timestamp field corresponding to the time window of the data packet), logically bind the physical parameters (such as temperature, pressure value) in the original multi-source data with the virtual parameters of the digital twin model. For example, if the device code is associated with sensor data, map the real-time readings in the original data to the simulation variables in the twin model to form a dynamic data flow channel.

[0083] Initialize the digital twin simulation environment based on the mapping relationship, load the historical operation data as the initial state, and set the simulation parameters (such as time span, physical law constraints). Drive the model to run through a discrete event simulation or a real-time stream processing engine to simulate the actual operation process of the device or business. During the simulation process, the twin model continuously receives incremental updates of the original multi-source data and outputs simulation results containing key performance indicators (such as predicted failure probability, energy consumption curve). The simulation results are stored in the form of structured data, accompanied by timestamps and confidence level tags.

[0084] When the specified indicators in the simulation results (such as temperature exceeding the safety threshold) deviate from the preset threshold, the system automatically queries the preset tags (such as device risk level, emergency strategy ID) in the target evidence record and the historical operation logs (such as the latest maintenance record, fault work order). Call the predefined management rules through an intelligent contract protocol (such as the Ethereum Solidity contract): if the tag marks the device as high-risk, perform a data isolation operation; if the historical log shows that a similar fault has been repaired, trigger an automatic verification process. After the management action is completed, feedback the operation record to the digital twin model to update the simulation parameters, forming a closed-loop control.

[0085] This embodiment obtains the original multi-source data of each business, obtains encrypted data packets based on the encrypted transmission channel and the original multi-source data, writes the encrypted data packets into the distributed ledger to obtain the target evidence record, and manages the original multi-source data based on the target evidence record and the digital twin algorithm. By combining writing data into the distributed ledger with the digital twin algorithm, a closed-loop management system of "evidence storage - simulation - control" is formed, meeting the requirements of the power industry for the full life cycle supervision of data, integrating the characteristics of the encrypted transmission channel and the distributed ledger, and realizing multi-dimensional protection of data in the acquisition, storage, and management links.

[0086] Based on the first embodiment of the present application, in the second embodiment of the present application, for the same or similar content as in the above-mentioned first embodiment, reference can be made to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 2 , before the step S10, the steps S01 to S05 may further be included:

[0087] Step S01, deploy consortium chain nodes through the blockchain algorithm, and divide the consortium chain nodes into core coordination nodes, regional processing nodes, and edge storage nodes.

[0088] Construct a consortium chain network architecture through the blockchain algorithm, and divide the nodes into three categories according to their functions: core coordination nodes, regional processing nodes, and edge storage nodes. The core coordination node serves as the network control center, responsible for global consensus scheduling and cross-regional communication; the regional processing node is based on geographical or business partitions and undertakes the responsibilities of local data verification and transaction processing; the edge storage node deploys a distributed storage cluster through a static encryption algorithm, stores encrypted data packets nearby, and ensures offline availability. Encrypted channels are established between nodes through a quantum-secure communication protocol (such as Post-Quantum Key Exchange, PQKE) to ensure the confidentiality and anti-attack ability of node interactions.

[0089] Step S02, on the core coordination node, perform consensus processing on the encrypted data packet through the consensus algorithm and quantum-secure communication to obtain the consensus processing result.

[0090] Run a consensus algorithm (such as the Byzantine Fault Tolerance (BFT) algorithm or the improved PBFT) on the core coordination node, and combine the quantum-secure communication module to perform consensus processing on the encrypted data packet. The specific process includes: the node collects data packets to be consensus, generates dynamic weights through a quantum random number generator, and determines the consensus result based on the weight voting mechanism; quantum-secure communication ensures the immutability of the voting process and prevents malicious nodes from forging voting information. The finally generated consensus processing result includes the data packet validity mark, the signatures of consensus nodes, and the time stamp, forming a legally binding collective authentication certificate.

[0091] Step S03, verify the encrypted data packet based on the regional processing node to obtain the verification result.

[0092] The regional processing node receives the encrypted data packet broadcast by the core coordination node and performs dual verification: first, verify the legality of the data packet source through the device fingerprint library (such as whether the device unique code is registered in the white list); second, use a lightweight blockchain verification engine (such as the SPV protocol) to check the hash consistency between the data packet and the existing deposit records. The verification result includes the device status identifier (such as "valid" or "doubtful"), the verification time window, and the regional node signature, forming a traceable distributed verification evidence chain.

[0093] Step S04, on the edge storage node, deploy a distributed storage cluster in combination with the static encryption algorithm.

[0094] Deploy a static encryption algorithm (such as AES-256-CBC) on edge storage nodes to build a distributed storage cluster, split the encrypted data packets into multiple shards. Each shard is redundantly stored on different nodes using erasure coding technology (such as Reed-Solomon), and at the same time, the shard key is bound to the unique device code. The storage cluster achieves load balancing through a consistent hashing ring, and nodes regularly synchronize the storage status hash value to detect data anomalies. When receiving an evidence storage request, the cluster automatically triggers the data retrieval process, reconstructs the original data packet based on the shard key, and returns the integrity verification value to the verification layer.

[0095] Step S05, generate a distributed ledger based on the consensus processing result, the verification result, and the distributed storage cluster.

[0096] This embodiment adapts to the performance requirements of large-scale data processing in power plants by constructing a three-level node hierarchical architecture, that is, it is proposed to perform consensus processing through core coordination nodes, verification through regional processing nodes, and distributed storage through edge storage nodes, forming a consortium chain deployment mode.

[0097] As an implementation manner, step S05 in this embodiment may include:

[0098] Perform a non-linear combination of the consensus elements of the consensus processing result and the verification elements of the verification result based on a weighted fusion algorithm to obtain a composite verification tag, where the composite verification tag includes the unique device code and the time window;

[0099] Based on the composite verification tag, establish a multi-level mapping relationship between the encrypted data packet and the corresponding shard storage unit in the distributed storage cluster;

[0100] Generate a distributed ledger according to the consensus elements, the composite verification tag, and the multi-level mapping relationship.

[0101] It can be understood that based on the summary information of the consensus processing result (such as data packet hash value, consensus node signature) and the parameters of the verification result (such as device fingerprint, regional verification timestamp), a sensitivity coefficient (reflecting the importance degree of data types, such as key business data is given a weight of 0.7), node credibility (based on historical behavior statistics, the weight of a trusted node is 0.8 - 0.9, and that of an untrusted node is 0.5 - 0.6), and a time decay factor (the weight decays exponentially over time, and the formula is e^(-λt), where λ is the decay rate) are introduced. Calculate the composite weight through a non-linear combination formula (such as W = α×S + β×C + γ×D, where S is the sensitivity coefficient, C is the node credibility, and D is the time decay factor) to generate a composite verification tag containing the unique device code and the time window. This tag solidifies the weight allocation logic through a hash function (such as SM3) to ensure the traceability of the verification process.

[0102] Using the device unique encoding in the composite verification tag as the primary index, invoking the sharding strategy (such as the consistent hashing ring) of the distributed storage cluster to map the encrypted data packets to the corresponding sharded storage units; calculating the time hash value (such as HMAC - SHA256) based on the time window field, generating the secondary index and binding it to the life cycle of the storage unit. Allocating the composite weight to the multi - level index through a non - linear function (such as polynomial interpolation) to establish a multi - level mapping relationship from the device encoding to the storage unit. For example, highly sensitive data (weight ≥ 0.8) is mapped to the core storage nodes with high redundancy, and low - sensitive data (weight < 0.5) is stored in the edge nodes. At the same time, data with a shorter time window (such as TTL ≤ 1 hour) is preferentially allocated to the low - latency partition.

[0103] Input the consensus elements (abstract information, parameters), the composite verification tag (including the dynamic weight), and the multi - level mapping relationship into the distributed ledger generation engine. Encapsulate the transaction unit through a chained structure: write the hash values of the original consensus elements and the composite verification tag in the first layer, append the logical expression (such as the mapping tree structure) of the multi - level mapping relationship in the second layer, and store the binding of the device unique encoding and the physical address of the storage unit in the bottom layer. Use the smart contract to automatically execute the weight verification rule (such as the total weight threshold ≥ 0.9 to take effect), and generate a proof that meets the weight constraint through the zero - knowledge proof algorithm. The final ledger records all logical links in a nested structure (such as JSON - LD) to ensure that each layer of verification can be independently traced and cannot be tampered with.

[0104] Further, the step of establishing a multi - level mapping relationship between the encrypted data packet and the corresponding sharded storage unit in the distributed storage cluster based on the composite verification tag may include: generating a spatio - temporal feature vector according to the device unique encoding and the time window; extracting the key frequency - domain features of the encrypted data packet through a wavelet transform function, and mapping the key frequency - domain features to a dynamic perturbation factor using a chaotic mapping algorithm; obtaining the multi - level mapping relationship according to the spatio - temporal feature vector and the dynamic perturbation factor.

[0105] It should be understood that based on the device unique encoding (such as IMEI, serial number) and the time window (such as the data generation time range), the two are mapped into a multi - dimensional spatio - temporal feature vector through an encoding function. Specifically, the device unique encoding is converted into a unique identifier with a fixed length through a hash function, and the time window is decomposed into a start timestamp and a duration. The two are non - linearly combined according to the weights (such as the device encoding accounting for 70% and the time accounting for 30%) to generate a continuous vector containing spatial (device identity) and temporal (data timeliness) information. This vector characterizes the spatio - temporal distribution characteristics of the data and is used for the dynamic allocation of subsequent storage locations.

[0106] Apply the discrete wavelet transform to the original binary stream of the encrypted data packet. Decompose the signal by selecting a specific wavelet basis function (such as Daubechies-4) to extract the high-frequency components (reflecting the mutation characteristics of the data) and the low-frequency components (reflecting the overall trend). Focus on the key frequency-domain features (such as the energy concentration region or the abnormal fluctuation frequency band), calculate the energy values of each frequency band as feature parameters, and quantify the complexity of the features through the entropy function. This process transforms the encrypted data packet from the time domain to the frequency domain, revealing hidden patterns or abnormal behaviors.

[0107] Input the extracted key frequency-domain features into the chaotic mapping algorithm (such as the Logistic mapping iterative formula: x_{n+1} = rx_n(1 - x_n)). By adjusting the parameters r and the initial condition x_0, generate a sequence of dynamic perturbation factors with chaotic characteristics. This sequence introduces non-linear perturbations, breaks the determinacy of the traditional hash allocation, and enhances the randomness and anti-predictability of the storage path. Finally, the spatio-temporal feature vector and the dynamic perturbation factors form a composite index through non-linear superposition (such as polynomial fusion) and are mapped to the shard units of the distributed storage cluster. Shards with high chaos intensity are assigned to sensitive data to improve security, and shards with low intensity are used for ordinary data to optimize storage efficiency.

[0108] The step of generating the distributed ledger according to the consensus elements, the composite verification mark, and the multi-level mapping relationship includes: packing the consensus elements and the composite verification mark into a transaction unit, and verifying the transaction unit through a signature algorithm to obtain a verified transaction unit; generating a transaction hash according to the verified transaction unit, and updating the initial surface ledger based on the transaction hash to obtain an updated surface ledger; creating a hash pointer chain through the transaction hash and the device unique encoding, and updating the initial middle ledger based on the hash pointer chain to obtain an updated middle ledger; encrypting the encrypted data packet according to the time window and the device unique encoding to obtain a double-layer encrypted data packet, and updating the initial bottom ledger based on the double-layer encrypted data packet to obtain an updated bottom ledger; generating a distributed ledger according to the updated surface ledger, the updated middle ledger, the updated bottom ledger, and the multi-level mapping relationship.

[0109] It is understandable that consensus elements (such as summary information, parameters) and composite verification tags (including device unique encoding, time window) are encapsulated into a standardized transaction unit (such as a JSON structure). The content of the transaction unit is digitally signed through a signature algorithm: first, the hash value of the transaction content is generated, and then the hash value is signed with the private key to form a signature field appended to the end of the transaction unit. During verification, the public key is called to verify the validity of the signature to ensure the credibility of the transaction initiator's identity and data integrity. Then, based on the verified transaction unit, a unique transaction hash value is generated through a hash function (such as RIPEMD-160). This hash value is combined with the timestamp and node identifier and written into the block header of the initial surface ledger. The surface ledger is maintained in a chain structure, and each new block contains a hash pointer to the previous block, forming an immutable sequential record. During update, the state of the surface ledger of each node is synchronized through a consensus algorithm (such as Raft) to ensure that the ledger versions stored by all participating parties are consistent.

[0110] Then, the transaction hash value and the device unique encoding are extracted, and a hierarchical relationship is constructed through the hash pointer chain technology: the current transaction hash is used as the parent pointer and linked to the historical transaction records corresponding to the device unique encoding (such as a tree structure). The intermediate ledger stores these pointer chains and associated composite verification tags. During update, a distributed consensus protocol (such as Paxos) is used to ensure the consensus of all regional processing nodes on the pointer chain. If the verification fails, the data rollback mechanism is triggered to ensure logical consistency.

[0111] According to the time window (such as data validity period) and the device unique encoding, the original encrypted data packet is encrypted twice: the outer layer is encrypted with AES-256 using a dynamic key (a temporary key generated based on the time window), and the inner layer is encrypted with a device-bound key generated by combining the national cryptographic algorithm with the device unique encoding. The generated double-layer encrypted data packet is stored in the distributed cluster of edge storage nodes. The underlying ledger records the encryption algorithm parameters, key versions, and data packet storage paths, and is maintained in a Merkle tree structure. The data integrity can be quickly verified through the root hash value.

[0112] The updated surface ledger (including transaction order), intermediate ledger (including pointer chain and verification logic), and underlying ledger (storing physical data packets) are integrated, combined with a multi-level mapping relationship (such as device encoding - storage node - shard location). A logical closed-loop is established through cross-layer hash verification (such as the surface hash pointing to the intermediate layer pointer chain, and the intermediate layer pointer chain associating with the underlying data packet hash). The final ledger is presented in a nested structure (such as a Bloom Filter index), supporting efficient query and auditing, and at the same time hiding sensitive operation details through zero-knowledge proof technology.

[0113] For the sake of easy understanding, an example scenario of power plant boiler status monitoring and trusted management is used for illustration. In a thermal power plant, as a core device, the operating parameters of the boiler (such as steam temperature, pressure, vibration frequency) need to be collected in real time and analyzed collaboratively with data from multiple systems such as power grid dispatching and environmental supervision. Suppose there is the following scenario:

[0114] Multi-source data integration: The vibration sensors of the boiler (SCADA system), thermal parameters (DCS system), and environmental monitoring data (independent Internet of Things platform) need to be collected across protocols (Modbus TCP / IP, OPC UA). Through the standardized interface of the blockchain light node, the unique device code (such as "BOILER-001") is mapped to each data field, and after unifying the format, the original data is pre-hashed, and encrypted in segments to generate encrypted data packets containing a time window (such as from 20:00:00 to 20:05:00 on March 9, 2025), and transmitted to the management platform through the national secret SSL / TLS channel. For example, vibration data is collected at a sampling frequency of 1000 samples per second, encrypted in segments by AES-256, and encapsulated into a data packet of 5MB in size, with a timestamp and device code attached as metadata.

[0115] Distributed evidence storage: The encrypted data packets are written into the distributed ledger through the consortium chain nodes. The core coordination node verifies the integrity of the data packets based on the PBFT consensus algorithm, the regional processing node compares the device fingerprint (such as the check value of "BOILER-001") to confirm the legitimacy of the source, and the edge storage node stores the data in slices in the static encryption cluster. For example, the data packet is sliced into 3 redundant storages by the SM4 algorithm, each with a size of about 1.6MB, and stored in the storage nodes in North China, East China, and South China regions respectively. Finally, an evidence storage record containing the device code, time window, and consensus signature is generated, anchored to the hash pointer chain of the blockchain to ensure that the data is immutable and traceable. If subsequent audits need to verify the authenticity of vibration data during a certain period, the original data packet and the node signatures participating in the consensus can be quickly located through the hash pointer chain of the evidence storage record.

[0116] Digital twin-driven management: Based on the device code in the evidence storage record, the digital twin platform constructs a virtual model of the boiler and injects the decrypted parameters in real time (such as abnormal vibration amplitude). If the simulation results show that the vibration exceeds the threshold (deviating from the historical baseline by 15%), the system automatically calls the preset tags (such as "high-risk working condition") and historical operation logs (such as the recent maintenance records) in the evidence storage record, triggers the execution of the smart contract instruction: restricts the boiler load and pushes a maintenance work order, and at the same time updates the evidence storage record to solidify the disposal measures. For example, the digital twin simulation can predict the future 2-hour decline trend of thermal efficiency, generate optimization suggestions in combination with the historical energy efficiency data stored in the evidence, and guide fuel adjustment or equipment maintenance to avoid the average daily economic loss caused by unplanned shutdowns exceeding 500,000 yuan.

[0117] This embodiment proposes a three - level mapping mechanism of "physical layer - logic layer - encryption layer" based on composite verification tags. By extracting the frequency - domain features of encrypted data packets through wavelet transform and then generating dynamic perturbation factors using the chaotic mapping algorithm, dynamic adaptive adjustment of data sharding is achieved. The three - layer digital ledger update mechanism includes a hierarchical update strategy for the proposed surface ledger (transaction hash), intermediate - layer ledger (hash pointer chain), and bottom - layer ledger (double - layer encrypted data packets), meeting the evidence - storage requirements of different business scenarios. Double - layer encrypted data packets are generated based on a time window and a unique device code, and the application of national cryptographic algorithms is innovatively extended to dynamic data scenarios.

[0118] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data management method of this application. Based on this technical concept, more forms of simple transformations are within the protection scope of this application.

[0119] This application also provides a data management device. Please refer to Figure 3 , and the data management device includes:

[0120] A data acquisition module 10, configured to acquire the original multi - source data of each service and obtain encrypted data packets based on an encrypted transmission channel and the original multi - source data;

[0121] An evidence - storage acquisition module 20, configured to write the encrypted data packets into a distributed ledger to obtain target evidence - storage records;

[0122] A data management module 30, configured to manage the original multi - source data based on the target evidence - storage records and digital twin algorithms.

[0123] The data management device provided by this application adopts the data management method in the above - mentioned embodiment, and can solve the technical problems of multi - source data islands and non - traceability caused by scattered data collection and lack of a trusted management mechanism in the prior art. Compared with the prior art, the beneficial effects of the data management device provided by this application are the same as those of the data management method provided by the above - mentioned embodiment, and other technical features in the data management device are the same as those disclosed in the method of the above - mentioned embodiment, which will not be elaborated here.

[0124] This application provides a data management device. The data management device includes: at least one processor; and a memory communicatively connected to at least one processor; wherein, the memory stores instructions executable by at least one processor, and the instructions are executed by at least one processor so that at least one processor can execute the data management method in the first embodiment above.

[0125] Next, refer to Figure 4, which shows a schematic structural diagram of a data management device suitable for implementing the embodiments of the present application. The data management device in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Desction), PMPs (Portable Media Player), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 4 The shown data management device is merely an example and should not impose any limitation on the functions and usage scope of the embodiments of the present application.

[0126] As Figure 4 shown, the data management device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which may perform various appropriate actions and processes according to the program stored in the read-only memory 1002 or the program loaded from the storage device 1003 into the random access memory 1004. In the random access memory 1004, various programs and data required for the operation of the data management device are also stored. The processing device 1001, the read-only memory 1002, and the random access memory 1004 are connected to each other through a bus 1005. The input / output interface 1006 is also connected to the bus. Generally, the following systems may be connected to the input / output interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the data management device to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a data management device with various systems, it should be understood that it is not required to implement or have all the shown systems. Instead, more or fewer systems may be implemented or had.

[0127] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium. The computer program contains program codes for executing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a read-only memory 1002. When the computer program is executed by a processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are executed.

[0128] The data management device provided by the present application adopts the data management method in the above-mentioned embodiment, and can solve the technical problems of multi-source data islands and non-traceability caused by scattered data collection and lack of a reliable management mechanism in the prior art. Compared with the prior art, the beneficial effects of the data management device provided by the present application are the same as those of the data management method provided by the above-mentioned embodiment, and other technical features in the data management device are the same as those disclosed in the method of the previous embodiment, and will not be elaborated here.

[0129] It should be understood that each part disclosed in the present application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in a suitable manner in any one or more embodiments or examples.

[0130] As mentioned above, the above is only the specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application, and all should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0131] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the data management method in the above-mentioned embodiment.

[0132] The computer-readable storage medium provided by this application can be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium can be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0133] The above computer-readable storage medium can be included in a data management device; it can also exist separately without being assembled into the data management device.

[0134] The above computer-readable storage medium carries one or more programs. When the above one or more programs are executed by a data management device, the data management device is caused to: obtain the original multi-source data of each service, obtain an encrypted data packet based on the encrypted transmission channel and the original multi-source data, write the encrypted data packet into a distributed ledger, obtain a target deposit record, and manage the original multi-source data based on the target deposit record and the digital twin algorithm.

[0135] Computer program code for performing the operations of the present application can be written in one or more programming languages or combinations thereof. The above-mentioned programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0136] The readable storage medium provided by the present application is a computer-readable storage medium. The computer-readable storage medium stores computer-readable program instructions (i.e., computer programs) for performing the above-mentioned data management method, and can solve the technical problems of multi-source data islands and non-traceability caused by scattered data collection and lack of a reliable management mechanism in the prior art. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as those of the data management method provided by the above-mentioned embodiments, and will not be elaborated here.

[0137] The present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the data management method as described above are implemented.

[0138] The computer program product provided by the present application can solve the technical problems of multi-source data islands and non-traceability caused by scattered data collection and lack of a reliable management mechanism in the prior art. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the data management method provided by the above-mentioned embodiments, and will not be elaborated here.

[0139] The above is only part of the embodiments of the present application, and does not limit the patent scope of the present application. All equivalent structural transformations made under the technical concept of the present application by using the content of the specification and drawings of the present application, or directly / indirectly applied in other related technical fields, are included in the patent protection scope of the present application.

Claims

1. A data management method, characterized in that: The method comprises the following steps: Acquire original multi-source data of each service, and obtain an encrypted data packet based on the encrypted transmission channel and the original multi-source data; Writing the encrypted data packet into a distributed ledger to obtain a target evidence record; Based on the target evidence records and digital twin algorithm, the original multi-source data is managed.

2. The data management method according to claim 1, characterized in that: Before the step of writing the encrypted data packet into the distributed ledger to generate a proof record, the method further includes: Deploy alliance chain nodes through blockchain algorithms, and divide the alliance chain nodes into core coordination nodes, regional processing nodes, and edge storage nodes; On the core coordination node, consensus processing is performed on the encrypted data packet through a consensus algorithm and quantum secure communication to obtain a consensus processing result; Verifying the encrypted data packet based on the regional processing node to obtain a verification result; On the edge storage node, a distributed storage cluster is deployed in combination with a static encryption algorithm; A distributed ledger is generated according to the consensus processing result, the verification result and the distributed storage cluster.

3. The data management method according to claim 2, characterized in that: The step of generating a distributed ledger according to the consensus processing result, the verification result and the distributed storage cluster includes: Based on a weighted fusion algorithm, consensus elements of the consensus processing result and verification elements of the verification result are nonlinearly combined to obtain a composite verification mark, wherein the composite verification mark includes a unique device code and a time window; Based on the composite verification mark, a multi-level mapping relationship is established between the encrypted data packet and the corresponding shard storage unit in the distributed storage cluster; A distributed ledger is generated according to the consensus elements, the composite verification mark, and the multi-level mapping relationship.

4. The data management method according to claim 3, characterized in that: The step of establishing a multi-level mapping relationship between the encrypted data packet and the corresponding shard storage unit in the distributed storage cluster based on the composite verification mark includes: Generate a spatiotemporal feature vector according to the device unique code and the time window; Extracting key frequency domain features of the encrypted data packet through a wavelet transform function, and mapping the key frequency domain features into dynamic disturbance factors using a chaotic mapping algorithm; A multi-level mapping relationship is obtained according to the spatiotemporal feature vector and the dynamic disturbance factor.

5. The data management method according to claim 3, characterized in that: The step of generating a distributed ledger according to the consensus elements, the composite verification mark and the multi-level mapping relationship includes: Packing the consensus elements and the composite verification mark into a transaction unit, and verifying the transaction unit through a signature algorithm to obtain a verified transaction unit; Generate a transaction hash according to the verified transaction unit, and update the initial surface ledger based on the transaction hash to obtain an updated surface ledger; Creating a hash pointer chain through the transaction hash and the device unique code, and updating the initial middle-layer ledger based on the hash pointer chain to obtain an updated middle-layer ledger; Encrypting the encrypted data packet according to the time window and the unique code of the device to obtain a double-layer encrypted data packet, and updating the initial underlying ledger based on the double-layer encrypted data packet to obtain an updated underlying ledger; A distributed ledger is generated according to the updated surface ledger, the updated middle-layer ledger, the updated bottom-layer ledger, and the multi-level mapping relationship.

6. The data management method according to any one of claims 1 to 5, characterized in that: The step of acquiring the original multi-source data of each service and obtaining an encrypted data packet based on the encrypted transmission channel and the original multi-source data includes: Based on the standardized interface of blockchain light nodes, the original multi-source data of each business is collected according to the preset mapping rules; Performing hash preprocessing and segment encryption on the original multi-source data to obtain processed data; Based on the encrypted transmission channel, the processed data is encrypted by the national secret algorithm and the zero-knowledge proof algorithm to obtain an encrypted data packet.

7. The data management method according to any one of claims 1 to 5, characterized in that: The step of writing the encrypted data packet into a distributed ledger to obtain a target evidence record includes: Writing the encrypted data packet into a distributed ledger using a consistent hashing algorithm to generate a first evidence record; According to the multi-level mapping relationship, the first evidence record is associated with the encrypted data packet to obtain a structured associated evidence chain; Based on the structured associated evidence chain, a middle-layer verification record of the distributed ledger is generated in combination with a signature algorithm and a hash pointer chain, and a second evidence record is obtained based on the middle-layer verification record; The first evidence record and the second evidence record are aggregated through a zero-knowledge proof algorithm to generate a target evidence record.

8. The data management method according to any one of claims 1 to 5, characterized in that: The step of managing the original multi-source data based on the target evidence record and the digital twin algorithm includes: Establishing a mapping relationship between the unique device code in the target evidence record and the original multi-source data through a digital twin algorithm; Constructing a simulation scenario based on the mapping relationship, and obtaining a digital twin simulation result according to the simulation scenario; If the digital twin simulation result deviates from the expected threshold, the preset tags and historical operation logs in the target evidence record are called, and the original multi-source data is managed in combination with the smart contract protocol.

9. A data management device, characterized in that: The data management device comprises: A data acquisition module, used to acquire original multi-source data of each business, and obtain an encrypted data packet based on the encrypted transmission channel and the original multi-source data; A certificate acquisition module, used to write the encrypted data packet into a distributed ledger to obtain a target certificate record; A data management module is used to manage the original multi-source data based on the target evidence record and the digital twin algorithm.

10. A data management device, characterized in that: The data management device comprises: a memory, a processor, and a data management program stored in the memory and executable on the processor, wherein the data management program implements the data management method according to any one of claims 1 to 8 when executed by the processor.

Images