Blockchain and did-based data tracing method and device for smart meter, storage medium and electronic equipment

Abstract

A data traceability method and device of a smart meter based on a blockchain and a DID, a storage medium, and an electronic device. The method comprises: obtaining a verifiable credential corresponding to metering data of a smart meter according to a received traceability verification request; obtaining a decentralized identifier and a public key from the verifiable credential; verifying whether the verifiable credential digital signature meets a preset signature condition according to the decentralized identifier and the public key; if the preset signature condition is met, verifying whether the verifiable credential meets a blockchain verification condition; if the blockchain verification condition is met, verifying whether the verifiable credential meets a state deadline condition; if the state deadline condition is met, determining that the metering data corresponding to the verifiable credential is trusted data, and outputting a traceability result.

Description

Technical Field

[0001] This application relates to the field of data traceability technology, and more specifically, to a data traceability method, device, storage medium, and electronic device for smart metering instruments based on blockchain and DID. Background Technology

[0002] Intelligent metering instruments are metering devices that integrate microelectronics, computer, communication, and modern sensor technologies, and can automatically complete the acquisition, processing, storage, and remote transmission of metering data.

[0003] Smart metering instruments are the main metering instruments for energy supply and demand metering and settlement in energy systems, and also the main metering instruments for "dual control of energy consumption". However, the inventors of this application have found that existing data traceability schemes for smart metering instruments cannot meet the requirements of reliable and convenient interaction for metering data to support multi-departmental and cross-system accounting, verification and trading.

[0004] Taking smart meters as an example, the metering parameter of a smart meter is electricity consumption. The metering data is mainly used for metering and settlement between power system suppliers and consumers, and is also the primary data basis for "dual control of energy consumption." Currently, the metered electricity consumption of smart meters can be roughly verified using carbon emission factors. For example, existing carbon verification methods mainly calculate carbon emissions based on electricity bills, meter readings, and carbon emission factors. If the meter data is incorrect or falsified, errors in the report will occur, making data traceability difficult.

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

[0006] According to one aspect of this application, this application provides a data traceability method for smart meters based on blockchain and DID. The method includes: obtaining a verifiable certificate corresponding to the metering data of the smart meter according to a received traceability verification request; parsing a decentralized identity identifier and a public key from the verifiable certificate; verifying whether the digital signature of the verifiable certificate in the verifiable certificate meets preset signature conditions according to the decentralized identity identifier and public key; if the preset signature conditions are met, verifying whether the verifiable certificate meets blockchain verification conditions; if the blockchain verification conditions are met, verifying that the verifiable certificate meets the state expiration condition; if the state expiration condition is met, determining that the metering data corresponding to the verifiable certificate is trusted data, and outputting the traceability result.

[0007] According to some embodiments of this application, the steps of parsing the decentralized identity identifier and public key from the verifiable credential include: parsing the decentralized identity identifier from the verifiable credential; calling the blockchain decentralized identity identifier parsing interface to obtain the decentralized identity identifier document corresponding to the decentralized identity identifier; and extracting the public key from the decentralized identity identifier document.

[0008] According to some embodiments of this application, the step of verifying whether the digital signature of the verifiable credential in the verifiable credential meets the preset signature conditions based on the decentralized identity identifier and public key includes: determining a first hash value of the data of the digital signature of the verifiable credential other than the digital signature value; verifying whether the first hash value and the digital signature value are consistent based on the decentralized identity identifier and public key; if so, the digital signature of the verifiable credential meets the preset signature conditions.

[0009] According to some embodiments of this application, the steps for verifying whether a verifiable credential meets the blockchain verification conditions include: in the direct storage mode, verifying whether the first hash value and the second hash value of the blockchain are consistent; if so, the verifiable credential meets the blockchain verification conditions; or, in the batch storage mode, verifying whether the Merkel proof of the verifiable credential is included in the Merkel proof root of the blockchain; if so, the verifiable credential meets the blockchain verification conditions.

[0010] According to some embodiments of this application, before the step of obtaining the verifiable credential corresponding to the metering data of the smart metering instrument based on the received traceability verification request, the method further includes: registering a decentralized identity identifier for the smart metering instrument; determining the verifiable credential based on the metering data, the private key, and the registered decentralized identity identifier; and storing the verifiable credential on the blockchain.

[0011] According to some embodiments of this application, the steps for registering a decentralized identity identifier for a smart meter include: generating a key pair for the smart meter, wherein the key pair includes a public key; generating a decentralized identity identifier based on the unique identification information of the smart meter; and calling a preset registration contract of the blockchain to register the public key and the decentralized identity identifier to the blockchain to complete the registration of the decentralized identity identifier.

[0012] According to some embodiments of this application, the key pair also includes a private key. The steps of determining a verifiable credential based on the metering data, the private key, and the registered decentralized identity identifier include: sorting and serializing the metering data according to preset rules to generate data to be digitally signed; determining the hash value of the data to be digitally signed to obtain a message digest; digitally signing the message digest with the private key to obtain a digital signature value; and encapsulating the metering data, the digital signature value, and the decentralized identity identifier into a verifiable credential.

[0013] According to one aspect of this application, a data traceability device for smart meters based on blockchain and DID is provided. The device includes an application layer. The application layer obtains a verifiable credential corresponding to the metering data of the smart meter upon receiving a traceability verification request. The application layer parses a decentralized identity identifier and a public key from the verifiable credential. The application layer verifies whether the digital signature of the verifiable credential in the verifiable credential meets preset signature conditions based on the decentralized identity identifier and public key. If the preset signature conditions are met, the application layer verifies whether the verifiable credential meets blockchain verification conditions. If the blockchain verification conditions are met, the application layer verifies that the verifiable credential meets a state expiration condition. If the state expiration condition is met, the application layer determines that the metering data corresponding to the verifiable credential is trustworthy data and outputs the traceability result.

[0014] According to another aspect of this application, this application also provides a non-volatile computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the data traceability method for smart metering instruments based on blockchain and DID as described above.

[0015] According to another aspect of this application, this application also provides an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the data traceability method for smart metering instruments based on blockchain and DID as described above.

[0016] The technical solution of this application can obtain verifiable credentials corresponding to the metering data of smart meters through a traceability verification request. The technical solution of this application can parse a decentralized identity identifier and public key from the verifiable credentials. The technical solution of this application can use the decentralized identity identifier and public key to verify whether the signature of the verifiable credentials meets preset signature conditions. If the preset signature conditions are met, the technical solution of this application can verify whether the verifiable credentials meet blockchain verification conditions. If the blockchain verification conditions are met, the technical solution of this application can verify that the verifiable credentials meet state expiration conditions. If the state expiration conditions are met, the technical solution of this application can determine that the metering data corresponding to the verifiable credentials is trusted data and output the traceability result.

[0017] The technical solution of this application realizes data traceability based on blockchain and DID smart metering instruments, fills the gap in real-time metering and reliable data interaction technology of smart metering instruments, provides strong technical support for metering data accounting, and reduces verification time and verification cost. Attached Figure Description

[0018] 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.

[0019] Figure 1 A flowchart illustrating method 1000 according to an embodiment of this application is shown; Figure 2 A flowchart illustrating step S120 according to an embodiment of this application is shown; Figure 3 A flowchart illustrating step S130 according to an embodiment of this application is shown; Figure 4 A flowchart illustrating step S140 according to an embodiment of this application is shown; Figure 5 A flowchart illustrating method 2000 according to an embodiment of this application is shown; Figure 6 A flowchart illustrating step S210 according to an embodiment of this application is shown; Figure 7 A flowchart illustrating step S220 according to an embodiment of this application is shown; Figure 8 A schematic diagram of the structure of a data tracing device according to an embodiment of this application is shown.

[0020] Explanation of reference numerals in the attached figures: 10. Data traceability device; 11. Perception layer; 12. Data layer; 13. Service layer; 14. Application layer. Detailed Implementation

[0021] 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.

[0022] 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.

[0023] 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.

[0024] 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.

[0025] 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. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0026] The English terms used in this application, their full English names, and their corresponding Chinese definitions are as follows: DID, Decentralized Identifier; VC stands for Verifiable Credential. API, Application Programming Interface; SM2 stands for Elliptic Curve Public Key Cryptography Algorithm. SM3, SM3 cryptographic hash algorithm; ID, Identity; UTF-8, 8-bit Unicode Transformation Format, 8-bit Unicode Transformation Format; DER, Distinguished Encoding Rules; TEE, Trusted Execution Environment; ISO 8601, International Organization for Standardization 8601, International Representation of Dates and Times; JSON-LD, JavaScript Object Notation for Linked Data, is the JSON representation of linked data. JWS, JSON Web Signature; JWT stands for JSON Web Token.

[0027] The inventors of this application also discovered that existing data traceability schemes suffer from poor timeliness and high accounting costs. For example, taking smart meters as an example, carbon verification typically relies on manual, annual verification, requiring 3-5 professional verifiers to spend at least a week to produce a single carbon verification report, resulting in a large time span and poor timeliness. Enterprises must undergo carbon verification by third-party organizations for carbon compliance, with each verification costing tens to hundreds of thousands of yuan, increasing their operating costs.

[0028] See Figure 8 The data traceability device 10 may include a perception layer 11, a data layer 12, a service layer 13, and an application layer 14.

[0029] The devices in the sensing layer 11 may include smart meters. The sensing layer 11 can identify and collect the status and data of the environment or devices. Each smart meter should be assigned a unique DID to identify the device. The smart meter should have a built-in security module to store its private key.

[0030] Data Layer 12 can aggregate, process, and forward data from smart meters. Data Layer 12 performs preliminary verification of the digital signature data generated by the smart meters. Data Layer 12 packages the verified data into a VC (Value Capability) and submits it to the blockchain network for storage via a blockchain interface. Data Layer 12 also undertakes the auxiliary registration and management functions of the smart meters' DID (Digital ID).

[0031] Service layer 13 consists of a blockchain network and a distributed identity registration authority, which can provide core services such as data storage, traceability verification, and identity management for application layer 14. The basic architecture of the blockchain should comply with the relevant provisions of GB / T 42752.

[0032] Blockchain is a decentralized, distributed, and tamper-proof digital ledger network. By sharing and synchronizing data among multiple nodes in the network, and using cryptographic algorithms to ensure the security of data transmission and access, it can achieve data consistency, traceability, and non-repudiation. A blockchain includes ledger nodes and consensus nodes. This network maintains a shared distributed ledger used to store hash values ​​and related vouchers of smart meter readings. All metering data transactions are packaged into blocks on the chain in chronological order and linked together using a Merkle tree to form a traceable chain structure, providing the technological foundation for data immutability and verifiability.

[0033] A DID registry is a system that provides DID management services, responsible for the registration, updating, revocation, and resolution of DIDs. This role can be undertaken by specific nodes or smart contracts within the blockchain network. The DID registry ensures that each smart meter, agent node, etc., obtains a unique DID and writes the corresponding public key into the on-chain DID document. New devices or participants joining the traceability system should register their identity through the DID registry to obtain a trusted distributed identifier.

[0034] Application layer 14 can include end users and application systems that provide data services. End users can query the on-chain metering data storage of smart meters via API, obtain VCs issued by the smart meters, and use them for purposes such as electricity bill settlement, energy trading, and carbon verification. Data users (such as trading platforms) can act as verifiers, obtaining VCs issued by specific smart meter DIDs from the chain, verifying their signatures and integrity, and then using them for business transactions.

[0035] The following is combined with Figure 8 This application describes a data traceability method 1000 for smart metering instruments based on blockchain and DID, see [link to relevant documentation]. Figure 1 Method 1000 includes steps S110-160.

[0036] In step S110, a verifiable certificate corresponding to the metering data of the smart metering instrument is obtained based on the received traceability verification request.

[0037] According to the example embodiment, the intelligent metering instrument is a metering device that integrates microelectronics technology, computer technology, communication technology, and modern sensor technology, and can automatically complete the acquisition, processing, storage, and remote transmission of metering data. The intelligent metering instruments in this application include, but are not limited to, intelligent energy meters, intelligent carbon metering meters, intelligent carbon meters, intelligent water meters, intelligent gas meters, and intelligent heat meters, etc., and this application does not impose any limitations on these.

[0038] For example, a smart meter can be an electric carbon metering smart energy meter. This meter can have a built-in security module (such as a cryptographic chip), be able to execute national cryptographic algorithms, and have blockchain client functionality. It can not only measure active power but also synchronously measure carbon emissions based on dynamic electric carbon factors, achieving "synchronous electric carbon metering." Devices in the sensing layer 11 can include electric carbon metering smart energy meters.

[0039] A traceability verification request is an operational instruction initiated by the verifying party to verify the authenticity and completeness of metering data for a specific period of time from a specific smart meter. For example, the verifying party could be a carbon verification agency, an electricity billing system, or a carbon trading platform.

[0040] A verifiable credential (VC) is a digital credential that includes a claim and a cryptographic proof. Its core purpose is to enable the holder to present a data segment that can be independently verified to the verifier. A verifiable credential is a JSON-LD format data structure generated by the issuer digitally signing the credential content using their private key. It includes fields such as issuer identifier, holder identifier, credential subject, and proof.

[0041] For example, a verifiable credential refers to a metering data credential issued by a smart meter (as the issuer) or its agent node for a specific metering data. The credential declares metering data fields such as the smart meter reading, unit of measurement, and data collection timestamp. The cryptographic proof uses the SM2 elliptic curve digital signature algorithm, which conforms to the national cryptographic standard GB / T 32918.2, to generate a signature value. The decentralized identity identifier (DID) of the smart meter is used as the issuer identifier, thereby strongly binding the metering data with the meter's identity.

[0042] A verifiable credential digital signature is a complete verifiable credential (VC) data structure that includes cryptographic proof. For example, a verifiable credential digital signature is created by the VC holder using their private key to first normalize and serialize the credential content, then calculate the SM3 hash value, and finally digitally sign the hash value using the SM2 private key. The digital signature value and the algorithm identifier are written together into the proof field of the VC to form a complete verifiable credential signature.

[0043] For example, in step S110, application layer 14 obtains the verifiable credential corresponding to the metering data of the smart metering instrument based on the received traceability verification request. After receiving the traceability verification request, application layer 14 queries the blockchain and obtains the complete VC content through the ID of the verifiable credential (VC), or directly obtains the complete VC content through the holder. If only a VC digest is available, the holder should provide a method to obtain the original VC.

[0044] In step S120, the decentralized identity identifier and public key are parsed from the verifiable credentials.

[0045] According to the example embodiment, each smart meter should have a unique decentralized identity identifier (DID). The format of the decentralized identity identifier can refer to the DID data model design in "Recommendation Decentralized Identifiers (DIDs) v1.0". The DID of the smart meter can be generated when it is connected to the blockchain network during its factory calibration. The generation method should preferably be decentralized, for example, based on the smart meter serial number or public key hashing. Service layer 13 can provide a DID registration smart contract interface. The DID of newly connected smart meters should be registered on the blockchain by an authorized agency (such as the power supply company) and written into the corresponding DID document.

[0046] DID documents can be in JSON-LD format, designed according to "JSON-LD 1.1 A JSON-based Serialization for Linked Data". A DID document includes metadata such as the public key and service information of the DID subject.

[0047] For example, for smart energy meters with carbon metering, the DID document should include at least the following: DID: The DID of a carbon-metered smart energy meter, uniquely corresponding to a carbon-metered smart energy meter; VerificationMethod: A list of public keys used for signing the carbon-metered smart energy meter. Each public key should include a unique identifier (such as key ID), type (such as SM2), and public key value. The manufacturer can generate a key pair (including a public key and a private key) for the carbon-metered smart energy meter at the factory and write the public key into the DID document. Authentication: The verification method used to authenticate the identity of the smart energy meter should reference the public key in verificationMethod. For example, the public key corresponding to the master private key under the smart energy meter's DID can be specified as the authentication key; Service: A list of service endpoints that describes the services provided by the carbon metering smart energy meter. For example, a carbon metering smart energy meter can define a data service endpoint that points to the address of its energy information acquisition terminal or data cache, and the service type can be defined as MeterReadingService.

[0048] For example, in step S120, application layer 14 parses the decentralized identity identifier and public key from the verifiable credential. The verifiable credential includes the decentralized identity identifier. Application layer 14 can parse the verifiable credential to extract the decentralized identity identifier. Application layer 14 can search for decentralized identity identifier documents based on the decentralized identity identifier, confirm its validity, and extract the public key from the decentralized identity identifier documents.

[0049] In step S130, the verifiable credentials in the verifiable credentials are verified to meet the preset signature conditions based on the decentralized identity identifier and the public key.

[0050] According to the example embodiment, the preset signature condition can be the consistency condition between the digital signature value and the hash value of the verifiable credential signature. For example, in step S140, application layer 14 verifies whether the digital signature of the verifiable credential meets the preset signature condition based on the public key. For example, application layer 14 can calculate the hash value of the data of the verifiable credential other than the signature value, and use the public key to verify whether the hash value and the digital signature value are consistent. If application layer 14 verifies that the digital signature of the verifiable credential does not meet the preset signature condition, then the digital signature of the verifiable credential should not be accepted.

[0051] If the preset signature conditions are met, proceed to step S140.

[0052] In step S140, it is verified whether the verifiable credential meets the blockchain verification conditions.

[0053] According to the example embodiment, blockchain consistency can be a condition for verifying the consistency between the hash value of a verifiable credential and the corresponding hash value stored on the blockchain. For example, in step S140, application layer 14 verifies whether the verifiable credential meets the blockchain verification condition. Application layer 14 can compare the consistency between the hash value of the verifiable credential and the corresponding hash value stored on the blockchain. If application layer 14 verifies that the verifiable credential does not meet the blockchain verification condition, then the traceability of the measurement data is unreliable.

[0054] If the blockchain verification conditions are met, proceed to step S150.

[0055] In step S150, it is verified whether the verifiable credential meets the status expiration condition.

[0056] According to the example embodiment, the status expiration condition can be that the verifiable credential is valid and within its expiration period. Status management of the verifiable credential can take the form of a status list or a revocation list. The verifier can query the relevant status through the VC's ID. For example, in step S150, application layer 14 verifies whether the verifiable credential meets the status expiration condition. If application layer 14 verifies that the verifiable credential has been revoked or has expired, then the verifiable credential is considered invalid.

[0057] If the state duration condition is met, proceed to step S160.

[0058] In step S160, the measurement data corresponding to the verifiable voucher is determined to be reliable data, and the traceability result is output.

[0059] According to the example embodiment, after steps S130-S150, the application layer 14 can verify that the authenticity, completeness, and timeliness of the verifiable certificate have all passed verification, and the measurement data can be determined as reliable data. The application layer 14 can output the traceability results (including verification time, verification party (smart meter) DID, verification conclusion, etc.). Trusted data can be used in business scenarios, such as electricity billing, electricity trading, or carbon emission accounting. The traceability results can be written to the blockchain for future verification.

[0060] Through the above embodiments, the technical solution of this application can obtain verifiable credentials corresponding to the metering data of smart meters through a traceability verification request. The technical solution of this application can parse a decentralized identity identifier and public key from the verifiable credentials. The technical solution of this application can verify whether the signature of the verifiable credentials in the verifiable credentials meets preset signature conditions using the decentralized identity identifier and public key. If the preset signature conditions are met, the technical solution of this application can verify whether the verifiable credentials meet blockchain verification conditions. If the blockchain verification conditions are met, the technical solution of this application can verify that the verifiable credentials meet state expiration conditions. If the state expiration conditions are met, the technical solution of this application can determine that the metering data corresponding to the verifiable credentials is trustworthy data and output the traceability result.

[0061] The technical solution of this application realizes data traceability based on blockchain and DID smart metering instruments, fills the gap in real-time metering and reliable data interaction technology of smart metering instruments, provides strong technical support for metering data accounting, and reduces verification time and verification cost.

[0062] Optionally, see Figure 2 Step S120 may include steps S121-S123.

[0063] In step S121, a decentralized identity identifier is obtained by parsing from the verifiable credentials.

[0064] For example, in step S121, application layer 14 parses the decentralized identity identifier from the verifiable credential. Application layer 14 parses the issuer field of the verifiable credential to obtain the decentralized identity identifier.

[0065] In step S122, the blockchain decentralized identity identifier parsing interface is called to obtain the decentralized identity identifier document corresponding to the decentralized identity identifier.

[0066] For example, in step S122, application layer 14 calls the blockchain decentralized identity identifier parsing interface to search for the latest decentralized identity identifier document corresponding to the decentralized identity identifier, and confirms that the decentralized identity identifier document is valid. The decentralized identity identifier document can be in JSON-LD format.

[0067] In step S123, the public key is extracted from the decentralized identity identifier document.

[0068] For example, application layer 14 extracts the public key from the decentralized identity identifier document. The "verificationMethod" array in the DID document contains the public key information associated with that DID, including a unique identifier (such as key ID), type (such as SM2), and public key value (publicKeyMultibase) for each public key entry. Application layer 14 can locate the corresponding entry and extract the public key from the "verificationMethod" array in the decentralized identity identifier document based on the key ID specified by the "verificationMethod" attribute in the proof field of the verifiable credential signature.

[0069] Through the above embodiments, the technical solution of this application obtains a decentralized identity identifier from verifiable credentials. The technical solution of this application can obtain the decentralized identity identifier document corresponding to the decentralized identity identifier by calling the blockchain decentralized identity identifier parsing interface. The technical solution of this application can extract the public key from the decentralized identity identifier document.

[0070] Optionally, see Figure 3 Step S130 may include steps S131-S132.

[0071] In step S131, a first hash value is determined for the data other than the digital signature value in the verifiable credential digital signature.

[0072] According to the example embodiment, the digital signature value can be a binary data block encrypted with a private key and hashed. The calculation object of the first hash value can be data other than the digital signature value in the verifiable credential digital signature. For example, in step S131, the application layer 14 can determine the first hash value of the data other than the digital signature value in the verifiable credential digital signature using a hash value algorithm. The hash algorithm should comply with the provisions of GB / T 32905.

[0073] In step S132, based on the decentralized identity identifier and public key, it is verified whether the first hash value and the digital signature value are consistent.

[0074] For example, in step S132, application layer 14 can verify the consistency between the first hash value and the digital signature value using a digital signature verification algorithm based on the decentralized identity identifier and public key. The digital signature verification algorithm should comply with the provisions of GB / T32918.2.

[0075] If the first hash value and the digital signature value are consistent, the verifiable credential digital signature meets the preset signing conditions, verifying that the verifiable credential was indeed generated by the private key holder and that the metering data has not been modified after signing. If the first hash value and the digital signature value are inconsistent, the verifiable credential is not accepted.

[0076] Through the above embodiments, the technical solution of this application can determine the first hash value of the data other than the digital signature value in the digital signature of the verifiable credential. The technical solution of this application can verify the consistency between the first hash value and the digital signature value based on a decentralized identity identifier and a public key, thereby verifying the authenticity of the verifiable credential.

[0077] Optionally, see Figure 4 Step S140 may include step S141 or step S142.

[0078] In step S141, under the direct evidence storage mode, it is verified whether the first hash value and the second hash value of the blockchain are consistent.

[0079] According to the example embodiment, the methods for storing verifiable credentials on the blockchain may include direct storage mode, batch storage mode, and log event storage mode. The second hash value can be a hash value of the data of the verifiable credential stored on the blockchain, excluding the digital signature value.

[0080] For example, in step S141, in the direct evidence storage mode, application layer 14 verifies whether the first hash value and the second hash value of the blockchain are consistent. Application layer 14 can call the on-chain query interface using the DID of the verifiable credential as an index to obtain the corresponding on-chain second hash value, and then compare the first hash value and the second hash value byte by byte.

[0081] If the first hash value and the second hash value are the same, the verifiable credential meets the blockchain verification conditions, and the verifiable credential VC has not been modified after being stored on the blockchain.

[0082] If the first hash value and the second hash value are inconsistent, the verifiable credential does not meet the blockchain verification conditions, and the verifiable credential VC may be modified after being stored on the blockchain.

[0083] In step S142, under the batch storage mode, it is verified whether the Merkel proof of the verifiable credential is included in the Merkel proof root of the blockchain.

[0084] According to the example embodiment, a Merkle tree can be a tree-structured cryptographic data structure in which each leaf node stores a single piece of data (or its hash value), each non-leaf node stores the hash of its child node hash values, and the root node (Merkle root) represents the cryptographic digest of all leaf node data in the entire tree.

[0085] In the batch storage mode, the hash values ​​of verifiable certificates of several measurement data are used as leaf nodes to construct a Merkle tree. Only the Merkle root value is uploaded to the chain through a single blockchain transaction, and a corresponding Merkle proof path is generated for each verifiable certificate, which greatly reduces on-chain storage costs and transaction fees.

[0086] For example, in step S142, application layer 14 verifies whether the Merkel proof of the verifiable credential is included in the Merkel proof root of the blockchain in the batch proof mode.

[0087] Application layer 14 can obtain the Merkel proof of the verifiable credential and verify whether the Merkel proof is contained in the Merkel proof root by calculating layer by layer and comparing it with the on-chain Merkel root.

[0088] If the Merkel proof is included in the Merkel proof root of the blockchain, then the verifiable credential satisfies the blockchain verification conditions, and the verifiable credential VC has not been modified after being stored in the blockchain.

[0089] If the Merkel proof is not included in the Merkel proof root of the blockchain, the verifiable credential does not meet the blockchain verification conditions, and the verifiable credential VC may be modified after being stored on the blockchain.

[0090] Through the above embodiments, the technical solution of this application can verify whether the first hash value and the second hash value of the blockchain are consistent in the direct evidence storage mode, and verify whether the Merkel proof of the verifiable certificate is included in the Merkel proof root of the blockchain in the batch evidence storage mode, thereby verifying whether the certificate VC has been modified after being stored in the blockchain.

[0091] The following is combined with Figure 8 This application describes a data traceability method for smart metering instruments based on blockchain and DID (Data Identification and Information Management). See also: Figure 5 Method 2000 may include steps S210-S290.

[0092] In step S210, a decentralized identity identifier is registered for the smart meter.

[0093] According to the example implementation, each smart meter should have a unique decentralized identity identifier (DID). The DID of the smart meter can be generated when it is connected to the blockchain network during its factory calibration.

[0094] For example, in step S210, the perception layer 11, the data layer 12, and the service layer 13 register decentralized identity identifiers for the smart metering instrument.

[0095] Optionally, see Figure 6 Step S210 may include steps S211-S213.

[0096] In step S211, a key pair is generated for the smart metering instrument.

[0097] According to the example embodiment, key pair generation can employ the SM2 elliptic curve public key cryptography algorithm, which should comply with GB / T 32918.1. The key pair may include a private key and a public key. The private key should be stored in a security module (such as a security chip or a Trusted Execution Environment (TEE)) built into the smart meter. The public key is represented in 65-byte uncompressed format or 33-byte compressed format and written to the "verificationMethod" field of the DID document. For example, in step S211, the data layer 12 generates a key pair for the smart meter, determines the public key, and sends the public key to the sensing layer.

[0098] In step S212, a decentralized identity identifier is generated based on the unique identification information of the smart meter.

[0099] According to the example embodiment, the unique identification information of the smart meter can be the meter serial number, meter number, or the unique identification code of the measuring instrument as specified in the national standard.

[0100] In step S212, data layer 12 can generate a decentralized identity identifier based on the unique identification information of the smart meter. The generation method can be decentralized, for example, using the UTF-8 encoded byte string of the serial number or the DER encoding of the SM2 public key as input, calculating the SM3 hash value, and then encoding the first 16 bytes of the hash value into 32 bits as the method-specific-id part of the DID.

[0101] In step S213, the blockchain's preset registration contract is invoked to register the public key and decentralized identity identifier to the blockchain, thereby completing the registration of the decentralized identity identifier.

[0102] According to the example embodiment, the preset registration contract can be a smart contract pre-deployed on the blockchain. For example, in step S213, the service layer 13 calls the blockchain's preset registration contract to register the public key and decentralized identity identifier (DID) to the blockchain, thereby completing the registration of the DID. After registration, the application layer 14 can query the corresponding public key on the blockchain through the DID.

[0103] In step S220, verifiable credentials are determined based on metering data, private key, and registered decentralized identity identifier.

[0104] According to the example embodiment, the metering data can be used by the sensing layer 11 (i.e., smart metering instrument) to identify and collect the status and data of the environment or equipment.

[0105] For example, in step S220, the perception layer 11 and the data layer 12 determine the verifiable credential signature based on the metering data, key pair, and registered decentralized identity identifier.

[0106] Optionally, see Figure 7 Step S220 may include steps S221-S224.

[0107] In step S221, the measurement data is sorted and serialized according to preset rules to generate data to be digitally signed.

[0108] According to the example embodiment, the preset rules may include field order normalization rules, numerical format rules, and encoding rules. For example, the raw data of the measurement data is in JSON format.

[0109] The field order normalization rule recursively sorts all keys in the JSON object in ASCII lexicographical order; nested objects are handled in the same way. The numeric format rules require floating-point numbers to retain a fixed number of decimal places, and timestamps to use the ISO 8601 format. The encoding rules require the serialized string to be converted to a byte array using UTF-8 encoding, without any unnecessary whitespace characters.

[0110] Converting measurement data into digitally signed data that is a deterministic byte sequence ensures that the same measurement data always produces the same byte sequence, maintaining consistent results across different implementation environments.

[0111] For example, in step S221, the sensing layer 11 collects measurement data, and the data layer 12 sorts and serializes the measurement data according to preset rules to generate data to be digitally signed.

[0112] In step S222, the hash value of the data to be digitally signed is determined to obtain the message digest.

[0113] According to the example embodiment, in step S222, the data layer 12 can use the SM3 hash algorithm to perform operations on the data to be digitally signed and generate a 256-bit hash value. The SM3 hash algorithm can conform to GB / T 32905. The hash value of the data to be digitally signed can be used as a message digest.

[0114] In step S223, the message digest is digitally signed using the private key to obtain a digital signature value.

[0115] According to the example embodiment, in step S223, data layer 12 can use the SM2 signature algorithm, with the private key as the signature key, to digitally sign the message digest to obtain a signature value. Additional information can be introduced during the signing process, such as including the DID of the smart meter and the reading time tag in the hash, or introducing a random number during signing. When introducing additional information, the integrity of the record should be maintained and it should be explicitly labeled. The signature value can identify fields and algorithms, improving interoperability. The signature value format can be encapsulated according to the requirements of JWS or JWT.

[0116] In step S224, the measurement data, digital signature value, and decentralized identity identifier are encapsulated into a verifiable credential.

[0117] According to the example embodiment, in step S224, data layer 12 encapsulates the metering data, digital signature value, and decentralized identity identifier into a verifiable credential, forming a self-contained, verifiable digital certificate. The verifiable credential should include relevant claims and cryptographic proofs. The data model of the verifiable credential can be defined using JSON-LD, maintaining consistency in field types and formats, being compatible with data exchange formats of different blockchain platforms, and allowing for scalable fields and semantic interoperability.

[0118] In step S230, the verifiable credentials are stored on the blockchain.

[0119] According to the example embodiment, in step S230, the service layer 13 can store verifiable credentials on the blockchain. The on-chain mode can include edge proxy on-chain mode, main site on-chain mode, and hybrid on-chain mode.

[0120] For example, in the edge proxy on-chain mode, smart meters transmit metering data to the energy information collection terminal (data layer 12) via the local communication network. The energy information collection terminal aggregates and digitally signs the data, and acts as a blockchain client or node to upload verifiable credentials to the blockchain. If any abnormality is detected in the data transmission between the smart meter and the energy information collection terminal (such as data verification failure or signature verification failure), the on-chain process should be stopped and an alarm should be triggered.

[0121] For example, in the master station on-chain mode, the smart energy meter transmits data to the data acquisition master station (data layer 12). After completing the verification and storage, the data acquisition master station, acting as a blockchain client or node, writes the verifiable credentials onto the blockchain.

[0122] Simultaneously, both edge proxy on-chain and main station on-chain methods exist, forming a hybrid on-chain mode. The main station should be able to obtain the on-chain data from the power information collection terminal and archive it into its local database. Data already on-chain by the power information collection terminal does not need to be re-uploaded by the main station, but its on-chain hash value can be included in the main station's record for a unified external query interface. When querying, application layer 14 should be able to obtain a consistent data structure and verification process, and the verification results should not be affected by differences in modes.

[0123] Verifiable credentials can be stored on the blockchain in three ways: direct storage, batch storage, and log event storage. In direct transaction storage, each verifiable credential generates a blockchain transaction, with key data stored as transaction content. In batch storage, the hash values ​​of multiple verifiable credentials form a Merkle tree, and only the Merkle root value is recorded on the chain; a single verifiable credential can be verified through Merkle proofs. In log event storage, the blockchain event log function is used to write metering data anchoring information into the on-chain log, suitable for high-frequency scenarios.

[0124] Steps S240-S290 are the same as steps S110-S160 of method 1000, so they will not be described again.

[0125] Through the above embodiments, the technical solution of this application can register decentralized identity identifiers for smart metering instruments. The technical solution of this application can determine verifiable credentials using metering data, private keys, and the registered decentralized identity identifiers. The technical solution of this application can store the verifiable credentials on a blockchain.

[0126] The technical solution of this application applies "blockchain + DID + national cryptographic algorithm" to smart metering instruments to measure, calculate, digitally sign, encrypt and store carbon emissions from electricity, thereby achieving data tamper-proofing and trusted cross-domain data interaction from the data acquisition end.

[0127] For example, for smart energy meters that use "blockchain + DID + national cryptographic algorithm" for carbon metering, a trusted interactive service system for carbon metering data can be built based on the trusted data space of "blockchain + artificial intelligence", integrating new power systems, carbon statistical accounting, carbon traceability, carbon trading, and carbon supervision.

[0128] According to another aspect of this application, this application also provides a non-volatile computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the data traceability method for smart metering instruments based on blockchain and DID as described above.

[0129] According to another aspect of this application, this application also provides an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by one or more processors, enable the one or more processors to implement the data traceability method for smart metering instruments based on blockchain and DID as described above.

[0130] According to another aspect of this application, this application also provides a computer program product, including: a computer program stored on a computer-readable storage medium; the computer program includes program instructions, which, when executed by a computer, cause the computer to perform the data traceability method for smart metering instruments based on blockchain and DID as described above.

[0131] 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 data traceability method for smart metering instruments based on blockchain and DID, characterized in that, The method includes: Based on the received traceability verification request, obtain the verifiable certificate corresponding to the measurement data of the smart metering instrument; The decentralized identity identifier and public key are obtained by parsing the verifiable credentials. Based on the decentralized identity identifier and the public key, verify whether the digital signature of the verifiable credential in the verifiable credential meets the preset signature conditions; If the preset signature conditions are met, verify whether the verifiable credential meets the blockchain verification conditions. If the blockchain verification conditions are met, verify whether the verifiable credential meets the state expiration conditions. If the aforementioned status period condition is met, the measurement data corresponding to the verifiable certificate is determined to be reliable data, and the traceability result is output.

2. The method according to claim 1, characterized in that, The process of parsing the decentralized identity identifier and public key from the verifiable credential includes: The decentralized identity identifier is obtained by parsing the verifiable credentials; Call the blockchain decentralized identity identifier parsing interface to obtain the decentralized identity identifier document corresponding to the decentralized identity identifier; Extract the public key from the decentralized identity identifier document.

3. The method according to claim 1, characterized in that, The step of verifying whether the digital signature of the verifiable credential in the verifiable credential meets the preset signature conditions based on the decentralized identity identifier and the public key includes: Determine the first hash value of the data in the digital signature of the verifiable credential other than the digital signature value; Based on the decentralized identity identifier and the public key, verify whether the first hash value and the digital signature value are consistent; If so, the verifiable credential digital signature satisfies the preset signature conditions.

4. The method according to claim 3, characterized in that, The verification of whether the verifiable credential meets the blockchain verification conditions includes: In the direct evidence storage mode, verify whether the first hash value and the second hash value of the blockchain are consistent; If so, the verifiable credential satisfies the blockchain verification conditions; or In the batch proof mode, verify whether the Merkel proof of the verifiable credential is included in the Merkel proof root of the blockchain; If so, the verifiable credential satisfies the blockchain verification conditions.

5. The method according to claim 1, characterized in that, Before obtaining the verifiable certificate corresponding to the metering data of the smart metering instrument based on the received traceability verification request, the method further includes: Register a decentralized identity identifier for the smart metering instrument; The verifiable credential is determined based on the metering data, the private key, and the registered decentralized identity identifier; The verifiable credentials are stored in the blockchain.

6. The method according to claim 5, characterized in that, Registering a decentralized identity identifier for the smart meter includes: Generate a key pair for the smart metering instrument, wherein the key pair includes the public key; The decentralized identity identifier is generated based on the unique identification information of the smart meter. The preset registration contract of the blockchain is invoked to register the public key and the decentralized identity identifier to the blockchain, thereby completing the registration of the decentralized identity identifier.

7. The method according to claim 5, characterized in that, The key pair also includes a private key, and the determination of the verifiable credential based on the metering data, the private key, and the registered decentralized identity identifier includes: The measurement data is sorted and serialized according to preset rules to generate data to be digitally signed; Determine the hash value of the data to be digitally signed to obtain a message digest; The message digest is digitally signed using the private key to obtain a digital signature value; The measurement data, the digital signature value, and the decentralized identity identifier are encapsulated into the verifiable credential.

8. A data traceability device for a smart metering instrument based on blockchain and DID, characterized in that, The device includes: The application layer obtains the verifiable credentials corresponding to the metering data of the smart metering instrument based on the received traceability verification request. The application layer parses the decentralized identity identifier and public key from the verifiable credentials; The application layer verifies whether the digital signature of the verifiable credential in the verifiable credential meets the preset signature conditions based on the decentralized identity identifier and the public key. If the preset signature conditions are met, the application layer verifies whether the verifiable credential meets the blockchain verification conditions. If the blockchain verification conditions are met, the application layer verifies whether the verifiable credential meets the state expiration condition. If the aforementioned status period condition is met, the application layer determines that the measurement data corresponding to the verifiable credential is reliable data and outputs the traceability result.

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

10. 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 data tracing method as described in any one of claims 1-7.

Images