Blockchain and did-based metering data credible management method and system, electronic equipment and storage medium

Abstract

The application provides a metering data credible management method and system based on a blockchain and a DID, an electronic device, and a storage medium. The method comprises the following steps: creating device profile information of a smart meter; creating a unique decentralized identifier for the smart meter based on a blockchain; binding and verifying the device profile information and the decentralized identifier based on the blockchain; storing metering data signed by the smart meter in a preset structured format as a data ledger, and automatically verifying and maintaining the credibility status of the metering data in the data ledger; batch aggregating and multi-chain notarizing and locking the metering data in the data ledger based on a preset time window; in response to a user request, generating on-chain credible data information of the metering data, generating structured evidence information according to the on-chain credible data information, and outputting verified structured evidence information.

Description

Technical Field

[0001] This application relates to the technical field of trusted management of metrological data, and more specifically, to a method, system, electronic device, and storage medium for trusted management of metrological data based on blockchain and DID. Background Technology

[0002] Measurement data management refers to the process of collecting, processing, storing, analyzing, and applying carbon emission-related data in the production and consumption stages. Its core objective is to achieve accurate quantification and reliable traceability of carbon emissions. Driven by both the "dual carbon" strategic goals and international green trade barriers, measurement data has evolved from an internal energy management tool for enterprises to a critical infrastructure supporting carbon market trading, cross-border carbon tariff declarations, green financial product pricing, and government regulatory decisions. Its authenticity, real-time nature, and traceability directly affect the fair pricing power of carbon assets, the international competitiveness of exported products, and the credibility of the national carbon emission accounting system.

[0003] However, the inventors of this application have discovered the following technical problems in the existing metering data management system regarding the reliability of the data source and the identity binding mechanism. At the metering level, traditional solutions generally adopt a static accounting model that multiplies the "fixed emission factor" by the total electricity consumption. This fails to reflect the spatiotemporal differences in the power system caused by dynamic factors such as fluctuations in renewable energy output, leading to "different carbon emissions for the same electricity," resulting in systemic metering bias. Simultaneously, data collection relies heavily on manual entry or centralized system storage, posing risks of data lag, human intervention, and single points of failure. Regarding identity reliability, terminal devices such as smart metering instruments lack decentralized digital identity identifiers. After data is uploaded, a strong cryptographic binding relationship cannot be established with the source device. Once centralized records are tampered with or management authority is out of control, the authenticity of the data source cannot be self-verified, causing the complete traceability chain to break at its starting point.

[0004] Furthermore, the lack of unified technical standards for identity authentication systems and data formats across different institutions and regions restricts the flow of metrological data to closed, vertical systems, hindering reliable interaction and sharing across entities and borders, resulting in a severe data silo effect. Current data preservation methods rely on centralized evidence storage or third-party notary offices as trusted intermediaries, leading to low efficiency and difficulties in obtaining, verifying, and accepting evidence in judicial practice. This results in metrological data lacking the technically valid self-verification capability to withstand international trade carbon tariff reviews and financial regulatory audits, severely restricting the global circulation and compliant declaration of carbon assets.

[0005] The content in the background section is merely technology known to the public and does not necessarily represent existing technology in this field. Summary of the Invention

[0006] This application provides a method, system, electronic device, and storage medium for trusted management of metering data based on blockchain and DID, aiming to solve at least one of the technical problems mentioned in the background art.

[0007] According to one aspect of this application, a method for trusted management of metering data based on blockchain and DID is provided, comprising: creating equipment file information for smart metering instruments; creating a unique decentralized identity identifier for the smart metering instrument based on blockchain; binding and verifying the equipment file information and the decentralized identity identifier based on blockchain; storing the metering data digitally signed by the smart metering instrument in a preset structured format as a data ledger, and automatically verifying the signature and maintaining the trusted status of the metering data in the data ledger; batch aggregating and multi-chain storing and locking the metering data in the data ledger based on a preset time window; and generating on-chain trusted data information of the metering data in response to user requests, generating structured evidence information based on the on-chain trusted data information, and outputting the verified structured evidence information.

[0008] According to another aspect of this application, a trusted management system for metering data based on blockchain and DID is provided, including an equipment center module, a DID registration module, a binding verification module, a data ledger management module, a batch aggregation and locking module, and an evidence information processing module. The equipment center module creates equipment file information for smart metering instruments. The DID registration module creates a unique decentralized identity identifier for each smart metering instrument based on the blockchain. The binding verification module binds and verifies the equipment file information and the decentralized identity identifier based on the blockchain. The data ledger management module stores the metering data digitally signed by the smart metering instrument in a preset structured format as a data ledger, and automatically verifies the signatures and maintains the trusted status of the metering data in the data ledger. The batch aggregation and locking module performs batch aggregation and multi-chain evidence storage locking of the metering data in the data ledger based on a preset time window. The evidence information processing module responds to user requests, generates on-chain trusted data information of the metering data, generates structured evidence information based on the on-chain trusted data information, and outputs the verified structured evidence information.

[0009] According to another aspect of this application, an electronic device is also provided. The electronic device includes: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the one or more processors to perform the methods described above.

[0010] According to another aspect of this application, a non-volatile computer-readable storage medium is also provided. This storage medium stores a computer program that, when executed by a processor, can perform the methods described above.

[0011] According to another aspect of this application, this application also provides a computer program product. The computer program product includes: a computer program stored on a computer-readable storage medium; the computer program includes program instructions that, when executed by a computer, cause the computer to perform the methods described above.

[0012] Beneficial effects This application creates equipment file information for smart meters, combines it with a unique decentralized identity identifier created based on blockchain, and binds and verifies the equipment file with the identity identifier through blockchain. This achieves cryptographic anchoring of the equipment's physical and digital identities, establishing an immutable identity authentication foundation from the source of data generation. Furthermore, the metering data, digitally signed by the equipment, is stored in a structured format as a data ledger. Through automatic signature verification and maintenance of a trusted state, the authenticity and integrity of the data in the storage process can be ensured.

[0013] This application also significantly reduces the cost of evidence storage by batch aggregating ledger data according to preset time windows and locking it across multiple chains. This mechanism of locking massive amounts of data on a single blockchain significantly reduces the cost of evidence storage, while multi-chain evidence storage enhances the legal validity and redundancy reliability of the evidence. Subsequently, in response to user requests, trusted on-chain data information and structured evidence information are generated, and verified evidence is output, forming a complete closed loop from data collection and storage to verification output.

[0014] This application constructs a complete trusted data management chain from source-based trusted anchoring, process-based trusted storage, efficient on-chain evidence storage to compliant evidence output. It can effectively solve the technical problems of traditional solutions in terms of data source credibility, evidence storage cost and legal effect, and can provide an end-to-end technical trust infrastructure for carbon market trading, cross-border carbon tariff compliance and financial supervision. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating the reliable management method for measurement data according to an embodiment of this application is shown. Figure 2 This diagram illustrates yet another flowchart of the metrological data reliability management method according to an embodiment of this application; Figure 3 This diagram illustrates yet another flowchart of the metrological data reliability management method according to an embodiment of this application; Figure 4This diagram illustrates the structure of a reliable metering data management system according to an embodiment of this application.

[0017] Explanation of reference numerals in the attached figures: Device Center Module 10; DID Registration Module 20; Binding Verification Module 30; Data Ledger Management Module 40; Batch Aggregation and Locking Module 50; Evidence Information Processing Module 60; Key Management Module 70. Detailed Implementation

[0018] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0019] The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of these specific details, or other methods, components, materials, devices, etc. In these cases, well-known structures, methods, devices, implementations, materials, or operations will not be shown or described in detail.

[0020] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0021] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order.

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

[0023] The inventors of this application have discovered that current methods for storing and trading measurement data mainly suffer from the following technical problems.

[0024] Centralized evidence storage solutions suffer from the following technical problems in terms of data security, trust mechanisms, and judicial validity: Data is centrally stored in a centralized database, posing a risk of internal or external tampering, and lacks cryptographic means to prove its integrity. System security relies entirely on the platform's credibility; if the platform malfunctions, is attacked, or goes bankrupt, the stored data faces the risk of loss or invalidation. Electronic evidence is difficult to prove its authenticity and creation time, the evidence collection process is cumbersome, and judicial acceptance is difficult, making centralized evidence storage unsuitable for meeting the trusted management requirements of high-value data scenarios.

[0025] Blockchain-based evidence storage also faces significant limitations in its technical implementation. The core issue is that while blockchain can guarantee the immutability of data after it's uploaded, it cannot verify the authenticity of data before it's uploaded. This means the fundamental contradiction of "garbage in, garbage out" remains unresolved, and the "presumption of truth" rule does not apply to data uploaded before judicial review. Furthermore, blockchain consensus mechanisms are inefficient in handling high-concurrency requests, leading to transaction delays and resource waste. The storage and verification of massive amounts of data further exacerbates performance bottlenecks. Additionally, encryption algorithms may contain vulnerabilities, and theoretical risks such as 51% attacks always exist, posing potential security threats. Moreover, the lack of standardization in the evidence collection procedures of third-party evidence storage platforms has raised questions about their impartiality and neutrality in judicial practice.

[0026] Furthermore, the execution logic of smart contracts heavily relies on off-chain data provided by oracles. If an oracle is attacked, provides false data, or malfunctions, the contract will automatically execute under incorrect input, potentially leading to erroneous asset transfers or malicious exploitation of the contract logic, resulting in direct economic losses. In addition, the smart contract code itself may contain design flaws or implementation vulnerabilities, which attackers can exploit through carefully crafted transactions or data inputs. Moreover, the system lacks an effective verification mechanism for the authenticity and timeliness of data returned by oracles.

[0027] At the level of law and technology integration, the supporting mechanisms for this integration are still imperfect, and the rules for acceptance and the allocation of the burden of proof need to be clarified. Different courts have inconsistent standards for recognizing blockchain evidence, leading to either an over-reliance on platform endorsement or a refusal to accept it in practice. The legal requirements for electronic data vary significantly across countries, posing significant challenges to cross-border compliance. These uncertainties further amplify the practical impact of technological deficiencies such as source data distortion and centralized single-point risks.

[0028] According to one aspect of this application, this application provides a method for trusted management of metering data based on blockchain and DID. For example... Figure 1 As shown, the reliable management method for measurement data may include steps S100-S600.

[0029] According to the example embodiment, the metrological data trust management method can be executed by a metrological data trust management system (hereinafter referred to as the trust management system) with computing capabilities.

[0030] According to the example embodiment, in step S100, the trusted management system creates device profile information for the smart metering instrument.

[0031] For example, when a smart meter leaves the factory or is installed and put into use, the trusted management system creates a device profile for the device and records the corresponding device profile information. Device profile information includes, but is not limited to, device model, device serial number (i.e., device physical ID), installation location, company identifier, commissioning date, and operating status (including online, offline, normal operation, and abnormal alarms). Device profile information can be stored in a relational database and synchronized to consortium blockchain nodes, ensuring the immutability and cross-node consistency of the device profile information, providing a basic entry point for achieving a strong binding between "device—identity—data".

[0032] The trusted management system can maintain a communication connection with the smart metering instrument through a communication network, and periodically receive the operating status information reported by the device, thereby enabling real-time monitoring of the device's online / offline status, normal operation / abnormal alarm status, and other working statuses.

[0033] The trusted management system can also maintain a one-to-one mapping between the physical ID and DID identifier of smart meters, store this mapping in a relational database and synchronize it to the consortium blockchain nodes, so as to quickly locate the digital identity of the device in subsequent data collection, on-chain evidence storage and traceability verification. When the device file information or mapping relationship changes, the trusted management system can update the file records accordingly and record the change operation in the audit log.

[0034] The trusted management system can also record all key IDs and their validity periods used in the history of smart meters. Each time a device completes a key rotation, it records the key ID, activation time, expiration time, and current status, and stores it in association with the device's physical ID. This supports verification and traceability of historical data at any point in time. This setup provides a trusted device identity foundation for subsequent data collection, signature storage, batch locking, and evidence generation, ensuring an immutable device identity authentication chain is established from the source of data generation.

[0035] It can be understood here that intelligent metering instruments are metering devices that integrate microelectronics technology, computer technology, communication technology, and modern sensor technology, and can automatically complete the acquisition, processing, storage, and remote transmission of metering data.

[0036] The smart metering instruments in this application include, but are not limited to, smart energy meters, smart carbon meters, smart water meters, smart gas meters, and smart heat meters, etc., and this application does not limit them.

[0037] In step S200, the trusted management system creates a unique decentralized identity identifier for the smart metering instrument based on the blockchain.

[0038] For example, when a smart meter leaves the factory, its built-in ESAM security chip generates an asymmetric key pair based on the SM2 national cryptographic algorithm. Based on the public key, a DID identifier conforming to the W3C DID Core specification is derived, in the format did:emc:unique identifier. This DID identifier is then submitted to the metering consortium blockchain node for registration. The trusted management system maintains a DIDDocument corresponding to each DID. This DID Document contains public key information (supporting SM2 public keys and future PQC public key extensions), server endpoint, timestamp, and signature algorithm identifier, etc. Uploading the DID Document to the blockchain for evidence storage allows for global resolution.

[0039] The trusted management system also deploys a resolution service that conforms to the W3C DID Resolution specification. It can receive DID resolution requests from external systems (including regulatory agencies, carbon exchanges, financial institutions, and third-party verification agencies), retrieve the corresponding DID Document from the blockchain or cache, and return it. It supports standard formats such as JSON-LD, thus providing a standardized authentication interface for external systems.

[0040] This setup can endow smart meters with a decentralized digital identity that has cryptographic self-verification capabilities, thereby providing a foundation of identity trust for subsequent data signature verification and cross-domain mutual recognition.

[0041] In step S300, the trusted management system binds and verifies device profile information and decentralized identity identifiers based on the blockchain.

[0042] For example, the trusted management system cryptographically binds the device file information (such as the device physical ID) of the smart meter with the DID digital identity, generates a binding certificate containing the association between the device physical ID and the DID, and submits it to the blockchain for storage after being digitally signed by the trusted management system and the device itself, thereby forming an immutable on-chain binding record.

[0043] The trusted management system can also provide binding verification services. By verifying the binding records stored on the blockchain, the validity of digital signatures, and the certificate status, it can confirm whether the binding relationship between the device physical ID and the DID combination is valid. This ensures that the association between the "device physical entity" and the "DID digital identity" is immutable and verifiable, providing cryptographic security for the source trust of subsequent data.

[0044] In step S400, the trusted management system stores the metering data that has been digitally signed by the smart metering instrument in a preset structured format as a data ledger, and automatically verifies the signature and maintains the trusted status of the metering data in the data ledger.

[0045] For example, the data ledger is the core storage and management module of the trusted management system, which can be used to support the storage, retrieval, and trusted verification of metering data. Each metering data record can contain at least the following fields: record_id, as a globally unique record identifier; device_id, the physical ID of the smart meter; did, the decentralized identity identifier corresponding to the smart meter; key_id, the key ID used for signing; electricity data, including forward and reverse electricity carbon emissions; carbon data, the carbon emission value calculated by the difference method; timestamp, recording the data collection time; digital signature, the SM2 signature of the data by the smart meter's private key; and quality tag, used to identify the data quality level.

[0046] The trusted management system can organize the aforementioned fields according to a preset structured format and store them in a data ledger, forming searchable and verifiable measurement data records. Furthermore, the trusted management system automatically performs digital signature verification on each piece of data, confirming the validity of the signature and its match with the DID public key. The trusted management system also supports uploading quality data and quality description attachments. Simultaneously, the trusted management system can mark the trusted status of each piece of data, including pending verification, verified, evidence storage completed, and evidence storage verified, to reflect the progress of the data in the traceability chain.

[0047] In step S500, the trusted management system performs batch aggregation and multi-chain evidence locking of the measurement data in the data ledger based on a preset time window.

[0048] For example, a trusted management system can aggregate multiple data records into a batch according to a preset time window (such as hourly, daily, weekly, or monthly), generate a hash value for each measurement data in the batch and build a hash tree, and submit the generated root hash to the blockchain for evidence storage in order to obtain an on-chain evidence storage receipt.

[0049] The trusted management system can lock all data records within a batch through a single on-chain notarization, thereby reducing the cost of putting each unit of data on-chain. External verifiers can query the hash path of a record within the corresponding batch using the data record identifier to verify whether specific data belongs to the locked batch.

[0050] Optionally, the trusted management system can also submit the root hash of the same batch to multiple blockchains simultaneously for evidence storage and locking, and obtain evidence storage receipts from each blockchain to enhance the legal validity and redundancy reliability of the evidence storage.

[0051] The trusted management system can also generate batch proof files for each batch, including batch information, hash tree structure, chain receipts, and timestamps, for third parties to download and verify. This setup reduces the transaction frequency of blockchain-based evidence storage through batch aggregation and enhances the legal validity and redundancy reliability of the evidence through multi-chain locking, providing efficient, low-cost, and legally valid on-chain evidence storage for massive amounts of metrological data.

[0052] In step S600, the trusted management system responds to the user request by generating on-chain trusted data information of the metering data, generating structured evidence information based on the on-chain trusted data information, and outputting the verified structured evidence information.

[0053] For example, the trusted management system can generate on-chain trusted data information of measurement data (such as relevant trusted material information extracted from the equipment center module, DID registration module, binding verification module, data ledger management module, batch aggregation and locking module and evidence information processing module) based on user requests (such as export companies applying for carbon emission compliance certificates), and package it into structured evidence information.

[0054] For example, a complete set of structured evidence information packages includes at least the following: a data list, i.e., the original metering record digitally signed by the smart metering instrument; a DID document and parsing response, used to prove the authenticity of the data source; key materials, including the public key and key status proof; Merkel proof, i.e., proof of the data's path in the batch; blockchain receipt, i.e., blockchain storage information of the batch-locked transactions; and a quality report, i.e., data quality verification and metering calibration proof.

[0055] The trusted management system assembles the aforementioned material information into an evidence package file according to a preset structured format, ensuring cryptographic correlation and consistency among the various material information within the evidence package. This setup provides structured evidence packages with complete chains of evidence for scenarios such as carbon market trading, cross-border compliance reporting, and judicial evidence presentation, enabling trusted on-chain data to be transformed into compliant evidence that can be issued externally.

[0056] Through the above embodiments, this application creates equipment file information for smart metering instruments, combines it with a unique decentralized identity identifier created based on blockchain, and binds and verifies the equipment file with the identity identifier through blockchain. This achieves cryptographic anchoring of the physical and digital identities of the equipment, establishing an immutable identity authentication foundation from the source of data generation. Furthermore, the metering data digitally signed by the equipment is stored in a structured format as a data ledger, and through automatic signature verification and maintenance of a trusted state, the authenticity and integrity of the data in the storage process can be ensured.

[0057] This application also significantly reduces the cost of evidence storage by batch aggregating ledger data according to preset time windows and locking it across multiple chains. This mechanism of locking massive amounts of data on a single blockchain significantly reduces the cost of evidence storage, while multi-chain evidence storage enhances the legal validity and redundancy reliability of the evidence. Subsequently, in response to user requests, trusted on-chain data information and structured evidence information are generated, and verified evidence is output, forming a complete closed loop from data collection and storage to verification output.

[0058] This application constructs a complete trusted data management chain from source-based trusted anchoring, process-based trusted storage, efficient on-chain evidence storage to compliant evidence output. It can effectively solve the technical problems of traditional solutions in terms of data source credibility, evidence storage cost and legal effect, and can provide an end-to-end technical trust infrastructure for carbon market trading, cross-border carbon tariff compliance and financial supervision.

[0059] Optionally, such as Figure 2 As shown, step S300 may also include steps S310-S340.

[0060] In step S310, the trusted management system determines the binding information based on the device profile information and the decentralized identity identifier.

[0061] For example, the trusted management system generates binding information containing the device physical ID, DID identifier, public key, and timestamp based on the device profile information (including the device physical ID), DID identifier, and corresponding public key. This binding information is used for subsequent signature authentication between the trusted management system and the smart metering instrument.

[0062] For example, the binding information can be {device_id, did, public_key, timestamp}. device_id is the device physical ID, did is the DID identifier, public_key is the public key, and timestamp is the timestamp.

[0063] In step S320, the trusted management system digitally signs the binding information and generates binding credential information.

[0064] For example, during the initialization phase, the trusted management system uses the system platform's private key to digitally sign the binding information, generating binding credential information. This binding credential information can serve as an authorization statement from the trusted management system for the binding relationship of the smart meter, indicating that the trusted management system has reviewed and approved the binding relationship between the device's physical ID and digital identity (DID).

[0065] In step S330, the trusted management system digitally signs the binding information using a smart metering instrument to generate binding signature information.

[0066] For example, a trusted management system instructs a smart meter to use the private key of its ESAM security chip to digitally sign the binding information, generating binding signature information. This binding signature information can serve as proof of the device's identity, indicating that the smart meter actively confirms and acknowledges the binding relationship between its physical ID and digital identity (DID), constituting an authorization statement on the device side.

[0067] In step S340, the trusted management system uploads the binding credential information and binding signature information to the blockchain for evidence storage.

[0068] For example, the trusted management system merges the binding credential information (including the trusted platform signature) and the binding signature information (including the device signature) and submits them to the consortium blockchain for evidence storage. The consortium blockchain nodes verify and confirm the merged binding record through the consensus mechanism, write the binding record into a block, and form an immutable on-chain evidence storage record.

[0069] Through the above embodiments, this application achieves secure binding of a device's physical and digital identities via a collaborative mechanism of dual signatures and on-chain notarization. The trusted management system uses its platform private key to sign the binding information and generate binding credentials, enabling the trusted platform to authorize and endorse the binding relationship. Simultaneously, the smart meter uses its ESAM private key to sign the same binding information and generate binding signature information, allowing the device to confirm and claim its own identity.

[0070] Both parties confirm the same binding relationship from two independent dimensions: a trusted platform and a device. Neither party can complete the binding independently, effectively preventing unauthorized binding or forgery of the binding relationship. After the dual signatures are merged and submitted to the consortium blockchain for notarization, the blockchain's consensus mechanism and chained storage ensure that the binding record is tamper-proof and traceable. Therefore, this application can establish a strong cryptographic link between the "device physical entity—DID digital identity—collected data" at the source of data generation, providing an immutable trust anchor for subsequent data collection, notarization verification, and evidence issuance.

[0071] Optionally, such as Figure 2 As shown, step S300 may also include step S350.

[0072] In step S350, in response to a user request, the trusted management system verifies the validity of the binding relationship between the device profile information provided by the user and the decentralized identity identifier based on a preset interface.

[0073] For example, a trusted management system can provide a binding verification API interface to receive verification requests submitted by external systems. These requests must at least include the device's physical ID and DID identifier (e.g., (device_id, did)). The trusted management system queries the on-chain binding record based on this combination, verifying the validity of the platform signature in the binding certificate and confirming the authenticity and validity of the trusted platform's authorization endorsement of the binding relationship. The trusted management system can also verify the validity of the binding signature information, confirming the authenticity and validity of the device's self-declaration of the binding relationship. Furthermore, the trusted management system can verify the existence and tamper-proofing of the on-chain binding record, confirming whether the binding relationship has been solidified through blockchain consensus. If all verifications pass, the trusted management system determines that the device's physical ID and DID combination given by the user has a valid binding relationship. If any verification fails, the binding relationship is deemed invalid, and the corresponding failure reason is returned.

[0074] Through the above embodiments, this application can ensure that the binding relationship between the physical identity and digital identity of a device can be independently verified by a third party, which can provide a reliable identity verification basis for subsequent data traceability and cross-domain mutual recognition.

[0075] Optionally, the trusted management system performs lifecycle state management on the keys of smart metering instruments.

[0076] For example, a trusted management system can define a complete key state machine. Key states include: active, indicating that the key is in normal use; expiring, indicating that the key is about to expire and triggers a pre-rotation reminder; expired, indicating that the key has expired and no longer accepts new signatures; frozen, indicating temporary freezing for security incident response; revoked, indicating that it has been revoked and the key has been added to the certificate revocation list; and rotated, indicating that rotation has been completed and the old key is retained for historical signature verification and tracing.

[0077] The trusted management system can implement a key rotation mechanism: when a smart meter's key expires or a security event triggers rotation, the device generates a new key pair. The new public key, after being reviewed by the trusted management system, is updated to the on-chain DID Document. The old key is marked as expired or rotated, but is retained for historical data verification and traceability. The trusted management system can also implement a key freezing and revocation mechanism: when a device is suspected of being attacked or its key has been leaked, the regulator remotely initiates a key freezing or revocation operation, updating the key status to the on-chain DID Document and synchronizing it to all relevant nodes. Furthermore, all key status change operations are recorded in the audit log.

[0078] Through the above embodiments, this application can ensure the verifiability of digital signatures and the overall security of the system at different time scales through the key lifecycle state management mechanism, thereby supporting the consistency maintenance of key state among devices, platforms and blockchains.

[0079] Optionally, in step S400, the trusted management system marks the trusted status of each measurement data in the data ledger.

[0080] For example, each measurement data point is marked with a trustworthiness status in the data ledger. This trustworthiness status reflects the current progress of the measurement data in the traceability chain. Trustworthiness status includes at least four types: pending verification, indicating that the measurement data has been written to the data ledger but has not yet undergone digital signature verification; verified, indicating that the measurement data has completed digital signature verification and the signature is valid; evidence storage completed, indicating that the batch containing the measurement data has completed on-chain evidence storage locking; and evidence storage verified, indicating that the on-chain evidence storage information of the data has been verified and is consistent with the ledger record. This setup provides a clear indication of the progress status of the data ledger in the traceability chain, offering intuitive data trustworthiness indicators for system operators, regulatory agencies, and data users.

[0081] Optionally, in step S400, the trusted management system associates and stores data ledgers with data quality description information to assist in verifying the trustworthiness of the measurement data.

[0082] For example, a trusted management system can support the uploading of supporting materials such as data quality verification reports and metrological calibration certificates (i.e., data quality description information). These supporting materials can be linked and stored with the corresponding data ledger records, serving as supporting evidence for data quality labeling. When third-party verification agencies or regulators have doubts about data quality, they can review the linked quality description attachments to verify the data's metrological calibration status and quality verification records, thereby helping to determine whether the data possesses a credible quality basis. This setup, linking data quality description information with the data ledger, can provide auxiliary verification of the credible status of metrological data, enhancing the evidentiary integrity of data in judicial review and cross-border compliance scenarios.

[0083] Optionally, in step S400, the trusted management system verifies the digital signature of each metering data to confirm the trusted status of the metering data.

[0084] For example, a data ledger stores metering data signed with the private key of a smart meter. Each data record contains a digital signature field and a DID identifier corresponding to the device. The trusted management system reads the digital signature and DID identifier from the ledger, obtains the corresponding public key information through a DID resolution service, and uses this public key to verify the digital signature, confirming its validity and match with the DID public key. If verification passes, the trusted management system updates the data's trusted status to verified, indicating that the data was indeed generated by the claimed device at the corresponding time and has not been tampered with. If verification fails, the trusted management system marks the data as abnormal and triggers the corresponding alarm mechanism. This setup enables automatic verification of the authenticity of each metering data in the data ledger, ensuring the trustworthiness of the data source from a cryptographic perspective.

[0085] Optionally, such as Figure 3 As shown, step S500 may also include steps S510-S520.

[0086] In step S510, the trusted management system aggregates multiple measurement data in the data ledger into a batch based on a preset time window, calculates the hash value of each measurement data in the batch, and constructs a Merkle tree to generate the Merkle tree root hash.

[0087] For example, the trusted management system aggregates multiple metering records falling within a preset time window (including hourly, daily, weekly, or monthly) into a batch. The trusted management system then performs a hash calculation on each metering data in the batch to obtain the hash value of the leaf node corresponding to each data record.

[0088] Subsequently, the trusted management system combines the hash values ​​of each leaf node pairwise according to the Merkle tree construction rules, recursively generating the hash value of the upper-level parent node, and finally generating a unique Merkle tree root hash, recording the number of leaf nodes in this batch. The trusted management system uses the generated Merkle tree root hash as the unique digital fingerprint of the batch of data for subsequent on-chain evidence storage and locking operations. This setup can aggregate scattered individual data records into batches and generate a unique root hash that can be used for evidence storage, providing a data foundation for efficient on-chain evidence storage in batches.

[0089] In step S520, the trusted management system submits the batch of Merkel root hashes to multiple blockchains for evidence storage and generates blockchain receipts.

[0090] For example, the trusted management system constructs a Merkle root hash as a notarized transaction, submits it to the consortium blockchain node, and generates a blockchain receipt after confirmation by blockchain consensus. This receipt can contain information such as transaction ID, block height, and timestamp. With this setup, a single on-chain notarization can lock all data records within a batch, eliminating the need to upload each data record to the blockchain individually, thus greatly reducing the notarization cost per unit of data.

[0091] Optionally, the trusted management system also supports simultaneously submitting Merkel root hashes of the same batch to multiple blockchains for evidence storage and locking, such as the State Grid Chain, Chang'an Chain, and Judicial Chain, and obtaining evidence storage receipts from the corresponding blockchains. With this setup, this application uses a multi-chain locking mechanism to simultaneously solidify evidence of the same batch of data on multiple blockchains. Even if one chain fails or is attacked, the evidence stored on other chains can still serve as valid evidence, significantly enhancing the legal validity and data redundancy reliability of the evidence. It achieves trusted evidence storage of massive amounts of data with relatively low on-chain transaction costs, and the multi-chain redundant evidence storage can improve the judicial validity of the evidence and the system's fault tolerance.

[0092] Optionally, the external verifier can initiate a query request by submitting a record identifier (such as record_id). The trusted management system can then locate the batch in which the data belongs and the corresponding leaf node position of the data in the Merkle tree based on the record identifier.

[0093] The trusted management system extracts the hash values ​​of all sibling nodes along the path from the leaf node to the root node in the Merkle tree, combines them into a complete Merkle path, and returns it to the external verifier. Upon receiving the Merkle path, the external verifier combines it with the hash value of the data itself, performs a step-by-step hash calculation upwards according to the Merkle tree construction rules, and compares the calculated root hash value with the Merkle tree root hash stored on the blockchain. If they match, it proves that the data indeed belongs to the locked batch and has not been tampered with; if they do not match, it proves that the data does not belong to the batch or has been tampered with. This setup allows the external verifier to independently verify the existence of a single piece of data without relying on the trusted management system, ensuring that the credibility of the verification result is not constrained by the verification execution party, further guaranteeing the decentralization of the verification process and the non-repudiation of the verification results.

[0094] Optionally, the trusted management system can generate batch verification documents for each locked batch, which can be downloaded and verified by third parties.

[0095] For example, after a batch completes on-chain notarization and locking, the trusted management system gathers relevant information for that batch and generates a structured batch proof file. This batch proof file includes at least the following: batch information (including batch identifier, time window, number of data records, etc.), Merkle tree structure (including hash values ​​of each leaf node, hash values ​​of each parent node at each level, and the Merkle tree root hash), blockchain receipt (including transaction ID, block height, and timestamp), and batch generation timestamp, etc.

[0096] After obtaining the batch of supporting documentation, a third party can independently perform the following verification: based on the Merkle tree structure in the documentation and the hash value of the data to be verified, recalculate the Merkle tree root hash and compare it with the Merkle tree root hash recorded in the documentation. Simultaneously, the third party can verify the blockchain receipt in the documentation against the publicly available evidence records on a blockchain explorer to confirm the authenticity of the evidence transaction and the accuracy of the on-chain time. This setup provides external verification parties with standardized batch supporting documentation containing complete verification evidence, enabling third parties to independently complete data verification without relying on a trusted management system, meeting the self-verifiable evidence requirements in scenarios such as cross-border compliance, judicial evidence presentation, and regulatory auditing.

[0097] Optionally, in step S600, the trusted management system responds to the user request and verifies the structured evidence information based on a preset verification method.

[0098] For example, the default verification method can be managed verification or independent verification.

[0099] For managed verification, the Trusted Management System can provide managed verification services. Users submit structured evidence information to the Trusted Management System, which can automatically execute the verification process. For example, the Trusted Management System verifies the matching of digital signatures in the data list with DID public keys, verifies the validity of DID documents, verifies the validity of key status proofs, verifies the consistency between the Merkel path and the on-chain evidence root hash, verifies the authenticity of blockchain receipts, and verifies the completeness of quality reports, etc.

[0100] For independent verification, users download the independent verification tool through the trusted management system. This tool is an offline executable program, including modules for digital signature verification, Merkel path verification, and blockchain receipt parsing. Users import structured evidence information into the verification tool, which automatically executes the verification process offline. For example, it verifies whether the digital signature of the metering record in the data list matches the DID public key, verifies the consistency between the Merkel path and the hash of the on-chain evidence root, and verifies the authenticity and completeness of the blockchain receipt. After verification, the tool outputs standardized verification results locally, which users can submit along with the original evidence package to external institutions. In independent verification mode, the entire verification process requires no platform intervention; both the evidence package and the verification tool are completed offline on the user's side, making it suitable for issuing certificates to external independent institutions such as EU regulatory agencies and international verification bodies.

[0101] After verification, the Trusted Management System outputs standardized results in four states: pass, fail, partially pass, and insufficient materials, along with a detailed verification report.

[0102] Through the above embodiments, this application can verify structured evidence information through multi-form verification services, allowing users to obtain authoritative verification conclusions without requiring expertise in blockchain and cryptography. This is applicable to scenarios such as internal enterprise audits and regulatory reporting, significantly improving the convenience and efficiency of evidence verification. Furthermore, this application avoids verification obstacles caused by untrustworthy platforms or unreachable networks in cross-domain certification scenarios, ensuring that the reliability of verification conclusions no longer depends on the credit endorsement of the verification execution party. This effectively meets the requirements for verification independence and self-verification of evidence in cross-border compliance scenarios.

[0103] Optionally, a trusted management system can provide end-to-end operational auditing and traceability services.

[0104] For example, audit logs act as a trust recorder for the entire system, ensuring that all operations are traceable and auditable. The audit log module of a trusted management system can record every operation event across all functional modules in the system, including at least device registration, DID creation, device binding, key status changes, data uploading and notarization, batch locking, evidence package generation, and system configuration modifications.

[0105] Each audit log entry must include at least the operator, operation time, operation type, operation target, operation result, operation summary, and digital signature. After being digitally signed, audit logs can be stored in tamper-proof storage media, and their hash values ​​are periodically uploaded to the blockchain for evidence preservation to prevent subsequent tampering by internal personnel.

[0106] The trusted management system also provides audit log query and audit interfaces for regulatory agencies and internal risk control departments, supporting flexible retrieval based on operators, time ranges, operation types, and other criteria, and automatically generating audit reports. This setup enables complete recording and traceable auditing of all critical operations within the system, providing a reliable data foundation for regulatory compliance reviews and security incident tracing.

[0107] Optionally, the trusted management system also provides distributed system parameter management and dynamic configuration services.

[0108] For example, the system configuration module serves as the central management center for the entire system's operational strategies, centrally managing the operational parameters of each functional module. This module includes the following configuration functions: a chain configuration center, used to manage configuration information such as the consortium blockchain's RPC access address, smart contract address, and consensus parameters, supporting multi-chain switching and hot configuration updates; batch and proof rule configuration, used to configure parameters such as the time window for batch generation (including hourly, daily, or weekly), batch size limit, and locking threshold; alarm threshold configuration, used to configure trigger thresholds for various alarms such as device offline, key expiration, and data backlog, driving the operation and maintenance response process; default processing strategy configuration, used to configure the default data quality level classification standard, default verification service parameters, and default handling methods for abnormal data; and access control, employing a role-based access control mechanism to manage the access permissions of different user roles (including administrators, validators, and supervisors) to various modules of the system. This setup allows for dynamic adjustment of system operational parameters, adapting to different business scenarios and operational needs without modifying code or restarting the service, significantly improving the system's flexibility and maintainability.

[0109] The notarization and transaction method provided in this application enables devices to possess self-generated distributed digital identities. Public keys are stored on the blockchain, while private keys are hardware-isolated, allowing for self-verification and autonomous control of identity without relying on centralized third-party authentication. Starting from the data source, this application uses the device's private key to sign and confirm the measurement data. After the data is uploaded to the blockchain, the immutability and timestamp technology of the blockchain ensure reliable anchoring of evidence, guaranteeing that the data possesses cryptographic proof of authenticity from its inception. Every generation, transfer, and transaction of data leaves a digitally signed notarization record on the blockchain, forming a complete and traceable chain of evidence, solving the pain points of fragmented evidence and difficulty in tracing in traditional solutions. The system is automatically executed through smart contracts; transactions are triggered when preset conditions are met, achieving instant settlement and reducing counterparty risk and the possibility of human intervention.

[0110] The technical architecture of this application can be aligned with legal norms such as the Electronic Signature Law and complies with the DID-related standards already issued in my country (such as T / BEA 20001). It can enhance the probative value of electronic evidence at the judicial and regulatory levels based on technical self-verification, and is particularly suitable for serious scenarios that require strong supervision, high value, and mutual trust among multiple parties, such as carbon trading, green finance, and cross-border trade.

[0111] According to another aspect of this application, this application provides a trusted management system for metering data based on blockchain and DID. For example... Figure 4 As shown, the trusted management system for metering data may include an equipment center module 10, a DID registration module 20, a binding verification module 30, a data ledger management module 40, a batch aggregation and locking module 50, an evidence information processing module 60, and a key management module 70.

[0112] According to the example embodiment, the device center module 10 creates device file information for the smart metering instrument. The DID registration module 20 creates a unique decentralized identity identifier for the smart metering instrument based on the blockchain. The binding verification module 30 binds and verifies the device file information and the decentralized identity identifier based on the blockchain. The data ledger management module 40 stores the metering data digitally signed by the smart metering instrument in a preset structured format as a data ledger, and automatically verifies the signatures and maintains the trustworthiness of the metering data in the data ledger. The batch aggregation and locking module 50 performs batch aggregation and multi-chain evidence storage locking of the metering data in the data ledger based on a preset time window. The evidence information processing module 60 responds to user requests, generates on-chain trusted data information of the metering data, generates structured evidence information based on the on-chain trusted data information, and outputs the verified structured evidence information.

[0113] Optionally, the binding verification module 30 determines the binding information based on the device file information and the decentralized identity identifier. The binding verification module 30 digitally signs the binding information to generate binding credential information. The binding verification module 30 also digitally signs the binding information using a smart meter to generate binding signature information. Finally, the binding verification module 30 stores the binding credential information and binding signature information on the blockchain for evidence.

[0114] Optionally, in response to a user request, the binding verification module 30 verifies the validity of the binding relationship between the device profile information provided by the user and the decentralized identity identifier based on a preset interface.

[0115] Optionally, the key management module 70 performs lifecycle status management on the keys of the smart metering instrument.

[0116] Optionally, the data ledger management module 40 marks the credibility status of each measurement data in the data ledger. The data ledger management module 40 associates and stores the data ledger with data quality description information to assist in verifying the credibility status of the measurement data. The data ledger management module 40 verifies the digital signature of each measurement data to confirm its credibility status.

[0117] Optionally, the batch aggregation and locking module 50 aggregates multiple measurement data from the data ledger into a batch based on a preset time window, calculates the hash value of each measurement data in the batch, and constructs a Merkle tree to generate a Merkle tree root hash. The batch aggregation and locking module 50 submits the Merkle tree root hash of the batch to at least one blockchain for notarization and generates a blockchain receipt.

[0118] Optionally, the evidence information processing module 60 responds to a user request and verifies the structured evidence information based on a preset verification method.

[0119] It is understandable that the principles, processes, and corresponding beneficial effects of the blockchain and DID-based trusted management method for metering data have been described in detail above, and therefore will not be repeated here.

[0120] According to another aspect of this application, an electronic device is also provided. The electronic device includes: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, enable the one or more processors to perform the methods described above.

[0121] According to another aspect of this application, a non-volatile computer-readable storage medium is also provided. This storage medium stores a computer program that, when executed by a processor, can perform the methods described above.

[0122] According to another aspect of this application, this application also provides a computer program product. The computer program product includes: a computer program stored on a computer-readable storage medium; the computer program includes program instructions that, when executed by a computer, cause the computer to perform the methods described above.

[0123] Finally, it should be noted that the above description is merely a preferred embodiment of this application and is not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions of the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for trusted management of metering data based on blockchain and DID, characterized in that, include: Create equipment profile information for smart metering instruments; A unique decentralized identity identifier is created for the smart metering instrument based on blockchain; The device profile information is bound to and verified using the blockchain, along with the decentralized identity identifier. The metering data digitally signed by the smart metering instrument is stored in a data ledger in a preset structured format, and the signature is automatically verified and the credibility status of the metering data in the data ledger is maintained. Based on a preset time window, the measurement data in the data ledger is batch aggregated and multi-chain evidence storage and locking is performed. In response to a user request, on-chain trusted data information of the measurement data is generated, and structured evidence information is generated based on the on-chain trusted data information, and the verified structured evidence information is output.

2. The reliable management method for measurement data according to claim 1, characterized in that, The process of binding and verifying the device profile information and the decentralized identity identifier based on the blockchain includes: The binding information is determined based on the device file information and the decentralized identity identifier; The binding information is digitally signed to generate binding credential information; The binding information is digitally signed by the smart metering instrument to generate binding signature information; The binding credential information and the binding signature information are stored on the blockchain for verification.

3. The reliable management method for measurement data according to claim 2, characterized in that, After storing the binding credential information and the binding signature information on the blockchain, the metrological data trust management method further includes: In response to a user request, the system verifies the validity of the binding relationship between the device profile information provided by the user and the decentralized identity identifier based on a preset interface.

4. The reliable management method for measurement data according to claim 1, characterized in that, The method for reliable management of measurement data also includes: Lifecycle state management is performed on the key of the smart meter.

5. The reliable management method for measurement data according to claim 1, characterized in that, The automatic signature verification and maintenance of the credibility status of the measurement data in the data ledger include: The reliability status of each measurement data point is marked in the data ledger; and / or The data ledger and data quality description information are linked for storage to assist in verifying the reliability of the measurement data; and / or Verify the digital signature of each measurement data point to confirm the trustworthiness of the measurement data.

6. The reliable management method for measurement data according to claim 1, characterized in that, The step of batch aggregating and multi-chain evidence-based locking of the measurement data in the data ledger based on a preset time window includes: Based on a preset time window, multiple measurement data in the data ledger are aggregated into a batch, the hash value of each measurement data in the batch is calculated, and a Merkle tree is constructed to generate the Merkle tree root hash. Submit the Merkel root hash of the batch to at least one blockchain for notarization and generate a blockchain receipt.

7. The reliable management method for measurement data according to claim 1, characterized in that, The step of generating structured evidence information based on the trusted on-chain data information and outputting verified structured evidence information includes: In response to a user request, the structured evidence information is verified based on a preset verification method.

8. A trusted management system for metering data based on blockchain and DID, characterized in that, The trusted measurement data management system is used to execute the trusted measurement data management method as described in any one of claims 1-7, and the trusted measurement data management system includes: The Equipment Center module creates equipment file information for intelligent metering instruments; The DID registration module creates a unique decentralized identity identifier for the smart metering instrument based on the blockchain. The binding verification module binds and verifies the device profile information and the decentralized identity identifier based on the blockchain; The data ledger management module stores the metering data that has been digitally signed by the smart metering instrument in a preset structured format as a data ledger, and automatically verifies the signature and maintains the credibility status of the metering data in the data ledger. The batch aggregation and locking module performs batch aggregation and multi-chain evidence storage locking of the measurement data in the data ledger based on a preset time window. The evidence information processing module, in response to a user request, generates on-chain trusted data information of the measurement data, generates structured evidence information based on the on-chain trusted data information, and outputs the verified structured evidence information.

9. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the reliable management method for metering data as described in any one of claims 1-7.

10. A non-volatile computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the reliable management method for metrological data as described in any one of claims 1-7.

Images