Block chain-based battery full life cycle data tracing method and system

Abstract

The invention discloses a block chain-based battery full life cycle data tracing method and system, and the method comprises the steps: receiving verification request information sent by a battery pack manufacturer, calling corresponding parameter data from a storage server according to the verification request information, and carrying out the processing of the corresponding parameter data to generate a zero-knowledge proof; submitting the zero-knowledge proof, the encrypted data packet and verification request information to a data verification contract for verification, calling an authority management contract to modify the manufacturer access authority after verification is passed, collecting key operation through an audit tracking contract, performing uplink to generate a log record, and finally, according to the log record in the block chain network, performing data verification on the block chain network. The safe and traceable query of the full-life-cycle information of the battery cell is realized, the data privacy is ensured, and the credibility and high efficiency of the full-life-cycle information tracing process are ensured.

Description

Technical Field

[0001] This invention relates to the field of battery data processing technology, and in particular to a blockchain-based method and system for tracing battery lifecycle data. Background Technology

[0002] The battery manufacturing industry involves data interaction among multiple upstream and downstream enterprises and has strict requirements for data privacy, security, and management. For example, data interaction between component suppliers and vehicle manufacturers needs to ensure that data is not leaked. However, traditional encryption mechanisms can only achieve one-way transmission protection. This means that the recipient cannot verify the validity of the data without obtaining the original data, and insufficient encryption strength may lead to data leakage or tampering, undermining the credibility of traceability data. In addition, existing technologies lack unified operation log management. Operation records are scattered across various enterprise systems and cannot be linked to the blockchain traceability chain. Once data anomalies occur, it is impossible to quickly locate the operation subject and time, thus failing to achieve one-click traceability of data throughout the entire lifecycle. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a blockchain-based method and system for tracing battery lifecycle data, thereby resolving the technical issue that existing battery lifecycle data tracing methods cannot achieve accurate tracing of lifecycle data.

[0004] A first aspect of this invention provides a blockchain-based method for tracing battery lifecycle data, the method comprising: Receive verification request information sent by the battery pack manufacturer, wherein the verification request information includes at least the identifier of the data packet to be verified and the data packet to be verified; Based on the identifier of the data packet to be verified, the corresponding battery parameter data is retrieved from the storage server for processing to obtain a zero-knowledge proof. The battery parameter data is the parameter data collected at any stage from the battery manufacturing stage to the battery application stage. The zero-knowledge proof and verification request information are sent to the data verification contract for verification. If the verification is successful, the permission management contract is called to modify the data access permissions of the battery pack manufacturer, and the audit trail contract is called to collect all key operations of the data verification contract and the permission management contract. All key operations are sent to the blockchain network to generate log records. Based on log records in the blockchain network, the battery's entire lifecycle information can be traced.

[0005] In one possible implementation of the first aspect, before receiving the verification request information sent by the battery pack manufacturer, the method further includes: Obtain battery parameter data, encrypt the battery parameter data, and obtain ciphertext data; Calculate the original hash value of the battery parameter data, and construct an encrypted data packet based on the battery parameter data, the encrypted data, the original hash value, and the timestamp generated by the battery parameter data; The encrypted data packet is sent to the storage server, which then performs a metadata packet generation operation on the encrypted data packet and writes the metadata packet into the mapping table of the blockchain network.

[0006] In one possible implementation of the first aspect, the zero-knowledge proof and verification request information are sent to a data verification contract for verification, including: The zero-knowledge proof and verification request information are sent to the data verification contract, causing the data verification contract to perform verification operations, which include: Determine whether the hash value in the data packet to be verified is consistent with the original hash value stored on the blockchain network. If they are consistent, the first verification condition is met. Determine whether the format of the data packet to be verified conforms to the preset format specification. If it does, the second verification condition is met. The zero-knowledge proof verification algorithm is used to check whether the zero-knowledge proof is valid. If it is valid, the third verification condition is satisfied. When the first, second, and third verification conditions are all met, the verification request is considered successful.

[0007] In one possible implementation of the first aspect, all key operations of the data verification contract and the permission management contract include: The data verification contract includes all verification operations and results performed when verifying zero-knowledge proofs and verification request information; The access control contract controls all modification operations and results issued when modifying the data access permissions of the battery pack manufacturer.

[0008] In one possible implementation of the first aspect, the metadata packet generation operation includes: The encrypted data packet is split into multiple data fragments, and the content identifier generator is used to calculate the hash value of each data fragment to obtain the content identifier corresponding to each data fragment. Based on each content identifier, the corresponding meta data packet is obtained.

[0009] In one possible implementation of the first aspect, the battery's full lifecycle information is traced based on log records in the blockchain network, including: Based on the identifier of the data packet to be verified, the corresponding metadata data packet on the blockchain network is located using a metadata hash retriever; Based on the metadata, all log records and encrypted data packets of the metadata are integrated through the operation log association engine; The matched metadata, log records, and encrypted data packets are integrated into a standardized graph data structure; Battery information is traced throughout its entire lifecycle based on a standardized graph data structure.

[0010] To address the same technical problem, a second aspect of this invention provides a blockchain-based battery lifecycle data traceability system, comprising: The verification request receiving module is used to receive verification request information sent by the battery pack manufacturer. The verification request information includes at least the identifier of the data packet to be verified and the data packet to be verified. The zero-knowledge proof generation module is used to retrieve the corresponding battery parameter data from the storage server based on the identifier of the data packet to be verified, process it, and obtain the zero-knowledge proof. The battery parameter data is the parameter data collected at any stage from the battery manufacturing stage to the battery application stage. The log generation module is used to send zero-knowledge proof and verification request information to the data verification contract for verification. If the verification is successful, the permission management contract is called to modify the data access permissions of the battery pack manufacturer, and the audit trail contract is called to collect all key operations of the data verification contract and the permission management contract. All key operations are sent to the blockchain network to generate log records. The information traceability module is used to trace the battery's information throughout its entire lifecycle based on log records in the blockchain network.

[0011] In one possible implementation of the second aspect, an encryption module, an encrypted data packet construction module, and a blockchain writing module are also included, wherein, The encryption module is used to acquire battery parameter data, encrypt the battery parameter data, and obtain ciphertext data. The encrypted data packet construction unit is used to calculate the original hash value of the battery parameter data and constructs an encrypted data packet based on the battery parameter data, the data ciphertext, the original hash value, and the timestamp generated by the battery parameter data. The blockchain writing module is used to send encrypted data packets to the storage server, so that the storage server can perform a metadata packet generation operation on the encrypted data packets and write the metadata packets into the mapping table of the blockchain network.

[0012] A third aspect of the present invention provides a computer device, comprising: Memory, used to store computer programs; A processor, used to execute computer programs to implement steps of a blockchain-based battery lifecycle data traceability method as described in the first aspect.

[0013] A fourth aspect of the present invention provides a storage medium storing a computer program, which, when executed by a processor, implements the steps of the blockchain-based battery lifecycle data traceability method of the first aspect.

[0014] The technical solution of this invention has the following advantages: The battery lifecycle data traceability method based on blockchain provided in this invention sends encrypted data packets to battery pack manufacturers and receives verification request information from them. Based on the verification request, it retrieves corresponding battery parameter data from a storage server, processes it to generate a zero-knowledge proof, and then submits the zero-knowledge proof, encrypted data packets, and verification request information to a data verification contract for verification. Upon successful verification, it calls a permission management contract to modify the manufacturer's access permissions. Simultaneously, it collects key operations through an audit tracking contract and uploads them to the blockchain to generate log records. Finally, based on the log records in the blockchain network, it achieves secure and traceable querying of battery cell lifecycle information, ensuring both data privacy and the reliability and efficiency of the lifecycle information traceability process. Attached Figure Description

[0015] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating the traceability process of the blockchain-based battery lifecycle data traceability method in this embodiment of the invention. Figures 2A-2B This is a flowchart illustrating the full-stage full-lifecycle data traceability process of the blockchain-based battery full-lifecycle data traceability method in this embodiment of the invention. Figure 3 This is a system block diagram of a blockchain-based battery lifecycle data traceability system in an embodiment of the present invention; Figure reference numerals: 300, Blockchain-based battery lifecycle data traceability system; 301, Verification request receiving module; 302, Zero-knowledge proof generation module; 303, Log recording generation module; 304, Metadata package generation module; 305, Information traceability module. Detailed Implementation

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

[0018] The battery lifecycle data traceability method based on blockchain provided in this invention embodiment, such as... Figure 1 As shown, Figure 1 The flowchart of the blockchain-based battery lifecycle data traceability method includes steps S101 to S104, and the specific steps are as follows: S101. Receive verification request information sent by the battery pack manufacturer, wherein the verification request information includes at least the identifier of the data packet to be verified and the data packet to be verified.

[0019] In this embodiment, the verification request information refers to a verification request submitted to the blockchain by the verification party, such as the battery pack manufacturer. This verification request includes an identifier for the batch of data to be verified, a data packet to be verified, and a public parameter string. Before verification, battery parameter data collected by the cell manufacturer throughout the entire battery lifecycle, from production to vehicle application, is uploaded to the blockchain. This involves encrypting the battery parameter data to obtain an encrypted data packet, which is then stored in a storage server. During the generation of the metadata data packet, the storage server extracts and uploads the encrypted data packet to the blockchain for verification. This encrypted data packet will serve as the basic unit for subsequent cross-enterprise transmission and verification. The data packet to be verified refers to the original data of the same batch of battery packs that the battery pack manufacturer retrieves locally during production or maintenance to generate the data packet for the batch to be verified. The generation logic of the data packet to be verified is the same as the generation logic of the previously stored encrypted data packet.

[0020] In one embodiment, before receiving the verification request information sent by the battery pack manufacturer, the method further includes: Obtain battery parameter data, encrypt the battery parameter data, and obtain ciphertext data; Calculate the original hash value of the battery parameter data, and construct an encrypted data packet based on the battery parameter data, the encrypted data, the original hash value, and the timestamp generated by the battery parameter data; The encrypted data packet is sent to the storage server, which then performs a metadata packet generation operation on the encrypted data packet and writes the metadata packet into the mapping table of the blockchain network.

[0021] In this embodiment, the collected battery parameter data spans the entire lifecycle of the battery, from the production stage to the vehicle application stage. The entire lifecycle includes various stages from production to vehicle application, with each stage corresponding to multiple parameter data. For example, the cell production stage includes raw material procurement data, cell electrode fabrication data, and cell performance parameter data. Figures 2A-2B As shown, taking the battery parameter data obtained as cell performance parameter data as an example, in the cell production workshop, 5G industrial gateways and industrial IoT terminals are deployed to collect cell performance parameter data in real time, such as capacity, internal resistance, and cycle count. The collected cell performance parameter data is sent to an enterprise-level key management system, where an asymmetric encryption algorithm stored in the system is used to encrypt the data, resulting in ciphertext. Simultaneously or subsequently, a Field-Programmable Gate Array (FPGA) accelerator card is used to perform real-time hash calculations on the cell performance parameter data, generating a unique digital fingerprint, i.e., the original hash value. The use of the FPGA accelerator card ensures high throughput and low latency, meeting the real-time requirements of industrial production. Finally, the ciphertext, hash value, timestamp, and cell performance parameter data are encapsulated into a structured encrypted data packet. For each batch of cell performance parameter data, an independent encrypted channel is generated for the resulting encrypted data packet, and a data packet lifespan is set.

[0022] It should be noted that the core of the enterprise-level key management system is a national standard-compliant HSM (Hardware Security Module), used for secure storage and management of asymmetric encryption algorithms. Raw data is encrypted internally within the HSM using a private key, ensuring the private key never leaves the secure hardware, thus physically eliminating the risk of leakage. The preferred asymmetric encryption algorithm is RSA 4096, and the preferred hash algorithm is SHA-3. In practical applications, based on performance, hardware environment, and cost requirements, these can be replaced with other equivalent algorithms, including but not limited to ECC (Elliptic Curve Cryptography) elliptic curve encryption algorithms. Hash algorithms include, but are not limited to, BLAKE-3 and the SM3 national standard algorithm. The core of the enterprise-level key management system can be replaced with a TEE (Trusted Execution Environment).

[0023] It's important to note that the original hash value refers to the hash value obtained by the cell manufacturer when generating encrypted data packets by performing a hash operation on the original parameter data. This hash value, as part of the metadata, is extracted and stored on the blockchain by the storage server during the metadata generation process of the encrypted data packets. Specifically, after the encrypted data packets are generated, they are simultaneously sent to the storage server. The storage server parses the hash field from the data packets and writes it into the blockchain mapping table. This mapping table, as an on-chain storage structure, records the original hash value corresponding to each batch of data. The original hash value compared by the data verification contract during the verification phase comes from the on-chain stored data, not off-chain data, thus ensuring its immutability, consistency, and uniqueness.

[0024] This embodiment integrates data encryption and fingerprint generation into a tightly coupled hardware-level operation through the collaboration of the HSM isolation chamber and the FPGA acceleration card. This fundamentally avoids timing attack vulnerabilities and ensures the atomicity and security of the operation. Furthermore, this encryption process is customized for upstream and downstream enterprises. For example, cell manufacturers use RSA encryption to ensure absolute security of ownership and ultimate traceability, while battery pack manufacturers only need to use the publicly available SHA-3 hash value for verification and calculation in their daily operations, without needing to decrypt the original data. This layered mechanism of encryption isolation and hash circulation achieves the goal of data being usable but not visible, representing a key innovation in resolving the contradiction between data privacy and usability.

[0025] S102. Based on the identifier of the data packet to be verified, retrieve the corresponding battery parameter data from the storage server for processing to obtain a zero-knowledge proof. The battery parameter data is the parameter data collected at any stage from the battery manufacturing stage to the battery application stage.

[0026] In this embodiment, during data verification, an off-chain-on-chain collaborative verification process based on the zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) algorithm deeply binds the generation and verification process of zero-knowledge proofs with smart contract execution, forming a closed-loop technology. For example, when a battery pack company acts as the verifier, it first initiates a verification request to the data verification contract in the blockchain network. This verification request includes the identifier of the data batch to be verified and the data packet to be verified. In addition, according to the requirements of the zero-knowledge proof algorithm, parameters such as public reference strings also need to be submitted. The cell manufacturer, as an authorized node of the blockchain consortium chain, subscribes to all events in the blockchain in advance, such as the verification request event of the data verification contract. When the blockchain receives the verification request submitted by the battery pack company, the cell manufacturer captures the verification request and its accompanying parameters in real time. Then, the cell manufacturer executes the zero-knowledge proof generation process locally. Specifically, it uses its own raw data, namely the cell performance parameter data, as private input, combined with the corresponding algorithm, to generate a concise, non-interactive zero-knowledge proof. During this process, the original data itself will never be transmitted or exposed.

[0027] In practical applications, cross-enterprise data verification involves four workflows: battery pack companies deploying zero-knowledge proof verification nodes, establishing an attribute-based access control model, obtaining cell quality standard parameters through off-chain oracles, and performing validity verification. The verification server must be configured with at least an Intel Xeon Gold 6348 processor, deploy a dedicated TLS 1.3 encrypted tunnel, and establish a dynamic whitelist mechanism. A retransmission protocol is automatically triggered upon verification failure, and anti-DDoS (Distributed Denial of Service) attack strategies are configured.

[0028] It should be noted that the preferred zero-knowledge proof algorithm is the Groth 16 zero-knowledge proof algorithm. In practical applications, it can be replaced by Bulletproofs (a non-interactive zero-knowledge proof protocol without trust settings) or PLONK (Permutations over Lagrange-bases for Oecumenical Non-interactive arguments of Knowledge) universal verification systems, depending on performance, hardware environment, and cost requirements.

[0029] S103. Send the zero-knowledge proof and verification request information to the data verification contract for verification. If the verification is successful, call the permission management contract to modify the data access permissions of the battery pack manufacturer, and call the audit trail contract to collect all key operations of the data verification contract and the permission management contract. Send all key operations to the blockchain network and generate log records.

[0030] In this embodiment, a three-layer smart contract architecture is designed in the blockchain network, including a data verification contract, a permission management contract, and an audit trail contract. Through functional decoupling and logical coordination, refined and automated management of the entire data lifecycle is achieved. Specifically, the data verification contract is used for hash value verification and validity verification; the permission management contract dynamically controls data access permissions; and the audit trail contract records data operation events, including timestamps and operator digital signatures. Specifically, zero-knowledge proofs, encrypted data packets, and verification request information are sent to the data verification contract for verification. If the verification passes, the permission management contract modifies the battery pack manufacturer's data access permissions and uses the audit trail contract to collect all key operations of the data verification contract and the permission management contract. Once a key operation is captured, the audit trail contract immediately generates a structured log record on the chain. This log record includes the event type and clearly records the nature of the operation.

[0031] Access control contracts are used for dynamic access control. During deployment, these contracts define various roles within the system (such as cell manufacturers, battery pack companies, and regulators) and associated attributes (such as company ID, accessible data types, and access permission levels). Instead of using a static permission list, they subscribe to and respond to events from data verification contracts. Upon receiving a verification pass event, they automatically activate temporary or permanent access permissions for that specific batch of data for the verifying party, based on the event content.

[0032] When any user or contract attempts to call a protected data interface or function, the request is first intercepted by this access control contract. The contract checks the caller's address, role / attributes, and whether the requested data batch is in an "authorized" state. If all checks pass, the access control contract forwards the request to the target function for permission modification; otherwise, the request is rejected and an error message is returned, thus reducing the rate of permission misuse to a low level.

[0033] It should be noted that the three-layer smart contracts are primarily written in Solidity and run on the Ethereum Virtual Machine (EVM). Solidity is a high-level contract-oriented language. In practical applications, the programming language for the three-layer smart contracts includes, but is not limited to, TinyXML (a lightweight, extensible markup language). The interaction logic of the three-layer contract group is preferably in the Ethereum public chain mode. In practical applications, a single-contract state machine mode can also be used for data verification, permission modification, and auditing.

[0034] In one embodiment, sending zero-knowledge proof and verification request information to a data verification contract for verification includes: The zero-knowledge proof and verification request information are sent to the data verification contract, causing the data verification contract to perform verification operations, which include: Determine whether the hash value in the data packet to be verified is consistent with the original hash value stored on the blockchain network. If they are consistent, the first verification condition is met. Determine whether the format of the data packet to be verified conforms to the preset format specification. If it does, the second verification condition is met. The zero-knowledge proof verification algorithm is used to check whether the zero-knowledge proof is valid. If it is valid, the third verification condition is satisfied. When the first, second, and third verification conditions are all met, the verification request is considered successful.

[0035] In this embodiment, the data verification contract primarily verifies two types of data: first, the integrity of the data packet, achieved by comparing data hash values; and second, the business validity of the data, achieved through zero-knowledge proof verification. Specifically, when an encrypted data packet is first uploaded to the blockchain, its metadata is recorded on the blockchain. Any subsequent reference or operation to this data must submit its hash value. The data verification contract compares the submitted hash value with the original hash value stored on the chain; if they match, the verification is successful. Simultaneously, the data verification contract also determines whether the structure of the encrypted data packet conforms to predefined specifications, ensuring that all fields are complete and correctly formatted. During zero-knowledge proof validity verification, the zk-SNARKs verification algorithm is executed to determine whether the data meets specific business rules.

[0036] It's important to note that the encrypted data packets are structured and encapsulated, containing multiple fixed fields. The contract verifies the integrity and format of each field. For example, if the encrypted data is a string with a length conforming to the RSA 4096 encryption standard, the contract checks its existence, length, and whether there are any garbled characters. The hash value is a 64-bit hexadecimal string; the contract checks its presence in the encrypted data packet, its hexadecimal format, and its accurate length. The data batch identifier consists of numbers and letters with a fixed length of 20 characters; the contract checks its existence and whether its character type and length conform to the agreement.

[0037] Specific business rules can be understood as quality standards or collaboration requirements in the battery industry, such as cell capacity ≥200Ah, internal resistance ≤50mΩ, and cycle count ≥1000 times. These rules have been converted into arithmetic constraints that can be recognized by the zk-SNARKs algorithm in advance and synchronized to the data verification contract.

[0038] In one embodiment, all key operations of the data verification contract and the permission management contract include: The data verification contract includes all verification operations and results performed when verifying zero-knowledge proofs and verification request information; The access control contract controls all modification operations and results issued when modifying the data access permissions of the battery pack manufacturer.

[0039] In this embodiment, the audit trail contract is responsible for recording all key operations, providing irrefutable evidence for tracing and auditing. Specifically, the audit trail contract listens for and captures all predefined events issued by the data verification contract and the permission management contract through the event mechanism of the Ethereum Virtual Machine. All key operations include, but are not limited to, the operation of the cell manufacturer generating encrypted data packets; the operation of storing the metadata (hash value, batch identifier, manufacturer signature) corresponding to the encrypted data packets on the blockchain; the operation of the battery pack company submitting a verification request to the data verification contract; the operation of the cell manufacturer generating a zero-knowledge proof off-chain and submitting it to the data verification contract after receiving the verification request; the operation of the data verification contract performing hash value comparison, ZKP validity verification, and data packet structure verification; after the verification is passed, the data verification contract calls the permission management contract to activate the corresponding data access permissions of the battery pack company; the permission management contract intercepts data access requests, performs permission verification, and permission modification operations, etc.

[0040] In one embodiment, the metadata packet generation operation includes: The encrypted data packet is split into multiple data fragments, and the content identifier generator is used to calculate the hash value of each data fragment to obtain the content identifier corresponding to each data fragment. Based on each content identifier, the corresponding meta data packet is obtained.

[0041] In this embodiment, a hybrid storage topology is used to store encrypted data packets in a storage server. The storage server performs a metadata generation operation on the encrypted data packets and writes the metadata packets into the mapping table of the blockchain network, thereby realizing distributed storage and on-chain metadata. This hybrid storage topology is a physical connection structure between IPFS (InterPlanetary File System) fragmented storage nodes and blockchain metadata anchors. Specifically, the storage server automatically divides the encrypted data packets into multiple data fragments, denoted as fragment 1 to fragment N, according to the IPFS default sharding rules or patented custom rules, such as 256KB / shard. Each fragment contains only partial ciphertext information and cannot reconstruct the complete encrypted data packet. The storage server's built-in CID (Content Identifier) ​​generator performs a SHA-256 hash algorithm on each data fragment individually to generate a unique hash value for each data fragment. The Multihash algorithm is used to calculate the hash value of each data fragment, ultimately generating the content identifier for each fragment, such as CID1 corresponding to data fragment 1, CID2 corresponding to data fragment 2. The CID is the core index for subsequent data retrieval and association with on-chain metadata.

[0042] As a storage node in the IPFS network, the storage server distributes multiple generated data fragments and their corresponding CIDs to other storage nodes in the IPFS network via a pre-defined protocol, such as P2P (Peer-to-Peer). After IPFS completes fragmented storage, the metadata needs to be anchored to the blockchain to form a "on-chain metadata - off-chain IPFS data" association, ensuring data traceability. The storage server extracts core metadata from the encrypted data packets and the IPFS fragmented storage results to form metadata packets, such as the hash value of the encrypted data packets, content identifiers of all data fragments, data batch identifiers, storage timestamps, and the storage server's digital signature. The metadata packets only contain the above index information and do not involve any original data or complete ciphertext. Then, the storage server sends the extracted metadata packets to the blockchain gateway through a secure channel, initiating a request to upload the metadata packets to the blockchain, and simultaneously submitting its own digital signature. The digital signature is used by the gateway to verify the legitimacy of the metadata source. After the metadata is uploaded to the blockchain, the blockchain network generates a corresponding block. The blockchain gateway synchronizes the block height information from the blockchain nodes. The blockchain gateway has a built-in LSM-Tree index engine that establishes key-value pairs between the CID of each data fragment and the height of the block containing the metadata, such as key: CID1, value: block height 10000. The blockchain gateway synchronizes the constructed CID-block height mapping table to other gateway nodes to achieve multi-node backup and avoid index loss due to gateway failure.

[0043] It should be noted that LSM-Tree supports efficient write and query operations through a layered structure of "memory log + ordered disk storage". When it is necessary to query the metadata data packet through CID later, the gateway can quickly locate the block height where the metadata is located through LSM-Tree without traversing the entire blockchain ledger, and the query latency can be controlled in the millisecond level.

[0044] S104. Based on the log records in the blockchain network, trace the battery's information throughout its entire lifecycle.

[0045] In this embodiment, the traceability link, which consists of a metadata hash retrieval engine, an operation log association engine, and a visualization graph generator, relies on the following technologies: a fast hash positioning algorithm based on Merkle Patricia Trie (MPT) for operation events, a strong association mapping rule for blockchain transaction numbers, a D3.js engine, and a real-time data channel with an off-chain database.

[0046] In one embodiment, the battery's full lifecycle information is traced based on log records in the blockchain network, including: Based on the identifier of the data packet to be verified, the corresponding metadata data packet on the blockchain network is located using a metadata hash retriever; Based on the metadata, all log records and encrypted data packets of the metadata are integrated through the operation log association engine; The matched metadata, log records, and encrypted data packets are integrated into a standardized graph data structure; Battery information is traced throughout its entire lifecycle based on a standardized graph data structure.

[0047] In this embodiment, when an authorized entity, such as a battery pack manufacturer, needs to trace data from a certain batch of batteries, it first inputs traceability conditions into the traceability system interface, such as the identifier of the data packet to be verified, the cell serial number, and the time range. The system automatically converts the conditions into a metadata hash retrieval request. Based on the MPT fast hash positioning algorithm, it locates the metadata packet from the MPT tree of the blockchain. After obtaining the metadata packet, the operation log association engine integrates the log records of the entire data lifecycle. The operation log association engine extracts the IPFS data fragment CID list from the metadata and initiates a data fragment shard acquisition request to the IPFS distributed storage node. The node locates and returns the corresponding encrypted data packet fragment through the CID. The engine merges the encrypted data packet fragments into the target encrypted data packet. The target metadata packet, log records, and target encrypted data packet are integrated into a full traceability dataset and synchronized to the off-chain database through the D3.js real-time data channel. Finally, the visualization graph generator builds an interactive visualization interface based on the D3.js engine, transforming complex traceability data into intuitive graphs, time series diagrams, etc., making it convenient for authorized entities to quickly understand the entire data lifecycle flow.

[0048] This embodiment achieves data storage security and traceability for the entire life cycle of power batteries through a closed-loop technology system of encrypted transmission, intelligent verification, trusted evidence storage, and precise traceability.

[0049] The battery lifecycle data traceability system based on blockchain provided in this embodiment of the invention, such as... Figure 3 As shown, Figure 3 The system block diagram of the blockchain-based battery lifecycle data traceability system 300 includes: The verification request receiving module 301 is used to receive verification request information sent by the battery pack manufacturer, wherein the verification request information includes at least an identifier of the data packet to be verified and the data packet to be verified; The zero-knowledge proof generation module 302 is used to retrieve the corresponding battery parameter data from the storage server based on the identifier of the data packet to be verified, and process it to obtain the zero-knowledge proof. The battery parameter data is the parameter data collected in any stage from the battery manufacturing stage to the battery application stage. The log generation module 303 is used to send zero-knowledge proof and verification request information to the data verification contract for verification. If the verification is successful, the permission management contract is called to modify the data access permissions of the battery pack manufacturer, and the audit trail contract is called to collect all key operations of the data verification contract and the permission management contract. All key operations are sent to the blockchain network to generate log records. The information traceability module 304 is used to trace the battery's information throughout its entire lifecycle based on log records in the blockchain network.

[0050] In one embodiment, it further includes an encryption module, an encrypted data packet construction module, and a blockchain writing module, wherein, The encryption module is used to acquire battery parameter data, encrypt the battery parameter data, and obtain ciphertext data. The encrypted data packet construction unit is used to calculate the original hash value of the battery parameter data and constructs an encrypted data packet based on the battery parameter data, the data ciphertext, the original hash value, and the timestamp generated by the battery parameter data. The blockchain writing module is used to send encrypted data packets to the storage server, so that the storage server can perform a metadata packet generation operation on the encrypted data packets and write the metadata packets into the mapping table of the blockchain network.

[0051] The specific implementation of the blockchain-based battery life cycle data traceability system is basically the same as the specific implementation of the blockchain-based battery life cycle data traceability method described above, and will not be repeated here.

[0052] In one embodiment of this application, a computer device is provided, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above steps. The implementation principle and technical effects of the computer device provided in this embodiment are similar to those of the above method embodiments, and will not be repeated here.

[0053] In one embodiment of this application, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, it performs the above steps; the implementation principle and technical effects of the computer-readable storage medium provided in this embodiment are similar to those of the above method embodiments, and will not be repeated here.

[0054] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0055] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A blockchain-based method for tracing battery lifecycle data, characterized in that, include: Receive verification request information sent by the battery pack manufacturer, wherein the verification request information includes at least an identifier of the data packet to be verified and the data packet to be verified; Based on the identifier of the data packet to be verified, the corresponding battery parameter data is retrieved from the storage server for processing to obtain a zero-knowledge proof. The battery parameter data is parameter data collected at any stage from the battery manufacturing stage to the battery application stage. The zero-knowledge proof and the verification request information are sent to the data verification contract for verification. If the verification is successful, the permission management contract is invoked to modify the data access permissions of the battery pack manufacturer, and the audit trail contract is invoked to collect all key operations of the data verification contract and the permission management contract. All key operations are sent to the blockchain network to generate log records. Based on the log records in the blockchain network, the battery's full lifecycle information can be traced.

2. The blockchain-based battery lifecycle data traceability method as described in claim 1, characterized in that, Before receiving the verification request information sent by the battery pack manufacturer, the method further includes: Obtain the battery parameter data, encrypt the battery parameter data, and obtain ciphertext data; Calculate the original hash value of the battery parameter data, and construct an encrypted data packet based on the battery parameter data, the encrypted data, the original hash value, and the timestamp generated by the battery parameter data; The encrypted data packet is sent to the storage server, so that the storage server performs a metadata packet generation operation on the encrypted data packet and writes the metadata packet into the mapping table of the blockchain network.

3. The blockchain-based battery lifecycle data traceability method as described in claim 2, characterized in that, The step of sending the zero-knowledge proof and the verification request information to the data verification contract for verification includes: The zero-knowledge proof and the verification request information are sent to the data verification contract, causing the data verification contract to perform a verification operation, wherein the verification operation includes: Determine whether the hash value in the data packet to be verified is consistent with the original hash value stored on the blockchain network. If they are consistent, the first verification condition is met. Determine whether the format of the data packet to be verified conforms to the preset format specification. If it does, the second verification condition is met. The zero-knowledge proof is checked for validity using a zero-knowledge proof verification algorithm. If valid, the third verification condition is met. When the first verification condition, the second verification condition, and the third verification condition are all met, the verification request is considered to have passed.

4. The blockchain-based battery lifecycle data traceability method as described in claim 1, characterized in that, All key operations of the data verification contract and the permission management contract include: The data verification contract performs all verification operations and verifies the zero-knowledge proof and the verification request information. The permission management contract issues all modification operations and modification results when modifying the data access permissions of the battery pack manufacturer.

5. The blockchain-based battery lifecycle data traceability method as described in claim 2, characterized in that, The metadata generation operation includes: The encrypted data packet is split into multiple data fragments, and a content identifier generator is used to calculate the hash value of each data fragment to obtain the content identifier corresponding to each data fragment. Based on each of the aforementioned content identifiers, the corresponding metadata packets are obtained.

6. The blockchain-based battery lifecycle data traceability method as described in claim 1, characterized in that, The step of tracing the battery cell's full lifecycle information based on the log records in the blockchain network includes: Based on the identifier of the data packet to be verified, the corresponding metadata data packet is located on the blockchain network using a metadata hash retrieval tool; Based on the metadata, all the log records and the encrypted data packets of the metadata are integrated through the operation log association engine; The matched metadata packets, log records, and encrypted data packets are integrated into a standardized graph data structure; The battery's full lifecycle information is traced based on the standardized graph data structure.

7. A blockchain-based battery lifecycle data traceability system, characterized in that, include: The verification request receiving module is used to receive verification request information sent by the battery pack manufacturer, wherein the verification request information includes at least an identifier of the data packet to be verified and the data packet to be verified; The zero-knowledge proof generation module is used to retrieve the corresponding battery parameter data from the storage server based on the identifier of the data packet to be verified, process it, and obtain the zero-knowledge proof. The battery parameter data is parameter data collected in any stage from the battery manufacturing stage to the battery application stage. The log generation module is used to send the zero-knowledge proof and the verification request information to the data verification contract for verification. If the verification is successful, the module calls the permission management contract to modify the data access permissions of the battery pack manufacturer, and calls the audit trail contract to collect all key operations of the data verification contract and the permission management contract. All key operations are then sent to the blockchain network to generate log records. The information traceability module is used to trace the battery throughout its entire lifecycle based on the log records in the blockchain network.

8. The blockchain-based battery lifecycle data traceability system as described in claim 7, characterized in that, It also includes an encryption module, an encrypted data packet construction module, and a blockchain writing module, among which, The encryption module is used to acquire the battery parameter data, encrypt the battery parameter data, and obtain ciphertext data. The encrypted data packet construction unit is used to calculate the original hash value of the battery parameter data, and construct an encrypted data packet based on the battery parameter data, the data ciphertext, the original hash value, and the timestamp generated by the battery parameter data; The blockchain writing module is used to send the encrypted data packet to the storage server, so that the storage server performs a metadata packet generation operation on the encrypted data packet and writes the metadata packet into the mapping table of the blockchain network.

9. A computer device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the blockchain-based battery lifecycle data traceability method as described in any one of claims 1 to 6 when executing the computer program.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the steps of the blockchain-based battery lifecycle data traceability method as described in any one of claims 1 to 6.

Images