Battery data query system application method based on cross-chain index and zero knowledge verification

Abstract

The invention discloses a battery data query system application method based on cross-chain index and zero knowledge verification, and relates to the field of block chain energy storage, and the method comprises the following steps: a user submits a query request; the aggregation querier and the verification engine query the battery DID from a battery global identity registry, obtain each block chain address list, and send a standardized query request to a cross-chain verification relay of each block chain in the list in parallel; accessing local chain data by each cross-chain verification relay, and generating and returning zero-knowledge proof; and the aggregation querier and the verification engine verify the validity of all certificates, determine unique and credible timestamps and state data by using an intelligent conflict judgment mechanism aiming at possible conflicts, and integrate the verified data and a certification conclusion to generate a battery full-life-cycle credible report. According to the method, a battery data island in energy storage asset digitization is broken, and cross-chain query efficiency is improved while data credibility and privacy security are guaranteed.

Description

Technical Field

[0001] This application relates to the field of blockchain energy storage, and in particular to an application method for a battery data query system based on cross-chain indexing and zero-knowledge verification. Background Technology

[0002] With the advancement of dual-carbon goals, the number of power batteries and energy storage batteries has surged, making battery lifecycle management increasingly important. Currently, the industry typically adopts the concept of a "battery passport," using blockchain technology to record data throughout the entire battery lifecycle, from production and use to recycling. However, existing solutions have several key problems: Data silo problem: The life cycle of a battery involves multiple participants (cell manufacturers, vehicle manufacturers, energy storage operators, recycling companies, etc.). Each participant often chooses different blockchain systems (such as Hyperledger Fabric, Ethereum, Corda, etc.) based on its own needs, resulting in battery data being scattered and stored in different blockchains, forming data silos.

[0003] Inefficient querying: Existing solutions lack a unified query mechanism. To obtain complete lifecycle data for a battery, multiple blockchains need to be queried separately, a cumbersome and inefficient process. Third-party institutions (such as financial institutions and regulatory agencies) also find it difficult to quickly obtain comprehensive battery data.

[0004] Verification complexity: Even when data is obtained from different chains, verifying the authenticity and integrity of this data is a challenge. It requires verifying the consensus mechanism, digital signatures, and other aspects of each chain separately, and the verification cost increases linearly with the number of chains involved.

[0005] Insufficient privacy protection: How to protect the commercially sensitive information of each participant (such as transaction prices and core technical parameters) during the data aggregation process is an issue that has not yet been well resolved.

[0006] Lack of standardization: Currently, there is a lack of standard protocols for cross-chain data query and verification, making it difficult for various systems to interconnect and interoperate, which limits the value mining of battery life cycle data.

[0007] In some situations, while various cross-chain solutions exist, such as notary mechanisms, sidechains / relay chains, and hash locking, these solutions primarily focus on cross-chain asset transfers rather than cross-chain data querying and verification. For scenarios like battery lifecycle data, which require multi-party participation, long-term storage, and frequent queries, existing cross-chain technologies are clearly insufficient. Summary of the Invention

[0008] The purpose of this application is to provide a battery data query system application method based on cross-chain indexing and zero-knowledge verification, which can break down battery data silos in the digitization of energy storage assets and improve cross-chain query efficiency while ensuring data credibility and privacy security.

[0009] To achieve the above objectives, this application provides the following solution: Firstly, this application provides an application method for a battery data query system based on cross-chain indexing and zero-knowledge verification. The battery data query system includes: a global battery identity registry, a cross-chain verification relay, and an aggregation queryer and verification engine. The global battery identity registry is used to establish and maintain a dynamic mapping between battery DIDs and multiple blockchain addresses based on DPoS consensus and an economic staking model. The cross-chain verification relay is deployed on different blockchains in a pluggable adapter architecture, responding to standardized query requests and generating cryptographic proofs. The aggregation queryer and verification engine are used to query routing information from the global battery identity registry, initiate parallel query requests to the cross-chain verification relay, and verify response proofs and aggregated data. The application method includes: a user submitting a query request to the aggregation queryer and verification engine. The query request includes: the target battery DID and required data fields; the aggregate query engine and verification engine query the target battery DID from the global battery identity registry to obtain a list of all stored blockchain addresses; based on the address list, the aggregate query engine and verification engine send standardized query requests in parallel to the cross-chain verification relays on different blockchains; each cross-chain verification relay on each blockchain accesses local chain data, generates a cryptographic proof according to the request, and returns it; the cryptographic proof includes at least: zero-knowledge verification; the aggregate query engine and verification engine verify the validity of the cryptographic proof, using the blockchain as a data source, and employing a smart conflict resolution mechanism based on dynamic weights to determine a unique timestamp and corresponding state data; the aggregate query engine generates a battery lifecycle report based on the unique timestamps and corresponding state data of each blockchain and the conclusion of the cryptographic proof.

[0010] Secondly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described application method for a battery data query system based on cross-chain indexing and zero-knowledge verification.

[0011] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application constructs a global index through the Global Battery Identity Registry (GBIR) and establishes a dynamic mapping between battery digital identities and multi-chain addresses based on DPoS consensus and an economic staking model, effectively solving the data silo problem. The Cross-Chain Verification Relay (CCVR) adopts a pluggable adapter architecture deployed on various blockchains, responding to query requests through standardized interfaces and generating cryptographic proofs, including zero-knowledge proofs, ensuring data trustworthiness while protecting commercially sensitive information. The Aggregator & Verification Engine (AVE) first queries the registry to obtain routing information, then sends requests to each verification relay in parallel, verifies cryptographic proofs, and uses a smart conflict resolution mechanism based on dynamic weights to resolve data inconsistencies, ultimately generating a trusted battery lifecycle report. A complete cross-chain query and verification protocol enables interoperability between heterogeneous blockchain systems, automating the traditional manual cross-chain query and verification process and improving query and verification efficiency. In summary, this application breaks down battery data silos in the digitization of energy storage assets, improving cross-chain query efficiency while ensuring data trustworthiness and privacy security. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0013] Figure 1 A flowchart illustrating the application method of the battery data query system based on cross-chain indexing and zero-knowledge verification provided in this application embodiment. Figure 1 .

[0014] Figure 2 This is a schematic diagram of the overall architecture of the battery data query system based on cross-chain indexing and zero-knowledge verification provided in the embodiments of this application.

[0015] Figure 3 This is a sequence diagram of cross-chain query and verification provided in the embodiments of this application.

[0016] Figure 4 A flowchart illustrating the application method of the battery data query system based on cross-chain indexing and zero-knowledge verification provided in this application embodiment. Figure 2 .

[0017] Figure 5This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0019] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] Example 1, such as Figures 1-4 As shown, this embodiment provides an application method for a battery data query system based on cross-chain indexing and zero-knowledge verification. The battery data query system based on cross-chain indexing and zero-knowledge verification includes: a global battery identity registry, a cross-chain verification relay, and an aggregation queryer and verification engine. The global battery identity registry is used to establish and maintain a dynamic mapping between battery DIDs (Decentralized Identifiers) and multiple blockchain addresses based on DPoS (Delegated Proof of Stake) consensus and economic staking model. The cross-chain verification relay is used to deploy on different blockchains in the form of a pluggable adapter architecture, and respond to standardized query requests and generate cryptographic proofs. The aggregation queryer and verification engine are used to query routing information from the global battery identity registry, initiate query requests in parallel to the cross-chain verification relay, and verify the response proofs and aggregated data. The application method includes the following steps.

[0021] S1. The user submits a query request to the aggregate query engine and the verification engine; the query request includes: the target battery DID and the required data fields.

[0022] Furthermore, the query request is a four-tuple structure, represented as: Record=(DID, Chain_Info, Timestamp, Signature); where DID is the battery's unique digital identity identifier; Chain_Info is the blockchain information of the battery data, including: chain type, gateway address, and query interface; Timestamp is the registration timestamp; and Signature is the registrant's digital signature.

[0023] Optionally, DID adopts the W3C DID standard.

[0024] In practical applications, Chain_Info, Timestamp, and Signature constitute the required data fields.

[0025] Furthermore, the registration mechanism of the global battery identity registry includes: when the battery data of a target battery is recorded on a blockchain for the first time, the gateway node of that blockchain needs to register with the global battery identity registry: Register(DID, Chain_Info, Stake) → Tx_Hash. At the same time, the registration process requires collateral and payment of a preset transaction fee to prevent Sybil attacks.

[0026] Optionally, a Sybil attack is a security threat to distributed networks in which attackers manipulate the system by creating numerous fake identities (such as nodes or users). Its core harm lies in disrupting mechanisms based on the majority principle: in blockchain, attackers can use fake identities to influence voting consensus or monopolize network resources; in P2P networks, they can manipulate data routing and storage.

[0027] Optionally, the default fee is a token-based query fee.

[0028] In practical applications, the global battery identity registry is a lightweight distributed ledger optimized for high-frequency index queries. Its main function is to maintain a dynamic mapping relationship between battery DIDs and the blockchain addresses that store their data, acting as a global routing directory.

[0029] Innovative mapping methods and consensus mechanisms: The Global Battery Identity Registry adopts a modified Merkel-Patricia Trie (MPT) structure for storing the mapping (DID->List[Chain_Info]), supporting efficient querying and traversal. A Delegated Proof-of-Stake (DPoS) consensus mechanism is employed, optimized for the high throughput and low latency requirements of index registration and querying. Consensus nodes are provided by key participants within the ecosystem (such as industry associations and well-known battery manufacturers). A Bloom filter is integrated before the query interface to quickly predict whether a given DID has already been registered with GBIR, significantly improving query efficiency.

[0030] The specific registration and economic model for attack resistance is as follows.

[0031] Registration Mechanism: Any blockchain gateway wishing to register a battery DID must execute the Register(DID,Chain_Info,Stake) operation and pledge a certain amount of system tokens as security collateral.

[0032] Economic model: The "pledge-credit-fee" ternary model is adopted.

[0033] 1) Staking: To prevent witch attacks, malicious registration will result in the forfeiture of staked assets.

[0034] 2) Reputation: After registration, the number of queries and the validity of the data will accumulate reputation points for that data source. High-reputation data sources can receive discounts on query fees.

[0035] 3) Costs: Data queryers pay a small fee, which is allocated to the GBIR maintenance nodes and the data source providers. This economic model ensures the long-term sustainability and security of the system.

[0036] In addition, the global battery identity registry provides a standard query interface: Query(DID) → List[Chain_Info].

[0037] Furthermore, cryptographic proofs also include: existence proofs of Merkle trees, zero-knowledge proofs based on zk-SNARKs, and aggregation signatures based on BLS.

[0038] S2. The aggregate query engine and verification engine query the target battery's DID from the global battery identity registry to obtain a list of all stored blockchain addresses.

[0039] S3. The aggregate query engine and verification engine send standardized query requests in parallel to cross-chain verification relays on different blockchains based on the address list.

[0040] S4. Cross-chain verification relays on each blockchain access local chain data, generate cryptographic proofs according to requests, and return them; the cryptographic proofs include at least: zero-knowledge verification.

[0041] Furthermore, the pluggable adapter architecture is a scalable architecture that is compatible with multiple blockchain types by defining a unified abstract interface.

[0042] In practical applications, the cross-chain verification relay is a pluggable, modular, standardized software package deployed on each participating blockchain gateway, and it is key to the implementation of the battery data cross-chain query protocol. Its core responsibility is to process standardized query requests and generate cryptographic proofs.

[0043] Pluggable Adapter Architecture: Define a unified abstract interface IChainConnector, including methods such as query(data_request) and generateProof(data). Develop specific adapter implementations (FabricAdapter, EthAdapter, etc.) for different types of blockchains (such as Fabric, Ethereum, Corda). This design makes the protocol highly scalable, allowing new chains to quickly connect simply by developing an adapter.

[0044] The multi-type proof generation engine specifically includes: existence proof, zero-knowledge proof, and aggregate signature support.

[0045] Existence proof: Based on the Merkle tree structure of each primitive chain, generate a Merkle proof π_merkle. The verification formula is: VerifyMerkleProof(leaf,π_merkle,root_hash)->bool.

[0046] Zero-Knowledge Proof (ZKP) service: Built-in zk-SNARKs circuit compiler support. Allows data providers to predefine privacy-preserving query strategies (e.g., SOH > 80%). When a query involves sensitive data, CCVR calls the ZK engine and executes `GenerateZKProof(constraint, private_data)->π_zk`. This proves that private data satisfies a public constraint without revealing the data itself. The verification formula is: `VerifyZKProof(π_zk, public_constraint, vk)->bool`.

[0047] Aggregated signature support: For publicly available data, aggregated signatures based on the BLS signature algorithm are supported, allowing verification of signatures from multiple data sources at once, greatly improving verification efficiency.

[0048] Query processing algorithm: CCVR receives standardized query requests in the following format.

[0049] json{"did":"Battery DID","requested_data":["List of data fields"],"proof_type":"Proof type","zk_proof":"Whether zero-knowledge proof is required"}.

[0050] S5. The aggregate query engine and verification engine verify the validity of cryptographic proofs, using the blockchain as a data source and employing a smart conflict resolution mechanism based on dynamic weights to determine unique timestamps and corresponding state data.

[0051] Furthermore, the intelligent conflict resolution mechanism based on dynamic weights specifically includes the following.

[0052] 1) Based on the historical accuracy, timestamp generation precision, and data source type, a weight calculation function is used to calculate the dynamic weight of the data source; data source types include: direct sensor data collection, system logs, and manual input.

[0053] 2) Substitute the dynamic weights of the conflicting timestamps and their corresponding data sources into the weighted average formula to calculate the unique timestamp; 3) The unique timestamp and corresponding status data will be used as the basis for the generation and application of subsequent battery life cycle reports.

[0054] Furthermore, the formula for calculating the dynamic weight of the data source is as follows.

[0055] .

[0056] In the formula, For data source Dynamic weights; For data source Historical accuracy and reputation (from GBIR); For data source The precision of the timestamp (e.g., 1.0 for milliseconds, 0.7 for seconds). For data source The weight of the data source type (1.0 for direct sensor data, 0.6 for system logs, and 0.3 for manual input). All of these are adjustable weighting coefficients.

[0057] Furthermore, the formula for calculating the unique timestamp is as follows.

[0058] .

[0059] In the formula, A unique timestamp; For data source The original timestamp; To be assigned to the data source The weights; The number of data sources; For data source The weight.

[0060] In practical applications, the aggregation query engine and verification engine are service platforms for end users, responsible for coordinating the execution of the entire battery data cross-chain query protocol process, and are the ultimate implementers of trusted aggregation.

[0061] The query aggregation algorithm has the following characteristics.

[0062] 1) Initialization and Route Query: The algorithm receives input parameters: the battery's Digital Identity (DID) and a list of data fields to be queried. First, the algorithm calls the query interface of the Global Registry (GBIR) to retrieve a list of network addresses of all blockchains storing the battery's data, based on the provided DID. This step aims to determine the target set to be queried.

[0063] 2) Sequential Traversal and Chain-Specific Connector Invocation: After obtaining the relevant blockchain list, the algorithm enters a sequential loop processing flow. For each blockchain configuration in the list, the algorithm retrieves a corresponding dedicated connector instance from a connector factory or registry, based on the blockchain type (e.g., Hyperledger Fabric, Ethereum, etc.). This connector encapsulates the protocol details for interacting with a specific type of blockchain.

[0064] 3) Query Execution and Result Collection: After obtaining a dedicated connector for the current blockchain, the algorithm invokes the connector's query method. This method sends a query request conforming to the target blockchain network's protocol format to retrieve the specified battery data. The results returned by each query are immediately added to a result list.

[0065] 4) Result return: After all blockchains have been traversed and queried in sequence, the algorithm obtains a raw list containing the query results of all blockchains, integrates, formats or further processes the raw data, and returns the final aggregated result to the caller.

[0066] The parallel query scheduling algorithm has the following characteristics.

[0067] 1) After receiving a user query request, AVE first queries GBIR to obtain a list L of all associated chain addresses of the target DID.

[0068] 2) Subsequently, AVE adopts an asynchronous parallel mode and simultaneously sends standardized query requests to the CCVR modules of all chains in list L.

[0069] 3) Set up a dynamic timeout mechanism to avoid dragging down overall performance due to slow response of a single chain.

[0070] The specific implementation process of the intelligent conflict resolution mechanism based on dynamic weights is as follows.

[0071] For conflict events, a weighted time window algorithm is used to ensure that the rulings tend to favor sources with more reliable historical data and higher quality.

[0072] The essence of timestamp conflict resolution is a weighted average algorithm. For example, a battery records an overheating event on Chain_A with a timestamp of 2025-09-02 10:00:05 (data source 1). The same battery also records this event on Chain_B, but with a timestamp of 2025-09-02 10:00:12 (data source 2). The two records differ by 7 seconds. This inconsistency in timestamps constitutes a timestamp conflict. Possible causes include: clock asynchrony: slight errors exist in the system clocks of different blockchain nodes; network latency: data packaging, broadcasting, and confirmation on the chain take time, and this latency varies across different networks; different recording triggering mechanisms: some chains record data in real-time from sensors, while others record data in batches every minute. Simply taking the first record or randomly selecting one is arbitrary and unscientific. Therefore, an intelligent algorithm that reflects the credibility of different data sources is needed to automatically determine the most reliable time. The core idea of ​​this algorithm is: historically more reliable and accurate data sources should be trusted more.

[0073] Weight It is a quantitative metric used to measure the credibility and reliability of timestamps provided by a data source (i.e., a blockchain). The weight can be assigned based on one or more of the following factors.

[0074] Data source reliability: High weight (w≈0.9): Data directly uploaded to the blockchain from high-precision, tamper-proof sensors. Medium weight (w≈0.6): Data indirectly uploaded to the blockchain from system logs. For example, data reported in batches periodically by a power plant monitoring system. Low weight (w≈0.3): Data uploaded to the blockchain after manual input. For example, maintenance records manually filled out by maintenance personnel.

[0075] Historical accuracy of a data source: If a data source frequently provides timestamps that are inconsistent with other high-quality sources in the past, its weight will be lowered by the system. If a data source has consistently high historical accuracy, its weight will be higher.

[0076] Timestamp generation precision: A timestamp recorded to the millisecond level should have a higher weight than a timestamp recorded only to the second level.

[0077] An example of the calculation process is shown below.

[0078] Suppose there are three conflicting timestamps for the same event.

[0079] 1) Data source 1 ( :00:05): Data directly uploaded to the blockchain from the vehicle's onboard chip (highly reliable), weighted .9.

[0080] 2) Data source 2 ( :00:12): From the power plant monitoring system log (relatively reliable), weight 6.

[0081] 3) Data source 3 ( :00:20): Manually entered by staff (low reliability), weight 3.

[0082] The final decision time is calculated using the following formula: resolved_time= =(0. +0. +0. ) / 1.8 = (4.5 + 7.2 + 6.0) / 1.8 = 17.7 / 1.8 ≈ 9.83 seconds. Therefore, the final time determined by the system is 10:00:09.83.

[0083] The core algorithm principle of this application is as follows.

[0084] 1) Cross-chain identity resolution protocol.

[0085] A cross-chain identity resolution protocol based on DID is defined: DID:battery:chain1:abc123 → resolves to → [chain1_info,chain2_info,chain3_info].

[0086] Here, battery:chain1:abc123 is a DID. 'battery' is the method name, indicating that this is a DID type defined for battery assets. 'chain1:abc123' is a method-specific identifier. The design here combines 'chain1' (the chain identifier) ​​and 'abc123' (the battery's native ID on that chain) to form a globally unique battery ID.

[0087] 2) Verifiable query protocol.

[0088] A query verification mechanism based on digital signatures was designed: Query→Response→Verify(Signature,Response)→Trust.

[0089] 3) Zero-knowledge proof application: For sensitive data, zk-SNARKs are used to implement privacy-preserving queries. C(x,w)=1 iff f(x,w)=1.

[0090] Where x represents public input and w represents private witness.

[0091] S6. The aggregate query engine and verification engine generate battery life cycle reports based on the unique timestamps and corresponding state data of each blockchain and the conclusions of cryptographic proofs.

[0092] Furthermore, after step S6, the process also includes: S7. Triggering the economic pledging model in the global identity registry of the battery through the query behavior, updating the credit score of the data source and allocating query fees; the economic pledging model is a ternary model of pledging-credit-fee.

[0093] In practical applications, the battery data query system based on cross-chain indexing and zero-knowledge verification proposed in this application can be applied to: residual value assessment of battery cascade utilization, green financial financing of energy storage assets, and carbon footprint tracking and auditing.

[0094] This application also provides the following two practical application scenarios.

[0095] Scenario 1: Residual value assessment of battery reuse.

[0096] A recycling company wants to assess the residual value of a retired battery, Battery_DID_001.

[0097] Step 1: Query.

[0098] Recycling companies can submit a query request (Query(Battery_DID_001,["SOH","cycle_count","temperature_history"]) through the AVE interface.

[0099] Step 2: Routing.

[0100] AVE queries GBIR and learns that the battery data exists in both the Fabric chain (for automakers) and the Ethereum chain (for energy storage operators).

[0101] Step 3: Obtain proofs in parallel.

[0102] AVE sends requests to the CCVRs of both chains in parallel. The Fabric chain CCVR returns a Merkle proof π_merkle. The Ethereum chain CCVR, due to its sensitivity to the SOH data, returns a ZK proof π_zk, proving that SOH > 80% is true.

[0103] Step 4: Validation and aggregation.

[0104] The AVE verification engine verifies the validity of the two proofs. Once the verification passes, the public data is aggregated with the conclusions of the ZK proof.

[0105] Step 5: Generate a report.

[0106] AVE generates a trusted report containing all cryptographic proofs. Recycling companies can use this report to accurately assess the residual value of batteries and submit it to a third-party auditing firm for verification.

[0107] Scenario 2: Green finance financing scenario for energy storage assets.

[0108] Step 1: An energy storage power station operator applies for a green loan from a bank using its battery assets as collateral.

[0109] Step 2: The bank submits a batch query request for all battery DIDs in the power station via AVE, requesting to obtain historical SOH trends and current status.

[0110] Step 3: AVE automatically completes the parallel query, verification, and aggregation process for all relevant chains.

[0111] Step 4: Within minutes, the bank receives a cryptographically secured, complete asset health report, replacing the traditional, time-consuming in-person due diligence process.

[0112] Step 5: Based on this credible report, the bank conducts a rapid risk assessment and pricing, completing loan approval. Meanwhile, the ZK proof of the battery data protects sensitive information such as the operator's operational details.

[0113] In the battery data query system based on cross-chain indexing and zero-knowledge verification in this application, there is a collaborative working mechanism among the three components: the global battery identity registry, the cross-chain verification relay, and the aggregated queryer and verification engine. The collaborative technical effects of the three components are mainly reflected in the following aspects.

[0114] 1) Efficient Collaboration of Global Identity Resolution and Route Discovery: GBIR, as the global index layer, achieves unified resolution and route discovery of battery identities by storing the dynamic mapping relationship between battery DIDs and multi-chain addresses through a lightweight distributed ledger. AVE quickly locates all blockchain nodes where the target battery data is located by calling GBIR's standardized query interface, avoiding the inefficiency of manually traversing multiple chains in traditional solutions, and significantly improving the efficiency and accuracy of the query initiation phase.

[0115] 2) Deep Integration of Pluggable Cross-Chain Verification and Privacy Protection: CCVR, as the core module for cross-chain data access and proof generation, supports seamless access to various blockchain types through a pluggable adapter architecture. When responding to query requests initiated by AVE, it can dynamically select and generate different types of cryptographic proofs, such as Merkle existence proofs, zero-knowledge proofs (ZKP), or aggregate signatures, based on data sensitivity and user needs. This mechanism not only ensures the authenticity and integrity of the data but also achieves "data usable but not visible" through ZK technology, effectively protecting commercially sensitive information during the aggregation process.

[0116] 3) System optimization of parallel query scheduling and intelligent conflict resolution: As a coordination and aggregation engine, AVE employs an asynchronous parallel scheduling algorithm to simultaneously initiate query requests to multiple chains, and combines this with a dynamic timeout mechanism to avoid single-point delays affecting overall performance. During the data aggregation phase, AVE's built-in intelligent conflict resolution module based on dynamic weights can automatically identify and resolve timestamp or state data conflicts from different chains. It calculates the most reliable data value through a multi-dimensional reputation model (such as historical accuracy, data precision, and source type), improving the reliability and usability of the aggregation results.

[0117] 4) Synergistic Protection of Economic Model and Security Mechanism: The "staking-reputation-fee" ternary economic model introduced in GBIR forms a closed loop with CCVR's proof generation mechanism and AVE's verification logic. Registrants must stake tokens to protect against Sybil attacks, querying parties pay fees to incentivize ecosystem participation, and frequent and valid data queries improve their reputation score. This mechanism not only enhances the system's security and attack resistance but also promotes data quality improvement and the healthy development of the ecosystem.

[0118] 5) Standardized Protocols and Ecosystem Interoperability: All three adhere to a complete set of cross-chain query and verification protocol standards, enabling different blockchain systems to quickly connect to this system simply by deploying a CCVR adapter, greatly reducing the technical barriers and costs of heterogeneous chain interconnection. This standardized design provides a replicable and scalable infrastructure for cross-chain aggregation of battery lifecycle data, suitable for various application scenarios such as cascade utilization, green finance, and carbon footprint auditing.

[0119] The technical effects of this application are as follows.

[0120] This application aims to construct a distributed infrastructure for a cross-chain query protocol for battery data. Through three innovative core components—a lightweight global index, a pluggable verification relay, and a parallel aggregation engine—it addresses the challenges of querying, verifying, protecting privacy, and resolving conflicts caused by battery data being scattered across multiple heterogeneous blockchains. Ultimately, it achieves seamless discovery, reliable verification, privacy-preserving aggregation, and intelligent conflict resolution of battery lifecycle data, providing a complete and reliable data foundation for accurate valuation, green finance, regulatory compliance, and efficient recycling of battery assets. Specific technical effects are as follows.

[0121] 1) Solving the data silo problem: By building a global index through GBIR, unified discovery and querying of battery data scattered across multiple blockchains is realized, breaking down data silos.

[0122] 2) Improve query and verification efficiency: By using the standardized CCVR module and parallel query and verification algorithm, the complex process that originally required manual query and verification on multiple chains is automated, which greatly improves efficiency.

[0123] 3) Ensure data credibility: The verification mechanism based on cryptographic proof (Merkel proof, digital signature) ensures the credibility of cross-chain query results without the need to trust the intermediate aggregator.

[0124] 4) Protecting data privacy: Through zero-knowledge proof technology, privacy-preserving queries that "prove without reveal" are achieved, protecting the commercially sensitive information of all parties involved in the data aggregation process.

[0125] 5) Provides standardized interfaces: Defines a complete cross-chain query and verification protocol, providing a standardized solution for the interconnection of different blockchain systems.

[0126] 6) Supports a wide range of application scenarios: This system is not only suitable for battery data query, but can also be extended to other scenarios that require cross-chain data aggregation, such as supply chain finance and carbon footprint tracking.

[0127] Example 2: This application also provides a computer device, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 5 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores and processes data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the methods described above.

[0128] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0129] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

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

[0131] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for using a battery data query system based on cross-chain indexing and zero-knowledge verification, characterized in that, The battery data query system based on cross-chain indexing and zero-knowledge verification includes: a global battery identity registry, a cross-chain verification relay, and an aggregation queryer and verification engine; the global battery identity registry is used to establish and maintain a dynamic mapping between battery DIDs and multiple blockchain addresses based on DPoS consensus and an economic staking model; the cross-chain verification relay is deployed on different blockchains in the form of a pluggable adapter architecture, responds to standardized query requests, and generates cryptographic proofs; the aggregation queryer and verification engine are used to query routing information from the global battery identity registry, initiate query requests in parallel to the cross-chain verification relay, and verify the response proofs and aggregated data; the application method includes: The user submits a query request to the aggregated query engine and the verification engine; the query request includes: the target battery DID and the required data fields; The aggregation queryer and verification engine query the target battery DID from the global battery identity registry to obtain a list of all stored blockchain addresses; The aggregated queryer and the verification engine send standardized query requests in parallel to the cross-chain verification relays on different blockchains based on the address list. The cross-chain verification relay on each blockchain accesses local chain data, generates cryptographic proofs according to requests, and returns them; the cryptographic proofs include at least: zero-knowledge verification; The aggregation query and verification engine verify the validity of the cryptographic proof, using the blockchain as the data source and employing a smart conflict resolution mechanism based on dynamic weights to determine the unique timestamp and corresponding state data. The aggregation query engine and verification engine generate a battery life cycle report based on the unique timestamps of each blockchain, the corresponding state data, and the conclusions of cryptographic proofs.

2. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, After the aggregation query engine and verification engine generate a battery life cycle report based on the unique timestamps and corresponding state data of each blockchain and the conclusions of cryptographic proofs, it also includes: S7. The query behavior triggers the economic pledging model in the global identity registry of the battery, updates the credit score of the data source and allocates query fees; the economic pledging model is a ternary model of pledging-credit-fee.

3. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, The query request is a four-tuple structure, which is represented as: Record=(DID, Chain_Info, Timestamp, Signature); where DID is the unique digital identity of the battery; Chain_Info is the blockchain information of the battery data, which includes: chain type, gateway address and query interface; Timestamp is the registration timestamp; and Signature is the digital signature of the registrant.

4. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 3, characterized in that, The registration mechanism of the global battery identity registry includes: when the battery data of a target battery is recorded on a blockchain for the first time, the gateway node of the blockchain needs to register with the global battery identity registry: Register(DID, Chain_Info, Stake) → Tx_Hash. At the same time, the registration process requires collateral and payment of a preset transaction fee to prevent Sybil attacks.

5. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, The pluggable adapter architecture is a scalable architecture that is compatible with multiple blockchain types by defining a unified abstract interface.

6. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, The cryptographic proofs also include: Merkle tree existence proofs, zk-SNARKs-based zero-knowledge proofs, and BLS-based aggregate signatures.

7. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, The intelligent conflict resolution mechanism based on dynamic weights specifically includes: Based on the historical accuracy, timestamp generation precision, and data source type, a weight calculation function is used to calculate the dynamic weight of the data source; the data source types include: direct sensor data collection, system logs, and manual input. Substitute the conflicting timestamps and their corresponding data source dynamic weights into the weighted average formula to calculate the unique timestamp. The unique timestamp and corresponding status data will be used as the basis for the generation and application of subsequent battery life cycle reports.

8. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 7, characterized in that, The formula for calculating the dynamic weight of the data source is as follows: ； In the formula, For data source Dynamic weights; For data source Historical accuracy and reputation; For data source The precision coefficient of the timestamp; For data source Data source type weight; All of these are adjustable weighting coefficients.

9. The application method of the battery data query system based on cross-chain indexing and zero-knowledge verification according to claim 1, characterized in that, The formula for calculating the unique timestamp is as follows: ； In the formula, A unique timestamp; For data source The original timestamp; To be assigned to the data source The weights; The number of data sources; For data source The weight.

10. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the battery data query system application method based on cross-chain indexing and zero-knowledge verification as described in any one of claims 1-9.

Images