A power right transaction trusted management method, device, equipment and medium

Abstract

The application discloses a power right and interest transaction credible management method, device, equipment and medium, relates to the power right and interest information management technical field, and the method comprises the following steps: collecting zero-knowledge proofs of a plurality of power right and interest transactions, and performing first validity verification on the zero-knowledge proofs through a preset recursive zero-knowledge proof technology; when the zero-knowledge proofs all pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof; when there is a power right and interest transaction that needs cross-domain verification, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof through a BLS threshold signature scheme to generate an aggregated signature; the aggregated proof, the aggregated signature and a proof digest are subjected to second validity verification, and after the verification passes, corresponding transaction digests and operation logs are written into a preset hierarchical block chain. The application can realize the unity of privacy protection and verification efficiency in the decentralized power right and interest information management.

Description

Technical Field

[0001] This invention relates to the field of power rights information management technology, and in particular to a reliable management method, device, equipment and medium for power rights transactions. Background Technology

[0002] Electricity rights trading, as a core component of the electricity market's operation, involves multiple stakeholders, including power generation, transmission, distribution, and consumption. The resulting rights certificates (such as generation rights, consumption rights, and green certificates) serve as crucial evidence for transaction settlement, quota assessment, and policy subsidies. Ensuring the authenticity, integrity, and immutability of these rights trading records—that is, achieving credible evidence preservation—is fundamental to maintaining market fairness, preventing transaction disputes, and supporting regulatory audits. Especially in cross-regional and cross-institutional trading scenarios, all parties must reach a consensus on the status of the same rights certificate. Traditional methods relying on a single centralized database or independent systems for recording are insufficient to provide sufficiently credible and efficient evidence preservation and verification capabilities, hindering the efficient collaboration and large-scale development of the electricity market.

[0003] Currently, existing technologies for achieving trusted evidence storage in electricity rights trading primarily employ centralized, trusted third-party data hosting and verification, or utilize blockchain technology for distributed transaction recording. However, these methods all face a key dilemma: how to efficiently verify the validity of transactions (such as authentic signatures, compliant formats, and legal ownership) while ensuring the privacy of sensitive transaction data (e.g., the identity of the transaction parties, precise quantities, and prices), especially in scenarios requiring multi-party, cross-domain collaborative verification. Specifically, if conventional encryption is used for storage, decryption is necessary for verification, posing a privacy risk; if relying on independent verification by each party followed by result exchange results, the process is complex, inefficient, and difficult to prevent malicious nodes from providing false verification conclusions. Existing solutions struggle to balance "privacy protection" and "efficient verifiability," becoming a core bottleneck restricting the practical application and cross-domain promotion of trusted management technologies for electricity rights trading. Summary of the Invention

[0004] This invention provides a trusted management method, apparatus, equipment, and medium for electricity rights transactions, which can solve the technical problem of high data leakage risk and low verification efficiency caused by the requirement for pre-decryption when performing data verification in existing electricity rights information management systems.

[0005] In a first aspect, embodiments of the present invention provide a trusted management method for electricity rights transactions, comprising: A number of zero-knowledge proofs for electricity rights transactions are collected, and the zero-knowledge proofs are first validated using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the validation, they are aggregated to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using the preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. When there is a power rights transaction that requires cross-domain verification, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof through the BLS threshold signature scheme. When the number of signatures reaches the preset threshold value, an aggregated signature is generated. The aggregated proof, aggregated signature, and proof digest are each subjected to a second validity verification. After the verification is passed, the transaction digests and operation logs corresponding to each power rights transaction generated by the aggregated proof are written into a preset hierarchical blockchain.

[0006] This invention verifies the validity of each proof (ensuring reliable origin) and then aggregates a large number of individual proofs (approximately 1KB each) into a very compact (approximately 300 bytes) aggregated proof. This achieves batch verification and data compression, reducing the data transmission and processing overhead of subsequent cross-domain consensus and blockchain records. By performing threshold signatures only on the hash value of the aggregated proof (rather than the original data or the proof itself), cross-domain consensus is achieved while minimizing the amount of data requiring consensus and communication complexity. Furthermore, the aggregatable nature of BLS signatures allows multiple signatures to be merged into one, further simplifying the verification logic. The threshold mechanism then ensures the system's fault tolerance and anti-collusion capabilities, preventing a few malicious nodes from disrupting consensus, thus achieving a secure and efficient cross-domain consensus mechanism. After final verification of all preceding steps, the key digest of the transaction (rather than the original data) and the operation log are written to the data chain and the evidence storage chain respectively, achieving hierarchical and secure data storage. This invention enables a balance between privacy protection and verification efficiency in decentralized power rights information management.

[0007] In some preferred solutions of the first aspect, a zero-knowledge proof is generated based on the original transaction data of the electricity rights transaction initiated by the user, using a pre-defined zero-knowledge proof technique. Specifically: Receive raw transaction data for electricity rights transactions initiated by users; wherein, the raw transaction data includes rights type, rights quantity and validity period; The original transaction data and the corresponding pre-generated digital signature are input into a pre-deployed zero-knowledge proof circuit, so that the zero-knowledge proof circuit performs a third validity verification on the power rights transaction; wherein, the third validity verification includes data format compliance verification, signature validity verification, and rights legality verification; If all the power rights transactions pass the third validity verification, then based on the original transaction data, a witness value satisfying the R1CS constraint is generated, and a proof component is constructed based on the witness value using a multinomial commitment system; wherein, the proof component includes a prover's knowledge commitment, a bilinear pair association commitment, and a final commitment verification characterizing the satisfaction of the R1CS constraint; The proof component is hashed and compressed with the preset public hash value of the original transaction data to generate a proof digest; The proof components and proof digest are encapsulated according to a preset format to generate a zero-knowledge proof for the electricity rights transaction.

[0008] This invention employs pre-deployed circuitry for multi-dimensional verification (format, signature, and legitimacy of rights) to ensure the compliance and authenticity of the input data itself; it generates witness values ​​that satisfy constraints and constructs core proof components (A, B, C) to ensure the cryptographic correctness and completeness of the generated proof; and it generates and encapsulates a unique proof digest, providing a tamper-proof fingerprint for the proof. This invention ensures that every zero-knowledge proof entering the subsequent aggregation process is valid, compliant, and cryptographically secure.

[0009] In some preferred embodiments of the first aspect, the first validity verification of the zero-knowledge proof is performed using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof, specifically as follows: Based on the transaction type and a preset time window, the zero-knowledge proofs are grouped to obtain several proof groups, and the format of each zero-knowledge proof within the proof group is validated. The proof groups that pass the format verification are input into a preset recursive zero-knowledge proof circuit. The bottom sub-circuit of the recursive zero-knowledge proof circuit performs a fourth validity verification on each zero-knowledge proof in the proof group. If each zero-knowledge proof in the proof group passes the fourth validity verification, the intermediate sub-circuit of the recursive zero-knowledge proof circuit performs logical aggregation on each zero-knowledge proof in the proof group to obtain an intermediate aggregated proof. Then, the top sub-circuit of the recursive zero-knowledge proof circuit uses the zk-SNARKs algorithm to generate the final aggregated proof based on the intermediate aggregated proof.

[0010] This invention achieves logically ordered management and load balancing by grouping transactions by type and time window. The recursive verification circuit with a tree-like hierarchical structure decomposes large-scale verification problems into small tasks that can be processed in parallel through a pipeline design of parallel verification (bottom layer), intermediate aggregation (middle layer), and final proof generation (top layer), which greatly improves computational efficiency. The final aggregated proof is generated only when all bottom-level proofs are valid, which strictly guarantees the reliability of the aggregation result.

[0011] In some preferred embodiments of the first aspect, after aggregating the zero-knowledge proofs to obtain aggregated proofs, the method further includes updating the Merkle tree on the main chain of the hierarchical blockchain based on the hash of the original transaction data corresponding to the aggregated proofs; wherein, updating the Merkle tree on the main chain of the hierarchical blockchain based on the hash of all the original transaction data corresponding to the aggregated proofs specifically involves: Extract all the original transaction data hashes corresponding to the pre-stored aggregated proof, construct a temporary Merkle tree based on the original transaction data hashes, and calculate the root hash of the temporary Merkle tree; Read the global Merkle root on the main chain of the currently stored hierarchical blockchain, and merge the root hash with the global Merkle root to generate a new global Merkle root, which is then written into the Merkle tree on the main chain.

[0012] This invention, through constructing a temporary Merkle tree and calculating its root hash, is a process of rapidly organizing a batch of discrete transactions into a cryptographic accumulator. First, the temporary root is merged with the main chain's global Merkle root, enabling incremental state updates and avoiding the enormous overhead of reconstructing the entire tree each time. Next, the association between the aggregated proof hash and the new global root is recorded, establishing an index relationship that traces back from the immutable anchor point (Merkle root) on the blockchain to a specific batch of transactions and their aggregated proofs. This is the foundation for achieving efficient retrieval and accurate traceability.

[0013] In some preferred embodiments of the first aspect, when cross-domain verification is required for electricity rights transactions, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated for the aggregated proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregated signature is generated, specifically as follows: Determine the cross-domain scenario to which the power equity transaction corresponding to the aggregated proof belongs, and match all participating domains under the cross-domain scenario; Calculate the hash value of the aggregated proof and distribute the hash value to the representative nodes of each participating domain; Each representative node uses its own private key to fragment the hash value and signs it using the BLS signature algorithm to generate a partial signature; The partial signatures of the representative nodes of each participating domain are integrated. When the number of partial signatures reaches a preset threshold, the partial signatures are aggregated into an aggregate signature.

[0014] This invention, through the distribution of hash values ​​of aggregated proofs, ensures that participating domains can participate in consensus without accessing the original data or complete proofs, thus protecting privacy. Using the BLS algorithm and private key sharding for signing and aggregation mathematically guarantees that as long as a threshold number of legitimate nodes participate, a short, uniformly verifiable, and authoritative signature can be generated, perfectly adapting to decentralized, fault-tolerant cross-domain environments.

[0015] In some preferred embodiments of the first aspect, a second validity verification is performed on the aggregated proof, aggregated signature, and proof digest, specifically as follows: The aggregated proof is verified using a preset verification key to determine whether it satisfies the constraints of the recursive verification circuit, thus obtaining the recursive constraint verification result. Verify the binding relationship between the aggregated signature and the hash value of the aggregated proof, confirm that the aggregated signature is a valid signature of the hash value, and obtain the cross-domain signature association verification result; The proof digest of the aggregated proof is recalculated and compared with the proof digest encapsulated in the aggregated proof to verify consistency and obtain the digest consistency verification result. When the recursive constraint verification result, the cross-domain signature association verification result, and the digest consistency verification result are all passed, the second validity verification is deemed to have passed.

[0016] This invention verifies the correctness of the "batch verification" process itself by verifying whether the aggregated proof satisfies the recursive verification circuit constraints, thus eliminating logical errors or attacks in the aggregation stage. Verifying the binding between the aggregated signature and the hash value confirms that the batch transaction has obtained legitimate cross-domain authorization, granting the evidence storage result inter-domain credibility. Recalculating and comparing the proof digest verifies whether the data has maintained its integrity during transmission or temporary storage, preventing man-in-the-middle tampering. These three interconnected verifications control the data from three key dimensions: computational correctness, authorization legitimacy, and data integrity. Only when all three pass are the data allowed to be stored on the blockchain, maximizing the absolute credibility of the data ultimately written to the blockchain.

[0017] In some preferred embodiments of the first aspect, the layered blockchain includes a data chain, a storage chain, and a main chain; The step of writing the transaction summaries and operation logs corresponding to each electricity rights transaction generated by the aggregation proof into a preset hierarchical blockchain specifically involves: The transaction summary is written into the data chain, and the operation log is written into the evidence storage chain.

[0018] This invention, through the collaborative efforts of the data chain, the evidence storage chain, and the main chain, persists electricity rights transaction information that has undergone rigorous verification and privacy processing in a way that balances high-performance access, complete audit trails, low storage overhead, and strong security anchoring. This directly supports and strengthens the "efficient, reliable, and traceable" evidence storage capabilities pursued by the overall system.

[0019] Secondly, embodiments of the present invention provide a trusted management device for electricity rights transactions, including an aggregated proof generation module, an aggregated signature generation module, and a rights transaction notarization module, wherein... The aggregated proof generation module is used to collect zero-knowledge proofs of several electricity rights transactions, and to perform a first validity verification on the zero-knowledge proofs using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using a preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. The aggregate signature generation module is used to generate an aggregate signature when there is a power rights transaction that requires cross-domain verification. In this cross-domain verification, the representative nodes of each participating domain sign the hash value pre-calculated by the aggregate proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregate signature is generated. The rights and interests transaction evidence storage module is used to perform a second validity verification on the aggregated proof, aggregated signature and proof digest respectively. After the verification is passed, the transaction digest and operation log corresponding to each power rights and interests transaction generated by the aggregated proof are written into the preset hierarchical blockchain.

[0020] This invention employs an aggregated proof generation module to verify the validity of each proof (ensuring reliable origin), then aggregates a large number (approximately 1KB / proof) of individual proofs into a very compact (approximately 300 bytes) aggregated proof. This enables batch verification and data compression, reducing the data transmission and processing overhead for subsequent cross-domain consensus and blockchain records. An aggregated signature generation module performs threshold signatures only on the hash value of the aggregated proof (rather than the original data or the proof itself). This achieves cross-domain consensus while minimizing the amount of data required for consensus and communication complexity. Furthermore, the aggregatable nature of BLS signatures allows multiple signatures to be merged into one, further simplifying the verification logic. The threshold mechanism ensures the system's fault tolerance and anti-collusion capabilities, preventing a few malicious nodes from disrupting consensus, thus achieving a secure and efficient cross-domain consensus mechanism. Finally, an equity transaction notarization module performs a final verification of all preceding steps. After successful verification, the key digest of the transaction (rather than the original data) and the operation log are written to the data chain and notarization chain respectively, achieving hierarchical and secure data storage.

[0021] Thirdly, embodiments of the present invention provide a terminal device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform the operation of the trusted management method for electricity rights trading as described in any of the above.

[0022] Fourthly, embodiments of the present invention provide a computer-readable storage medium comprising a stored computer program, wherein, when the computer program is executed, it controls the device or apparatus containing the computer-readable storage medium to perform the trusted management method for power rights trading as described in any of the preceding claims.

[0023] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of a trusted management method for electricity rights trading provided by an embodiment of the present invention; Figure 2 This is a structural diagram of a trusted management device for electricity rights trading provided in an embodiment of the present invention. Detailed Implementation

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

[0026] Example 1: like Figure 1 As shown, an embodiment of the present invention provides a trusted management method for electricity rights transactions, comprising the following steps: S101, collect several zero-knowledge proofs of electricity rights transactions, and perform a first validity verification on the zero-knowledge proofs using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, aggregate the zero-knowledge proofs to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using a preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. In one specific embodiment, when a user initiates a power generation rights certificate registration transaction through the application layer, the input data includes: rights type: power generation rights; rights quantity: 1000 kWh; validity period: January 1, 2025 to December 31, 2025; user identity identifier (encrypted); hash value of relevant supporting documents.

[0027] Specifically, the relevant supporting documents can be understood as a key file for the registration and transaction of the corresponding power generation rights certificate, generated through the following steps: The encryption method mainly adopts zero-knowledge proof encryption + signature encryption + data storage and index encryption, a triple encryption method; among them, the zero-knowledge proof encryption mainly uses the zk-SNARKs algorithm to generate the initial zero-knowledge proof, and generates a compact aggregate proof through recursive zero-knowledge proof technology; the signature encryption mainly adopts cross-domain verification, uses the BLS threshold signature scheme to generate aggregate signatures, and further combines a group signature mechanism with trusted institution whitelist management; the data storage and index encryption adopts a sharded Merkle tree, the main chain uses this structure to store the verification proof and the Merkle root, the data chain stores the transaction summary, and the evidence storage chain records the operation log, and the three are linked through hash pointers; Preferably, an auxiliary security mechanism is employed for each original transaction data of the power generation rights certificate registration transaction initiated by the user to ensure the security of the data source. The auxiliary security mechanism includes privacy protection, tamper detection, and source tracing encryption association. Privacy protection mainly consists of encrypted identity identification and encrypted data retrieval adaptation. The encrypted data retrieval adaptation combines a time-series database optimized with Bloom filters and LSM trees with a sharded Merkle tree index. The encryption link between tamper detection and source tracing combines state channel technology with comparison of state snapshots from off-chain monitoring nodes, while also using a backpropagation algorithm to trace and locate the source of the anomaly.

[0028] In this embodiment, a zero-knowledge proof is generated based on the original transaction data of a user-initiated electricity rights transaction using a preset zero-knowledge proof technology. Specifically, the process involves: receiving the original transaction data of the user-initiated electricity rights transaction; wherein the original transaction data includes the rights type, rights quantity, and validity period; inputting the original transaction data and the corresponding pre-generated digital signature into a pre-deployed zero-knowledge proof circuit, so that the zero-knowledge proof circuit performs a third validity verification on the electricity rights transaction; wherein the third validity verification includes data format compliance verification, signature validity verification, and rights legality verification; if the electricity rights transaction passes all the third validity verifications, a witness value satisfying the R1CS constraint is generated based on the original transaction data, and a proof component is constructed based on the witness value using a multinomial commitment system; wherein the proof component includes a prover knowledge commitment, a bilinear pair association commitment, and a final commitment verification representing the satisfaction of the R1CS constraint; hashing and compressing the proof component with a preset public hash value of the original transaction data to generate a proof digest; and encapsulating the proof component and the proof digest according to a preset format to generate a zero-knowledge proof of the electricity rights transaction.

[0029] It should be noted that when a user initiates a power rights certificate registration transaction through the application layer, the client software uses the user's private key to generate a digital signature on the core content of the transaction (such as rights type, quantity, validity period, etc.). This signature is submitted to the system along with the original transaction data.

[0030] In one specific embodiment, the aforementioned transaction data is sent to the equity information proof generation module of the smart contract layer. This module generates an initial zero-knowledge proof based on the zk-SNARKs (zero-knowledge concise non-interactive knowledge proof) algorithm. The specific operation is as follows: The preliminary steps include: pre-deploying zk-SNARKs circuits adapted for power rights trading (which should include logic for three verification dimensions: data format compliance verification, signature validity verification, and rights legality verification), and compiling the circuit description language into R1CS (Rank-1 constraint system), Witness calculation function, and Solidity verification contract using the Circom compiler; using security parameters that meet the security level requirements of the power industry, generating a public reference string through a trusted initialization ceremony, including a proof key and a verification key, with the verification key pre-deployed to the blockchain layer of the system, and the proof key held by and only by the "rights information proof generation module" of the smart contract layer; inputting the original transaction data (including rights type, quantity, validity period, etc.) into the witness calculation function to generate a witness value that satisfies the R1CS constraints, which contains the privacy information of the transaction data; Furthermore, the proof generation process includes three steps: constraint satisfaction verification, zero-knowledge proof construction, and formatted proof output. Constraint satisfaction verification: Substitute the R1CS constraint system and witness calculation function into the polynomial interpolation and commitment stage of the zk-SNARKs algorithm. Transform the R1CS constraints into polynomial equations through polynomial interpolation, and verify whether the witness values ​​that satisfy the R1CS constraints satisfy the polynomial equations. If the constraints are satisfied, generate polynomial commitment values. Zero-knowledge proof construction: Using "paired friendly elliptic curves" (BN254 curves) as the underlying mathematical foundation, and utilizing the bilinear pairing property of polynomial commitment values, the proof can be made concise; Based on the multinomial commitment system, three core proof components are generated: the prover's knowledge commitment, designated as A, the bilinear pairing association commitment, designated as B, and the final commitment verification of constraint satisfaction, designated as C. Proof Formatting Output: A, B, C, and the common input (the public hash value of the transaction data, equivalent to the public key) are compressed into a fixed-length proof digest using a hash function. A, B, C, and the proof digest are then encapsulated according to the zk-SNARKs standard format and lossless compressed (using the LZ4 compression algorithm) to generate the initial zero-knowledge proof π1. Initial zero-knowledge proof π1 includes: a proof header (version number, algorithm identifier), core components A, B, and C, the proof digest, and a timestamp. Initial zero-knowledge proof π1 (approximately 1 KB in size) verifies the validity of the transaction without revealing any original data content.

[0031] After outputting the initial zero-knowledge proof π1, it is transmitted through an encrypted channel, and the hash of the transaction data corresponding to the proof is recorded in the evidence storage chain.

[0032] In this embodiment, the zero-knowledge proof is first validated using a preset recursive zero-knowledge proof technique. When all zero-knowledge proofs pass the validation, they are aggregated to obtain an aggregated proof. Specifically, the zero-knowledge proofs are grouped according to the transaction type and a preset time window to obtain several proof groups, and the format of each zero-knowledge proof within each proof group is validated. The proof groups that pass the format validation are input to a preset recursive zero-knowledge proof circuit. The bottom sub-circuit of the recursive zero-knowledge proof circuit performs a fourth validity validation on each zero-knowledge proof in the proof group. If all zero-knowledge proofs in the proof group pass the fourth validity validation, the intermediate sub-circuit of the recursive zero-knowledge proof circuit performs logical aggregation on each zero-knowledge proof in the proof group to obtain an intermediate aggregated proof. Finally, the top sub-circuit of the recursive zero-knowledge proof circuit uses the zk-SNARKs algorithm to generate the final aggregated proof based on the intermediate aggregated proof.

[0033] In one specific embodiment, the system continuously collects multiple similar rights transactions (such as energy storage rights registration, electricity consumption rights registration, etc.). The rights information proof generation module uses recursive zero-knowledge proof technology to aggregate multiple initial proofs. Specifically, the process involves processing multiple initial zero-knowledge proofs π1, π2, ..., π according to "transaction type + time window". n Grouping is performed, with the number of members in each group dynamically configurable and adaptively adjusted based on system throughput. After grouping, the initial proofs within each group undergo format verification, specifically checking for consistency in proof version, algorithm representation, and length (standard 1kB size). The public hash value of the transaction data corresponding to each initial zero-knowledge proof is extracted and compared with the record in the evidence storage chain. Similarly, a recursive verification circuit adapted for electricity rights trading is pre-deployed, and the circuit description language is compiled into an R1CS constraint system using the Circom compiler. The recursive verification circuit adopts a "tree-like hierarchical structure" design: the bottom layer consists of n parallel initial proof verification sub-circuits, the middle layer is an aggregation verification sub-circuit, and the top layer is the final proof generation sub-circuit, with each layer connected in series through constraint logic. The circuit verifies the validity of a single initial proof and its verification key, outputting a "valid" or "invalid" result. The top layer only outputs the aggregation proof when all bottom-level verification results are "valid." The security parameters of the recursive circuit are consistent with those of the zk-SNARKs circuit, and a public reference string, including the recursive proof key and the recursive verification key, is generated through a trusted initialization ceremony. The recursive verification key is deployed to the blockchain layer.

[0034] Specifically, the verification process for the recursive verification circuit is as follows: Bottom layer: The grouped initial proofs are input into the initial proof verification sub-circuit respectively. Each sub-circuit loads the corresponding verification key and executes the verification logic independently, including whether the core components A, B, and C satisfy the bilinear pairing constraint, whether the proof digest matches the common input hash, and outputs the verification result of a single proof (valid = 1, invalid = 0, the same below). All bottom layer sub-circuits output 1 and enter the next layer of aggregation. The middle layer: The aggregation verification sub-circuit adopts a "binary recursion" strategy, dividing the n verification results of the bottom layer into several subsets (the number of subsets is random, and the number of verification results in each subset should be as equal as possible). Each subset is input into an aggregation verification sub-circuit, and a "logical AND" constraint is executed (that is, when each verification result in the subset is "1", the aggregation verification result of the sub-circuit is "1"), generating an "intermediate aggregation proof" for the subset. The above steps are repeated, using the "intermediate aggregation proof" generated in the previous round as input, and the sub-circuit is grouped again to generate higher-level "intermediate aggregation proofs" until a "top-level intermediate aggregation proof" is generated. Top layer: Input the "top layer intermediate aggregate proof" and the common input hash set of all initial proofs. Based on the polynomial interpolation technique, map the common input hash of all initial proofs to a unified polynomial commitment, and use the zk-SNARKs algorithm to generate the final aggregate proof (the basic process is similar to the initial zero-knowledge proof process above), and perform lossless compression.

[0035] In this embodiment, after aggregating the zero-knowledge proofs to obtain aggregated proofs, the method further includes updating the Merkle tree on the main chain of the hierarchical blockchain based on the hashes of the original transaction data corresponding to the aggregated proofs. Specifically, updating the Merkle tree on the main chain of the hierarchical blockchain based on the hashes of all the original transaction data corresponding to the aggregated proofs involves: extracting all the hashes of the original transaction data corresponding to the aggregated proofs from the pre-stored data, constructing a temporary Merkle tree based on the hashes, and calculating the root hash of the temporary Merkle tree; reading the global Merkle root on the main chain of the hierarchical blockchain currently stored, and merging the root hash with the global Merkle root to generate a new global Merkle root, which is then written into the Merkle tree on the main chain.

[0036] In one specific embodiment, updating the Merkle tree on the main chain of the hierarchical blockchain involves the following steps: After the aggregation proof Π is generated, the system extracts the transaction data hashes corresponding to all initial proofs, constructs a temporary Merkle tree, and calculates the root hash of the tree (denoted as Root_temp); it reads the currently stored global Merkle root (denoted as Root_old) from the main chain, merges Root_temp and Root_old using the Merkle tree merging algorithm, and generates a new global Merkle root (denoted as Root_new); it writes Root_new into the corresponding shard of the sharded Merkle tree on the main chain, and records the mapping relationship between Root_old and Root_new and the hash value of the aggregation proof Π, ensuring that all initial transactions of this aggregation can be traced back to Root_new in the future.

[0037] S102, when there is a power rights transaction that requires cross-domain verification, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof through the BLS threshold signature scheme. When the number of signatures reaches the preset threshold value, an aggregated signature is generated. In this embodiment, when a power rights transaction requires cross-domain verification, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregated signature is generated. Specifically, the process involves: determining the cross-domain scenario to which the power rights transaction corresponding to the aggregated proof belongs, and matching all participating domains in the cross-domain scenario; calculating the hash value of the aggregated proof and distributing the hash value to the representative nodes of each participating domain; each representative node using its own private key fragment to sign the hash value using the BLS signature algorithm to generate a partial signature; and integrating the partial signatures of the representative nodes of each participating domain. When the number of partial signatures reaches a preset threshold, the partial signatures are aggregated into an aggregated signature.

[0038] It should be noted that the BLS threshold signature scheme is a digital signature technology based on elliptic curve bilinear pairing. Its core feature is that "multiple private keys generate a single signature, and a single signature can verify the legitimacy of all signers". Its underlying implementation relies on BN254 elliptic curves (compatible with the zk-SNARKs algorithm, reducing system heterogeneity) and bilinear pairing operations (satisfying e(aP,bQ)=e(P,Q)^(ab), supporting signature aggregation and verification).

[0039] It should be noted that a valid aggregate signature is generated only when valid signatures of the participating domains above the threshold value t = n / 3 + 1 (where n is the number of initial zero-knowledge proofs) are collected.

[0040] It should be noted that the aggregate signature key generation logic uses a distributed key algorithm.

[0041] In one specific embodiment, when cross-domain verification is required for power rights transactions, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregated signature is generated. Specifically, the process is as follows: First, the cross-domain scenario to which the transaction corresponding to the aggregated proof Π belongs is determined, and all participating domains in that scenario are automatically matched (the preset list of participating domains is stored via the main chain hash). The representative node of each participating domain undergoes identity verification through the trusted institution whitelist management module, calculates the hash value H(Π) (256 bits) of the aggregated proof Π using a hash function, and synchronizes this hash value and the global public key in the aggregated signature key to all certified representative nodes of the participating domains. After receiving the hash value, each representative node performs BLS signature operations on the hash value using its own stored key (in the aggregated signature key), including: mapping H(Π) to a point on a BN254 elliptic curve, using the hash-to-curve standard algorithm and elliptic curve point multiplication to calculate the node signature; verifying all node signatures, and when the threshold t is reached, BLS is used. The signature aggregation algorithm aggregates t valid partial signatures into a single aggregated signature (aggregation uses elliptic curve point addition, and the size of the aggregated signature is still 32 bytes, consistent with the single-node BLS signature).

[0042] Preferably, the generated aggregate signature, hash value H(Π), and global public key are bound together to generate a structured confirmation signal (including signature timestamp, list of participating domains, and threshold achievement indicator), triggering the transaction to enter the blockchain recording stage.

[0043] S103, perform a second validity verification on the aggregated proof, aggregated signature and proof digest respectively. After the verification is passed, write the transaction digest and operation log corresponding to each power rights transaction generated by the aggregated proof into the preset hierarchical blockchain.

[0044] In this embodiment, the aggregated proof, aggregated signature, and proof digest are each subjected to a second validity verification. Specifically, the following steps are taken: First, the aggregated proof is verified using a preset verification key to determine whether it satisfies the constraints of the recursive verification circuit, resulting in a recursive constraint verification result. Second, the binding relationship between the aggregated signature and the hash value of the aggregated proof is verified, confirming that the aggregated signature is a valid signature of the hash value, resulting in a cross-domain signature correlation verification result. Third, the proof digest of the aggregated proof is recalculated and compared with the proof digest encapsulated in the aggregated proof to verify consistency, resulting in a digest consistency verification result. Fourth, when the recursive constraint verification result, the cross-domain signature correlation verification result, and the digest consistency verification result are all passed, the second validity verification is deemed successful.

[0045] It should be noted that after receiving the aggregated proof Π and the consistency confirmation signal, the verification node of the blockchain layer performs a second validity verification process on the aggregated proof, aggregated signature and proof digest respectively.

[0046] In one specific embodiment, a second validity verification is performed on the aggregated proof, aggregated signature, and proof digest, specifically as follows: Recursive constraint satisfaction verification: The verification node calls the pre-compiled zk-SNARKs verification algorithm, substitutes the recursive verification key, aggregate proof Π, and common input set into the verification logic, first parses the recursive verification commitment in Π, and verifies whether the commitment satisfies the R1CS constraint system of the recursive verification circuit (i.e., the validity verification result of all initial proofs in the verification aggregation process is "valid", and the recursive aggregation logic has not been violated). The binding relationship between the polynomial aggregation commitment and the common input set is verified through bilinear pairing operation (based on BN254 elliptic curve). Proof digest consistency check: Extract the proof digest from Π, recalculate the hash values ​​of the recursive verification commitment and the multinomial aggregation commitment using the SHA-256 algorithm, and compare them with the extracted proof digest. If they match, the proof Π has not been tampered with during transmission or storage; if they do not match, the verification is directly determined to have failed, and the anomaly tracing process is triggered. Cross-domain signature association verification: Combining the aggregate signature σ_agg in the cross-domain consistency confirmation signal, verify the binding relationship between the hash value H(Π) of Π and the aggregate signature (i.e., whether the aggregate signature is a valid signature for H(Π)). This step is implemented through BLS signature verification logic (e(σ_agg), G) = e(HashToCurve(H(Π)), global public key P)) to ensure that Π has undergone legitimate cross-domain verification, further strengthening the validity of the proof; If all the above verification steps pass, the verification node will output a "valid" result.

[0047] In this embodiment, the layered blockchain includes a data chain, a storage chain, and a main chain; the step of writing the transaction summary and operation log corresponding to each power rights transaction generated by the aggregation proof into the preset layered blockchain specifically involves writing the transaction summary into the data chain and writing the operation log into the storage chain.

[0048] It should be noted that the transaction digest mainly includes: basic information hash group, proof association hash, transaction status hash, verifier signature hash, and HMAC checksum; The basic information hash group includes "equity type hash, equity quantity hash, validity period hash, and transaction unique ID"; the proof association hash corresponds to the hash value in step one; the transaction status hash represents the current transaction status hash value (which may include "registered", "cross-domain verified", and "transaction completed"); the verification node signature hash is the aggregate hash value of the public keys of the set of verification nodes that are valid for this verification; and the HMAC checksum is an integrity checksum generated based on the transaction digest body.

[0049] Preferably, in this embodiment of the invention, the system status can be continuously scanned by off-chain monitoring nodes: current transaction status data and historical operation logs are obtained, and abnormal changes are detected by comparing status snapshots every second. Combined with status channel technology, millisecond-level response is achieved to obtain a tampering detection report (if there is no abnormality, "normal" is output).

[0050] It should be noted that users or authorized institutions can query the rights certificate information through the application layer: users or authorized institutions input query conditions (such as transaction ID, time range), the system locates the data shard through sharded Merkle tree index, combines the time series database optimized by LSM tree, uses Bloom filter to accelerate retrieval, and will return query results within 0.5-0.8 seconds, supporting high-concurrency access of hundreds of millions of data.

[0051] Preferably, if the system detects an abnormal signature, it can trace the signature path based on the backpropagation algorithm, locate the source of the abnormality, obtain a source tracing report and repair suggestions, and automatically trigger the smart contract to perform state rollback or alarm.

[0052] Preferably, embodiments of the present invention can be applied to the following trusted management system for electricity rights data, wherein the modules of each layer of the system are configured as follows: (1) Data Layer: This layer includes the main chain, the data chain, and the evidence storage chain. The main chain uses a sharded Merkle tree structure to store verification proofs and Merkle roots; the data chain stores transaction summaries; and the evidence storage chain records all operation logs. The three are interconnected through hash pointers to form a traceable data structure.

[0053] (2) Smart Contract Layer: Rights Information Proof Generation Module: Based on recursive zero-knowledge proof technology, it realizes the generation and aggregation of proofs.

[0054] Cross-domain verification module: Based on federated consensus and threshold signature, it realizes cross-domain data consistency verification.

[0055] Status monitoring module: Combines status channels with off-chain nodes to achieve real-time tamper detection.

[0056] (3) Blockchain layer: A decentralized network composed of multiple verification nodes, which automatically executes verification logic through smart contracts to ensure the consistency of distributed transactions.

[0057] (4) Application layer: Provides user interfaces such as data retrieval, data decryption, and transaction initiation, and supports high concurrency access and millisecond-level response.

[0058] (5) Auxiliary module Trusted Institution Whitelist Management Module: Verifies the identity of signers in group signatures.

[0059] Source tracing module: Enables rapid location and repair of abnormal events.

[0060] This invention verifies the validity of each proof (ensuring reliable origin) and then aggregates a large number of individual proofs (approximately 1KB each) into a very compact (approximately 300 bytes) aggregated proof. This achieves batch verification and data compression, reducing the data transmission and processing overhead of subsequent cross-domain consensus and blockchain records. By performing threshold signatures only on the hash value of the aggregated proof (rather than the original data or the proof itself), cross-domain consensus is achieved while minimizing the amount of data requiring consensus and communication complexity. Furthermore, the aggregatable nature of BLS signatures allows multiple signatures to be merged into one, further simplifying the verification logic. The threshold mechanism then ensures the system's fault tolerance and anti-collusion capabilities, preventing a few malicious nodes from disrupting consensus, thus achieving a secure and efficient cross-domain consensus mechanism. After final verification of all preceding steps, the key digest of the transaction (rather than the original data) and the operation log are written to the data chain and the evidence storage chain respectively, achieving hierarchical and secure data storage. This invention enables a balance between privacy protection and verification efficiency in decentralized power rights information management.

[0061] Example 2: like Figure 2 As shown, this embodiment provides a trusted management device for electricity rights transactions, including an aggregated proof generation module 201, an aggregated signature generation module 202, and a rights transaction evidence storage module 203, wherein... The aggregated proof generation module 201 is used to collect zero-knowledge proofs of several electricity rights transactions, and to perform a first validity verification on the zero-knowledge proofs using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using a preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. In one specific embodiment, when a user initiates a power generation rights certificate registration transaction through the application layer, the input data includes: rights type: power generation rights; rights quantity: 1000 kWh; validity period: January 1, 2025 to December 31, 2025; user identity identifier (encrypted); hash value of relevant supporting documents.

[0062] Specifically, the relevant supporting documents can be understood as a key file for the registration and transaction of the corresponding power generation rights certificate, generated through the following steps: The encryption method mainly adopts zero-knowledge proof encryption + signature encryption + data storage and index encryption, a triple encryption method; among them, the zero-knowledge proof encryption mainly uses the zk-SNARKs algorithm to generate the initial zero-knowledge proof, and generates a compact aggregate proof through recursive zero-knowledge proof technology; the signature encryption mainly adopts cross-domain verification, uses the BLS threshold signature scheme to generate aggregate signatures, and further combines a group signature mechanism with trusted institution whitelist management; the data storage and index encryption adopts a sharded Merkle tree, the main chain uses this structure to store the verification proof and the Merkle root, the data chain stores the transaction summary, and the evidence storage chain records the operation log, and the three are linked through hash pointers; Preferably, an auxiliary security mechanism is employed for each original transaction data of the power generation rights certificate registration transaction initiated by the user to ensure the security of the data source. The auxiliary security mechanism includes privacy protection, tamper detection, and source tracing encryption association. Privacy protection mainly consists of encrypted identity identification and encrypted data retrieval adaptation. The encrypted data retrieval adaptation combines a time-series database optimized with Bloom filters and LSM trees with a sharded Merkle tree index. The encryption link between tamper detection and source tracing combines state channel technology with comparison of state snapshots from off-chain monitoring nodes, while also using a backpropagation algorithm to trace and locate the source of the anomaly.

[0063] In this embodiment, the aggregation proof generation module 201 generates a zero-knowledge proof based on the original transaction data of the user-initiated electricity rights transaction using a preset zero-knowledge proof technology. Specifically, the aggregation proof generation module 201 receives the original transaction data of the user-initiated electricity rights transaction; wherein the original transaction data includes the rights type, rights quantity, and validity period; the original transaction data and the corresponding pre-generated digital signature are input into a pre-deployed zero-knowledge proof circuit, so that the zero-knowledge proof circuit performs a third validity verification on the electricity rights transaction; wherein the third validity verification includes data format compliance verification, The process includes signature validity verification and rights legitimacy verification. If all power rights transactions pass the third validity verification, a witness value satisfying the R1CS constraint is generated based on the original transaction data. A proof component is constructed based on the witness value using a multinomial commitment system. The proof component includes a prover's knowledge commitment, a bilinear pair association commitment, and a final commitment verification representing the satisfaction of the R1CS constraint. The proof component is hash-compressed with a preset public hash value of the original transaction data to generate a proof digest. The proof component and the proof digest are encapsulated according to a preset format to generate a zero-knowledge proof of the power rights transaction.

[0064] It should be noted that when a user initiates a power rights certificate registration transaction through the application layer, the client software uses the user's private key to generate a digital signature on the core content of the transaction (such as rights type, quantity, validity period, etc.). This signature is submitted to the system along with the original transaction data.

[0065] In one specific embodiment, the aforementioned transaction data is sent to the equity information proof generation module of the smart contract layer. This module generates an initial zero-knowledge proof based on the zk-SNARKs (zero-knowledge concise non-interactive knowledge proof) algorithm. The specific operation is as follows: The preliminary steps include: pre-deploying zk-SNARKs circuits adapted for power rights trading (which should include logic for three verification dimensions: data format compliance verification, signature validity verification, and rights legality verification), and compiling the circuit description language into R1CS (Rank-1 constraint system), Witness calculation function, and Solidity verification contract using the Circom compiler; using security parameters that meet the security level requirements of the power industry, generating a public reference string through a trusted initialization ceremony, including a proof key and a verification key, with the verification key pre-deployed to the blockchain layer of the system, and the proof key held by and only by the "rights information proof generation module" of the smart contract layer; inputting the original transaction data (including rights type, quantity, validity period, etc.) into the witness calculation function to generate a witness value that satisfies the R1CS constraints, which contains the privacy information of the transaction data; Furthermore, the proof generation process includes three steps: constraint satisfaction verification, zero-knowledge proof construction, and formatted proof output. Constraint satisfaction verification: Substitute the R1CS constraint system and witness calculation function into the polynomial interpolation and commitment stage of the zk-SNARKs algorithm. Transform the R1CS constraints into polynomial equations through polynomial interpolation, and verify whether the witness values ​​that satisfy the R1CS constraints satisfy the polynomial equations. If the constraints are satisfied, generate polynomial commitment values. Zero-knowledge proof construction: Using "paired friendly elliptic curves" (BN254 curves) as the underlying mathematical foundation, and utilizing the bilinear pairing property of polynomial commitment values, the proof can be made concise; Based on the multinomial commitment system, three core proof components are generated: the prover's knowledge commitment, designated as A, the bilinear pairing association commitment, designated as B, and the final commitment verification of constraint satisfaction, designated as C. Proof Formatting Output: A, B, C, and the common input (the public hash value of the transaction data, equivalent to the public key) are compressed into a fixed-length proof digest using a hash function. A, B, C, and the proof digest are then encapsulated according to the zk-SNARKs standard format and lossless compressed (using the LZ4 compression algorithm) to generate the initial zero-knowledge proof π1. Initial zero-knowledge proof π1 includes: a proof header (version number, algorithm identifier), core components A, B, and C, the proof digest, and a timestamp. Initial zero-knowledge proof π1 (approximately 1 KB in size) verifies the validity of the transaction without revealing any original data content.

[0066] After outputting the initial zero-knowledge proof π1, it is transmitted through an encrypted channel, and the hash of the transaction data corresponding to the proof is recorded in the evidence storage chain.

[0067] In this embodiment, the aggregated proof generation module 201 performs a first validity verification on the zero-knowledge proof using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof. Specifically, the aggregated proof generation module 201 groups the zero-knowledge proofs according to the transaction type and a preset time window to obtain several proof groups, and performs format verification on each zero-knowledge proof within each proof group. The proof groups that pass the format verification are input to a preset recursive zero-knowledge proof circuit, so that the bottom sub-circuit of the recursive zero-knowledge proof circuit performs a fourth validity verification on each zero-knowledge proof in the proof group. If all the zero-knowledge proofs in the proof group pass the fourth validity verification, the intermediate sub-circuit of the recursive zero-knowledge proof circuit performs logical aggregation on each zero-knowledge proof in the proof group to obtain an intermediate aggregated proof. Finally, the top sub-circuit of the recursive zero-knowledge proof circuit uses the zk-SNARKs algorithm to generate the final aggregated proof based on the intermediate aggregated proof.

[0068] In one specific embodiment, the system continuously collects multiple similar rights transactions (such as energy storage rights registration, electricity consumption rights registration, etc.). The rights information proof generation module uses recursive zero-knowledge proof technology to aggregate multiple initial proofs. Specifically, the process involves processing multiple initial zero-knowledge proofs π1, π2, ..., π according to "transaction type + time window". n Grouping is performed, with the number of members in each group dynamically configurable and adaptively adjusted based on system throughput. After grouping, the initial proofs within each group undergo format verification, specifically checking for consistency in proof version, algorithm representation, and length (standard 1kB size). The public hash value of the transaction data corresponding to each initial zero-knowledge proof is extracted and compared with the record in the evidence storage chain. Similarly, a recursive verification circuit adapted for electricity rights trading is pre-deployed, and the circuit description language is compiled into an R1CS constraint system using the Circom compiler. The recursive verification circuit adopts a "tree-like hierarchical structure" design: the bottom layer consists of n parallel initial proof verification sub-circuits, the middle layer is an aggregation verification sub-circuit, and the top layer is the final proof generation sub-circuit, with each layer connected in series through constraint logic. The circuit verifies the validity of a single initial proof and its verification key, outputting a "valid" or "invalid" result. The top layer only outputs the aggregation proof when all bottom-level verification results are "valid." The security parameters of the recursive circuit are consistent with those of the zk-SNARKs circuit, and a public reference string, including the recursive proof key and the recursive verification key, is generated through a trusted initialization ceremony. The recursive verification key is deployed to the blockchain layer.

[0069] Specifically, the verification process for the recursive verification circuit is as follows: Bottom layer: The grouped initial proofs are input into the initial proof verification sub-circuit respectively. Each sub-circuit loads the corresponding verification key and executes the verification logic independently, including whether the core components A, B, and C satisfy the bilinear pairing constraint, whether the proof digest matches the common input hash, and outputs the verification result of a single proof (valid = 1, invalid = 0, the same below). All bottom layer sub-circuits output 1 and enter the next layer of aggregation. The middle layer: The aggregation verification sub-circuit adopts a "binary recursion" strategy, dividing the n verification results of the bottom layer into several subsets (the number of subsets is random, and the number of verification results in each subset should be as equal as possible). Each subset is input into an aggregation verification sub-circuit, and a "logical AND" constraint is executed (that is, when each verification result in the subset is "1", the aggregation verification result of the sub-circuit is "1"), generating an "intermediate aggregation proof" for the subset. The above steps are repeated, using the "intermediate aggregation proof" generated in the previous round as input, and the sub-circuit is grouped again to generate higher-level "intermediate aggregation proofs" until a "top-level intermediate aggregation proof" is generated. Top layer: Input the "top layer intermediate aggregate proof" and the common input hash set of all initial proofs. Based on the polynomial interpolation technique, map the common input hash of all initial proofs to a unified polynomial commitment, and use the zk-SNARKs algorithm to generate the final aggregate proof (the basic process is similar to the initial zero-knowledge proof process above), and perform lossless compression.

[0070] In this embodiment, after aggregating the zero-knowledge proofs to obtain aggregated proofs, the aggregation proof generation module 201 further includes updating the Merkle tree on the main chain of the hierarchical blockchain according to the original transaction data hashes corresponding to the aggregated proofs. Specifically, updating the Merkle tree on the main chain of the hierarchical blockchain according to all the original transaction data hashes corresponding to the aggregated proofs involves: extracting all the pre-stored original transaction data hashes corresponding to the aggregated proofs to construct a temporary Merkle tree based on the original transaction data hashes, and calculating the root hash of the temporary Merkle tree; reading the currently stored global Merkle root on the main chain of the hierarchical blockchain, and merging the root hash with the global Merkle root to generate a new global Merkle root, which is then written into the Merkle tree on the main chain.

[0071] In one specific embodiment, updating the Merkle tree on the main chain of the hierarchical blockchain involves the following steps: After the aggregation proof Π is generated, the system extracts the transaction data hashes corresponding to all initial proofs, constructs a temporary Merkle tree, and calculates the root hash of the tree (denoted as Root_temp); it reads the currently stored global Merkle root (denoted as Root_old) from the main chain, merges Root_temp and Root_old using the Merkle tree merging algorithm, and generates a new global Merkle root (denoted as Root_new); it writes Root_new into the corresponding shard of the sharded Merkle tree on the main chain, and records the mapping relationship between Root_old and Root_new and the hash value of the aggregation proof Π, ensuring that all initial transactions of this aggregation can be traced back to Root_new in the future.

[0072] The aggregate signature generation module 202 is used to generate an aggregate signature when there is a power rights transaction that requires cross-domain verification. In this cross-domain verification, the representative nodes of each participating domain sign the hash value pre-calculated by the aggregate proof through the BLS threshold signature scheme. When the number of signatures reaches the preset threshold value, the aggregate signature is generated. In this embodiment, when there is a power rights transaction requiring cross-domain verification, the aggregate signature generation module 202, in this cross-domain verification, has representative nodes of each participating domain sign the hash value pre-calculated by the aggregate proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregate signature is generated. Specifically, the aggregate signature generation module 202 determines the cross-domain scenario to which the power rights transaction corresponding to the aggregate proof belongs, and matches all participating domains in the cross-domain scenario; calculates the hash value of the aggregate proof, and distributes the hash value to the representative nodes of each participating domain; each representative node uses its own private key fragment to sign the hash value using the BLS signature algorithm to generate a partial signature; integrates the partial signatures of the representative nodes of each participating domain, and when the number of partial signatures reaches a preset threshold, the partial signatures are aggregated into an aggregate signature.

[0073] It should be noted that the BLS threshold signature scheme is a digital signature technology based on elliptic curve bilinear pairing. Its core feature is that "multiple private keys generate a single signature, and a single signature can verify the legitimacy of all signers". Its underlying implementation relies on BN254 elliptic curves (compatible with the zk-SNARKs algorithm, reducing system heterogeneity) and bilinear pairing operations (satisfying e(aP,bQ)=e(P,Q)^(ab), supporting signature aggregation and verification).

[0074] It should be noted that a valid aggregate signature is generated only when valid signatures of the participating domains above the threshold value t = n / 3 + 1 (where n is the number of initial zero-knowledge proofs) are collected.

[0075] It should be noted that the aggregate signature key generation logic uses a distributed key algorithm.

[0076] In one specific embodiment, when cross-domain verification is required for power rights transactions, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregated signature is generated. Specifically, the process is as follows: First, the cross-domain scenario to which the transaction corresponding to the aggregated proof Π belongs is determined, and all participating domains in that scenario are automatically matched (the preset list of participating domains is stored via the main chain hash). The representative node of each participating domain undergoes identity verification through the trusted institution whitelist management module, calculates the hash value H(Π) (256 bits) of the aggregated proof Π using a hash function, and synchronizes this hash value and the global public key in the aggregated signature key to all certified representative nodes of the participating domains. After receiving the hash value, each representative node performs BLS signature operations on the hash value using its own stored key (in the aggregated signature key), including: mapping H(Π) to a point on a BN254 elliptic curve, using the hash-to-curve standard algorithm and elliptic curve point multiplication to calculate the node signature; verifying all node signatures, and when the threshold t is reached, BLS is used. The signature aggregation algorithm aggregates t valid partial signatures into a single aggregated signature (aggregation uses elliptic curve point addition, and the size of the aggregated signature is still 32 bytes, consistent with the single-node BLS signature).

[0077] Preferably, the generated aggregate signature, hash value H(Π), and global public key are bound together to generate a structured confirmation signal (including signature timestamp, list of participating domains, and threshold achievement indicator), triggering the transaction to enter the blockchain recording stage.

[0078] The rights and interests transaction evidence storage module 203 is used to perform a second validity verification on the aggregated proof, aggregated signature and proof digest respectively. After the verification is passed, the transaction digest and operation log corresponding to each power rights and interests transaction generated by the aggregated proof are written into the preset hierarchical blockchain.

[0079] In this embodiment, the equity transaction evidence storage module 203 performs a second validity verification on the aggregated proof, aggregated signature, and proof digest, respectively. Specifically, the equity transaction evidence storage module 203 verifies whether the aggregated proof satisfies the constraints of the recursive verification circuit using a preset verification key, and obtains a recursive constraint verification result; verifies the binding relationship between the aggregated signature and the hash value of the aggregated proof, confirming that the aggregated signature is a valid signature of the hash value, and obtains a cross-domain signature correlation verification result; recalculates the proof digest of the aggregated proof and compares it with the proof digest encapsulated in the aggregated proof to verify consistency, and obtains a digest consistency verification result; when the recursive constraint verification result, the cross-domain signature correlation verification result, and the digest consistency verification result are all passed, the second validity verification is determined to be passed.

[0080] It should be noted that after receiving the aggregated proof Π and the consistency confirmation signal, the verification node of the blockchain layer performs a second validity verification process on the aggregated proof, aggregated signature and proof digest respectively.

[0081] In one specific embodiment, a second validity verification is performed on the aggregated proof, aggregated signature, and proof digest, specifically as follows: Recursive constraint satisfaction verification: The verification node calls the pre-compiled zk-SNARKs verification algorithm, substitutes the recursive verification key, aggregate proof Π, and common input set into the verification logic, first parses the recursive verification commitment in Π, and verifies whether the commitment satisfies the R1CS constraint system of the recursive verification circuit (i.e., the validity verification result of all initial proofs in the verification aggregation process is "valid", and the recursive aggregation logic has not been violated). The binding relationship between the polynomial aggregation commitment and the common input set is verified through bilinear pairing operation (based on BN254 elliptic curve). Proof digest consistency check: Extract the proof digest from Π, recalculate the hash values ​​of the recursive verification commitment and the multinomial aggregation commitment using the SHA-256 algorithm, and compare them with the extracted proof digest. If they match, the proof Π has not been tampered with during transmission or storage; if they do not match, the verification is directly determined to have failed, and the anomaly tracing process is triggered. Cross-domain signature association verification: Combining the aggregate signature σ_agg in the cross-domain consistency confirmation signal, verify the binding relationship between the hash value H(Π) of Π and the aggregate signature (i.e., whether the aggregate signature is a valid signature for H(Π)). This step is implemented through BLS signature verification logic (e(σ_agg), G) = e(HashToCurve(H(Π)), global public key P)) to ensure that Π has undergone legitimate cross-domain verification, further strengthening the validity of the proof; If all the above verification steps pass, the verification node will output a "valid" result.

[0082] In this embodiment, the layered blockchain includes a data chain, a storage chain, and a main chain; the rights transaction storage module 203 writes the transaction summary and operation log corresponding to each power rights transaction generated by the aggregation proof into the preset layered blockchain, specifically: the rights transaction storage module 203 writes the transaction summary into the data chain and the operation log into the storage chain.

[0083] It should be noted that the transaction digest mainly includes: basic information hash group, proof association hash, transaction status hash, verifier signature hash, and HMAC checksum; The basic information hash group includes "equity type hash, equity quantity hash, validity period hash, and transaction unique ID"; the proof association hash corresponds to the hash value in step one; the transaction status hash represents the current transaction status hash value (which may include "registered", "cross-domain verified", and "transaction completed"); the verification node signature hash is the aggregate hash value of the public keys of the set of verification nodes that are valid for this verification; and the HMAC checksum is an integrity checksum generated based on the transaction digest body.

[0084] Preferably, in this embodiment of the invention, the system status can be continuously scanned by off-chain monitoring nodes: current transaction status data and historical operation logs are obtained, and abnormal changes are detected by comparing status snapshots every second. Combined with status channel technology, millisecond-level response is achieved to obtain a tampering detection report (if there is no abnormality, "normal" is output).

[0085] It should be noted that users or authorized institutions can query the rights certificate information through the application layer: users or authorized institutions input query conditions (such as transaction ID, time range), the system locates the data shard through sharded Merkle tree index, combines the time series database optimized by LSM tree, uses Bloom filter to accelerate retrieval, and will return query results within 0.5-0.8 seconds, supporting high-concurrency access of hundreds of millions of data.

[0086] Preferably, if the system detects an abnormal signature, it can trace the signature path based on the backpropagation algorithm, locate the source of the abnormality, obtain a source tracing report and repair suggestions, and automatically trigger the smart contract to perform state rollback or alarm.

[0087] Preferably, embodiments of the present invention can be applied to the following trusted management system for electricity rights data, wherein the modules of each layer of the system are configured as follows: (1) Data Layer: This layer includes the main chain, the data chain, and the evidence storage chain. The main chain uses a sharded Merkle tree structure to store verification proofs and Merkle roots; the data chain stores transaction summaries; and the evidence storage chain records all operation logs. The three are interconnected through hash pointers to form a traceable data structure.

[0088] (2) Smart Contract Layer: Rights information proof generation module: Based on recursive zero-knowledge proof technology, it realizes the generation and aggregation of proofs.

[0089] Cross-domain verification module: Based on federated consensus and threshold signature, it realizes cross-domain data consistency verification.

[0090] Status monitoring module: Combines status channels with off-chain nodes to achieve real-time tamper detection.

[0091] (3) Blockchain layer: A decentralized network composed of multiple verification nodes, which automatically executes verification logic through smart contracts to ensure the consistency of distributed transactions.

[0092] (4) Application layer: Provides user interfaces such as data retrieval, data decryption, and transaction initiation, and supports high concurrency access and millisecond-level response.

[0093] (5) Auxiliary module: Trusted Institution Whitelist Management Module: Verifies the identity of signers in group signatures.

[0094] Source tracing module: Enables rapid location and repair of abnormal events.

[0095] For a more detailed explanation of the working principle and procedures of this embodiment, please refer to the relevant description in Embodiment 1.

[0096] This invention employs an aggregated proof generation module 201 to verify the validity of each proof (ensuring reliable origin), then aggregates a large number (approximately 1KB / proof) of individual proofs into a very compact (approximately 300 bytes) aggregated proof to achieve batch verification and data compression, reducing the data transmission and processing overhead of subsequent cross-domain consensus and blockchain records. An aggregated signature generation module 202 performs threshold signing only on the hash value of the aggregated proof (rather than the original data or the proof itself), achieving cross-domain consensus while minimizing the amount of data requiring consensus and communication complexity. Furthermore, the aggregatable nature of BLS signatures allows multiple signatures to be merged into one, further simplifying the verification logic. The threshold mechanism ensures the system's fault tolerance and anti-collusion capabilities, preventing a few malicious nodes from disrupting consensus, thus achieving a secure and efficient cross-domain consensus mechanism. Finally, an equity transaction evidence storage module 203 performs a final verification of all preceding steps. After successful verification, the key digest of the transaction (rather than the original data) and the operation log are written to the data chain and evidence storage chain respectively, achieving hierarchical and secure data storage.

[0097] Example 3: This embodiment provides a terminal device, including: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform the operation of the trusted management method for electricity rights trading as described in any of the above.

[0098] Example 4: This invention provides a computer-readable storage medium including a stored computer program, wherein the computer program, when running, controls the device or apparatus containing the computer-readable storage medium to execute the trusted management method for power rights trading as described above.

[0099] 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 program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0100] 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 reliable management method for electricity rights transactions, characterized in that, include: A number of zero-knowledge proofs for electricity rights transactions are collected, and the zero-knowledge proofs are first validated using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the validation, they are aggregated to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using the preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. When there is a power rights transaction that requires cross-domain verification, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof through the BLS threshold signature scheme. When the number of signatures reaches the preset threshold value, an aggregated signature is generated. The aggregated proof, aggregated signature, and proof digest are each subjected to a second validity verification. After the verification is passed, the transaction digests and operation logs corresponding to each power rights transaction generated by the aggregated proof are written into a preset hierarchical blockchain.

2. The trusted management method for electricity rights transactions as described in claim 1, characterized in that, Using pre-defined zero-knowledge proof technology, a zero-knowledge proof is generated based on the original transaction data of the electricity rights transaction initiated by the user. Specifically: Receive raw transaction data of electricity rights transactions initiated by users; wherein, the raw transaction data includes rights type, rights quantity and validity period; The original transaction data and the corresponding pre-generated digital signature are input into a pre-deployed zero-knowledge proof circuit, so that the zero-knowledge proof circuit performs a third validity verification on the power rights transaction; wherein, the third validity verification includes data format compliance verification, signature validity verification, and rights legality verification; If all the power rights transactions pass the third validity verification, then based on the original transaction data, a witness value satisfying the R1CS constraint is generated, and a proof component is constructed based on the witness value using a multinomial commitment system; wherein, the proof component includes a prover's knowledge commitment, a bilinear pair association commitment, and a final commitment verification characterizing the satisfaction of the R1CS constraint; The proof component is hashed and compressed with the preset public hash value of the original transaction data to generate a proof digest; The proof components and proof digest are encapsulated according to a preset format to generate a zero-knowledge proof for the electricity rights transaction.

3. The trusted management method for electricity rights transactions as described in claim 1, characterized in that, The first validity verification of the zero-knowledge proof is performed using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof, specifically as follows: Based on the transaction type and a preset time window, the zero-knowledge proofs are grouped to obtain several proof groups, and the format of each zero-knowledge proof within the proof group is validated. The proof groups that pass the format verification are input into a preset recursive zero-knowledge proof circuit. The bottom sub-circuit of the recursive zero-knowledge proof circuit performs a fourth validity verification on each zero-knowledge proof in the proof group. If each zero-knowledge proof in the proof group passes the fourth validity verification, the intermediate sub-circuit of the recursive zero-knowledge proof circuit performs logical aggregation on each zero-knowledge proof in the proof group to obtain an intermediate aggregated proof. Then, the top sub-circuit of the recursive zero-knowledge proof circuit uses the zk-SNARKs algorithm to generate the final aggregated proof based on the intermediate aggregated proof.

4. The trusted management method for electricity rights transactions as described in claim 1, characterized in that, After aggregating the zero-knowledge proofs to obtain aggregated proofs, the method further includes updating the Merkle tree on the main chain of the hierarchical blockchain based on the hash of the original transaction data corresponding to the aggregated proofs; wherein, updating the Merkle tree on the main chain of the hierarchical blockchain based on the hash of all the original transaction data corresponding to the aggregated proofs specifically involves: Extract all the original transaction data hashes corresponding to the pre-stored aggregated proof, construct a temporary Merkle tree based on the original transaction data hashes, and calculate the root hash of the temporary Merkle tree; Read the global Merkle root on the main chain of the currently stored hierarchical blockchain, and merge the root hash with the global Merkle root to generate a new global Merkle root, which is then written into the Merkle tree on the main chain.

5. The trusted management method for electricity rights transactions as described in claim 1, characterized in that, When cross-domain verification is required for electricity rights transactions, the representative nodes of each participating domain in this cross-domain verification sign the hash value pre-calculated by the aggregated proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregated signature is generated, specifically as follows: Determine the cross-domain scenario to which the power equity transaction corresponding to the aggregated proof belongs, and match all participating domains under the cross-domain scenario; Calculate the hash value of the aggregated proof and distribute the hash value to the representative nodes of each participating domain; Each representative node uses its own private key to fragment the hash value and signs it using the BLS signature algorithm to generate a partial signature; The partial signatures of the representative nodes of each participating domain are integrated. When the number of partial signatures reaches a preset threshold, the partial signatures are aggregated into an aggregate signature.

6. The trusted management method for electricity rights transactions as described in claim 2, characterized in that, The aggregated proof, aggregated signature, and proof digest are each subjected to a second validity verification, specifically as follows: The aggregated proof is verified using a preset verification key to determine whether it satisfies the constraints of the recursive verification circuit, thus obtaining the recursive constraint verification result. Verify the binding relationship between the aggregated signature and the hash value of the aggregated proof, confirm that the aggregated signature is a valid signature of the hash value, and obtain the cross-domain signature association verification result; The proof digest of the aggregated proof is recalculated and compared with the proof digest encapsulated in the aggregated proof to verify consistency and obtain the digest consistency verification result. When the recursive constraint verification result, the cross-domain signature association verification result, and the digest consistency verification result are all passed, the second validity verification is deemed to have passed.

7. The trusted management method for electricity rights transactions as described in claim 1, characterized in that, The layered blockchain includes a data chain, a storage chain, and a main chain; The step of writing the transaction summaries and operation logs corresponding to each electricity rights transaction generated by the aggregation proof into a preset hierarchical blockchain specifically involves: The transaction summary is written into the data chain, and the operation log is written into the evidence storage chain.

8. A trusted management device for electricity rights trading, characterized in that, It includes an aggregated proof generation module, an aggregated signature generation module, and an equity transaction notarization module, among which, The aggregated proof generation module is used to collect zero-knowledge proofs of several electricity rights transactions, and to perform a first validity verification on the zero-knowledge proofs using a preset recursive zero-knowledge proof technique. When all the zero-knowledge proofs pass the verification, the zero-knowledge proofs are aggregated to obtain an aggregated proof. The zero-knowledge proofs are generated based on the original transaction data of the electricity rights transactions initiated by the user using a preset zero-knowledge proof technique. Each zero-knowledge proof includes a unique proof digest. The aggregate signature generation module is used to generate an aggregate signature when there is a power rights transaction that requires cross-domain verification. In this cross-domain verification, the representative nodes of each participating domain sign the hash value pre-calculated by the aggregate proof using the BLS threshold signature scheme. When the number of signatures reaches a preset threshold, an aggregate signature is generated. The rights and interests transaction evidence storage module is used to perform a second validity verification on the aggregated proof, aggregated signature and proof digest respectively. After the verification is passed, the transaction digest and operation log corresponding to each power rights and interests transaction generated by the aggregated proof are written into the preset hierarchical blockchain.

9. A terminal device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the trusted management method for electricity rights trading as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device or apparatus containing the computer-readable storage medium to perform the trusted management method for electricity rights trading as described in any one of claims 1 to 7.

Images