Distributed power transaction method and system capable of protecting identity and data privacy

Abstract

The invention discloses a distributed power transaction method and system capable of protecting identity and data privacy, and relates to the technical field of power transaction, and the method mainly comprises the steps: publishing a power transaction request to an alliance chain platform through an intelligent contract, and broadcasting the power transaction request to all consensus nodes, and verifying legality by using a practical Byzantine fault-tolerant algorithm, writing the power transaction request into a block chain account book, performing decryption, matching and uplink verification signature according to the power transaction request, and executing a transaction according to the signed transaction contract. By implementing the distributed power transaction method and system capable of protecting identity and data privacy, effective protection of identity information and data privacy in the power transaction process can be ensured, and meanwhile, the verifiability and credibility of the transaction are kept.

Description

Technical Field

[0001] The present invention relates to the field of power trading technology, and more specifically, to a distributed power trading method and system capable of protecting identity and data privacy. Background Art

[0002] In recent years, with the rapid development of distributed energy resources and demand-side response management, the power market is moving towards greater openness, and a distributed power trading market has gradually been established. This market mechanism, based on a decentralized trading mechanism, allows node users to trade with each other or with the power grid, ultimately maximizing market returns. This new power trading model has the potential to achieve diversification, flexibility, and efficiency in the power market. However, under this market model, power transactions rely on third-party institutions for oversight and settlement, increasing transaction costs. Consortium blockchain technology can provide a solution for distributed power trading markets. Combining distributed power trading markets with consortium chains is a method of integrating distributed power trading markets with blockchain technology, and this application will be a key direction for future power market development. Consortium chains are a special type of blockchain technology that improves system efficiency and security by limiting the number and permissions of participants. By recording transaction data on a consortium chain, decentralized transaction settlement can be achieved, reducing transaction costs. Furthermore, the security and privacy of consortium chains ensure the safety of transaction data. However, distributed power trading markets also face numerous challenges, such as shortcomings in identity authentication and data privacy protection in current power trading systems. Traditional centralized authentication methods may involve the centralized storage of user identity information, which can lead to potential security vulnerabilities and privacy risks. Furthermore, data exchange in existing power trading systems often lacks necessary privacy protection mechanisms, potentially leading to the leakage and misuse of sensitive user information. Ensuring the security of large-scale data exchanges between market participants is crucial, as the transmission of plaintext data can leak user identities and private electricity usage information, posing potential security risks to market participants. While security mechanisms and technologies for power trading have advanced significantly, risks such as data leakage and attacks persist in practical applications, necessitating the adoption of more advanced security technologies and strategies. Furthermore, distributed power trading systems are based on a decentralized mechanism, which challenges their processing capacity as transaction volumes continue to grow. This also presents complex challenges, such as ensuring transaction fairness and transparency and reducing transaction latency. Furthermore, distributed power trading systems utilize smart contract technology for transaction automation and execution. However, the correctness, security, and stability of smart contract code are crucial considerations, as is the design and implementation of secure and reliable smart contracts.

[0003] Centralized identity authentication: In traditional power trading systems, identity authentication often relies on centralized identity management agencies, which poses a single point of failure and security risks. If the identity authentication agency is attacked or data is leaked, the user's identity information will be at risk of being leaked and misused.

[0004] Inadequate data privacy protection: Existing power trading systems often fail to provide adequate data privacy protection mechanisms. During the data exchange process, user transaction data may be accessed and used by unauthorized third parties, increasing the risk of user privacy leakage.

[0005] Verifiability and credibility issues: Power trading systems need to ensure the verifiability and credibility of transactions to prevent fraud and disputes. However, the existing system lacks a comprehensive mechanism to ensure the verifiability and credibility of transactions.

[0006] To this end, it is necessary to develop a secure distributed power trading identity and data privacy protection system based on alliance chain privacy computing to ensure that data interaction between market participants is secure, private and reliable. Summary of the Invention

[0007] The purpose of the present invention is to provide a distributed power trading method and system that can protect identity and data privacy, ensure the effective protection of identity information and data privacy during the power trading process, and maintain the verifiability and credibility of the transaction.

[0008] The present invention provides a distributed power trading method that can protect identity and data privacy, comprising the following steps: S1: obtaining a power trading request based on key field information; S2: publishing the power trading request to a consortium chain platform using a smart contract; S3: broadcasting the power trading request to all consensus nodes, and confirming the legitimacy of the power trading request using a practical Byzantine fault tolerance algorithm; S4: writing the power trading request into a blockchain account book based on the legitimacy of the power trading request; S5: decrypting and matching the blockchain account book to obtain a matching result structure; S6: obtaining an on-chain registration item using a smart contract based on the matching result structure; S7: verifying the on-chain registration item and updating the smart contract status; S8: obtaining a signed transaction contract based on the smart contract status and a private key; S9: executing a transaction based on the signed transaction contract to obtain a transaction result.

[0009] The present invention also provides a distributed power trading system that can protect identity and data privacy, and the system includes the following modules: a transaction request construction module, configured to obtain a power transaction request based on key field information; a transaction request publishing module, configured to publish the power transaction request to the alliance chain platform using a smart contract; a transaction request distribution module, configured to broadcast the power transaction request to all consensus nodes and confirm the legitimacy of the power transaction request using a practical Byzantine fault tolerance algorithm; a transaction data encryption module, configured to write the power transaction request into a blockchain account book based on the legitimacy of the power transaction request; a transaction off-chain matching module, configured to decrypt and match the blockchain account book to obtain a matching result structure; a transaction matching on-chain module, configured to obtain an on-chain registration item based on the matching result structure using a smart contract; a privacy verification module, configured to verify the on-chain registration item and update the smart contract status; a transaction confirmation module, configured to obtain a signed transaction contract based on the smart contract status and private key; and a transaction execution module, configured to execute the transaction based on the signed transaction contract to obtain a transaction result.

[0010] The implementation of the distributed power trading method and system for protecting identity and data privacy provided by the present invention has the following beneficial effects: the present invention reduces transaction costs, improves transaction efficiency, reduces resource waste and energy consumption, maximizes market benefits, and improves market efficiency by establishing a decentralized trading mechanism; the present invention ensures the security and privacy of data interaction through various technologies such as the BIP32 protocol and attribute-based access control, prevents the leakage of user identity information and electricity usage privacy information, and realizes privacy protection; the present invention, through a distributed power trading system, allows users to participate in market transactions more conveniently, enjoy higher-quality and more convenient energy services, and enhance user experience; at the same time, it can prevent improper behaviors such as fraud and manipulation, ensure the fairness and standardization of the market, and realize the sustainable development of the distributed power trading market. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which: Figure 1 This is a flow chart of a distributed power trading method and system that can protect identity and data privacy, provided by the present invention; Figure 2 It is a business flow chart of the system provided by the present invention; Figure 3 It is the overall framework diagram of the system provided by the present invention; Figure 4 This is the confidential transaction query display diagram provided by the present invention; Figure 5 This is a schematic diagram of trusted power trading and security auditing provided by the present invention; Figure 6 This is a schematic diagram of the smart contract provided by the present invention; Figure 7 It is a schematic diagram of transaction information provided by the present invention; Figure 8 This is a schematic diagram of group signature generation provided by the present invention; Figure 9 Schematic diagram of the method for verifying and tracking signatures provided by the present invention; Figure 10 The role provided by the present invention is temporarily a schematic diagram of buyer authority; Figure 11 This is a schematic diagram of the client and management terminal provided by the present invention; Figure 12 This is a schematic diagram of user identity authorization and authentication provided by the present invention; Figure 13 This is a schematic diagram of the distributed matching algorithm provided by the present invention. DETAILED DESCRIPTION

[0012] In order to have a clearer understanding of the technical features, purposes and effects of the present invention, specific embodiments of the present invention are now described in detail with reference to the accompanying drawings.

[0013] Figure 1 A schematic diagram of a distributed power trading method capable of protecting identity and data privacy according to this embodiment is shown. In this embodiment, the distributed power trading method capable of protecting identity and data privacy includes the following steps: S1: Get the power transaction request based on the key field information; In an exemplary embodiment, step S1 specifically includes: S11: Use the BIP32 protocol to obtain multiple sub-addresses; S12: Get digital signature based on private key; S12: Obtain the power transaction request based on the key field information using attribute encryption and digital signature; In an exemplary embodiment, the key field information includes the intended transaction power, the expected electricity price, the transaction initiation timestamp, the user role identifier, and the user anonymous identity address; S2: Publish the electricity transaction request to the alliance chain platform using a smart contract; S3: Broadcast the electricity trading request to all consensus nodes and use the practical Byzantine fault tolerance algorithm to confirm the legitimacy of the electricity trading request; S4: Writing the power transaction request into the blockchain account book based on the legitimacy of the power transaction request; S5: Decrypt and match the blockchain ledger to obtain a matching result structure; In an exemplary embodiment, step S5 specifically includes: S51: Decrypt the blockchain account book according to the access control policy and user role to obtain the authorized access content; S52: Matching is performed based on the authorized access content and the set matching conditions to obtain a matching result structure; In an exemplary embodiment, the matching conditions set include electricity price matching, quantity matching, and time window overlap; In an exemplary embodiment, the matching result structure includes the sub-addresses of the supply and demand parties, electricity price, electricity quantity, matching timestamp, and matching number; S6: Obtain the on-chain registration item using the smart contract based on the matching result structure; S7: Verify the on-chain registration item and update the smart contract status; In an exemplary embodiment, step S7 specifically includes: Use zero-knowledge proof to verify whether the electricity prices in the transaction between the supply and demand parties are consistent, and use zero-knowledge proof to verify whether the supply and demand electricity volume falls within the preset range. The verification result is obtained based on whether the electricity prices are consistent and whether the supply and demand electricity volume falls within the preset range; update the smart contract status based on the verification result; In an exemplary embodiment, the verification result is a Boolean value; S8: Obtain a signed transaction contract based on the smart contract state and private key; In an exemplary embodiment, step S8 specifically includes: S51: Obtaining a transaction summary on the chain based on the smart contract status; S52: Digitally sign the transaction summary on the chain to obtain a signed transaction contract; In an exemplary embodiment, the on-chain transaction summary includes the matched transaction number, transaction time, electricity price, and sub-addresses of both the electricity supplier and the electricity demander; S9: Execute the transaction according to the signed transaction contract to obtain the transaction result; In an exemplary embodiment, the method further includes: performing abnormal audit and identity tracing based on the transaction results to obtain an audit report; and updating the blockchain based on the audit report.

[0014] This embodiment provides a distributed power trading system capable of protecting identity and data privacy. The system includes the following modules: a transaction request construction module configured to obtain a power transaction request based on key field information; a transaction request publishing module configured to publish the power transaction request to a consortium chain platform using a smart contract; a transaction request distribution module configured to broadcast the power transaction request to all consensus nodes and verify the legitimacy of the power transaction request using a practical Byzantine fault tolerance algorithm; a transaction data encryption module configured to write the power transaction request into a blockchain ledger based on the legitimacy of the power transaction request; a transaction off-chain matching module configured to decrypt and match the blockchain ledger to obtain a matching result structure; a transaction matching on-chain module configured to obtain an on-chain registration item based on the matching result structure using a smart contract; a privacy verification module configured to verify the on-chain registration item and update the smart contract status; a transaction confirmation module configured to obtain a signed transaction contract based on the smart contract status and a private key; and a transaction execution module configured to execute a transaction based on the signed transaction contract to obtain a transaction result.

[0015] In some embodiments, the above-mentioned distributed power trading method and system capable of protecting identity and data privacy may also be implemented in the following manner.

[0016] In this embodiment, a full-link privacy protection and verification mechanism is provided for both the initiator (customer) and the receiver (electricity user) of the electricity transaction.

[0017] 1. Data protocol encryption and identity anonymization process: Customer Registration and Identity Initialization: After registering with the system, each trading customer uses a master key generated based on the BIP32 protocol to derive multiple sub-addresses, which are then combined with a mnemonic phrase to bind their identity. For each transaction, customers can select an unused sub-address to anonymize their identity, making transaction records difficult to track and reconstruct, and enhancing privacy protection.

[0018] Data encryption transmission: All electricity transaction request data is encrypted using attribute-based encryption (ABE) or homomorphic encryption. The data contains key information such as electricity consumption and electricity price, but it will be encrypted off-chain before being uploaded to the chain and has a role-based access control tag (RBAC) to ensure that buyers can only access sellers' information and vice versa.

[0019] 2. BIP32 anonymization and alliance chain verification mechanism: BIP32 anonymization mechanism: Each user's transaction request is initiated by one of its sub-addresses rather than a fixed main address, thus breaking the continuity of the data link; the multi-address obfuscation strategy (similar to CoinJoin) makes it difficult for attackers to restore the user's identity or transaction habits from the blockchain; users can transfer funds between sub-addresses within their accounts, further concealing the actual transaction counterparty.

[0020] Consortium chain verification mechanism: Using the FISCO BCOS blockchain platform, transaction requests are verified by consensus nodes within the consortium chain using the PBFT algorithm after submission. Transaction data on the blockchain is initially verified by smart contracts to confirm the legitimacy of sub-addresses and the integrity of transaction structures. The zero-knowledge proof (ZKP) mechanism is used to verify the consistency of transaction electricity prices and transfer amounts, as well as whether electricity trading volumes are within a reasonable range, without disclosing specific values.

[0021] On-chain and off-chain collaborative matching: Off-chain nodes read encrypted transaction requests from the chain and match them based on local resource allocation control (RBAC) permissions. After the matching is completed, the administrator calls the smart contract to write the result to the chain. The transaction results are verified on the chain, and the correctness is verified by the zero-knowledge proof (ZKP) module before the electricity and funds are transferred.

[0022] System security assurance: 1. The customer constructs a transaction request: The power supplier and the power user each fill in the transaction intention, including the amount of electricity, price, and role. Sub-addresses are generated using BIP32 to ensure identity anonymity. Each transaction of each user uses a master key to derive multiple sub-addresses (such as A1, A2, ...) (BIP32), achieving transaction behavior decoupling and identity anonymity. Transaction data is encrypted using ABE (attributed encryption), which can only be decrypted by specific roles. Digital signatures are used to ensure data integrity.

[0023] 2. Off-chain submission & consortium chain verification: Encrypted transaction data is uploaded to the consortium chain via the smart contract publishTrade(); the consortium chain uses the PBFT consensus algorithm to verify transaction structure, signatures, role permissions, etc.; specifically, the consortium chain only verifies the legitimacy of the signature of the current transaction sub-address, that is, whether the transaction data is signed by the private key corresponding to the BIP32-generated sub-address; it does not need and will not be associated with the user's primary identity or other sub-addresses; signature verification is completed by the smart contract + consensus node through ECDSA or an equivalent algorithm; data is written to the blockchain in an encrypted state to ensure privacy; in the event of a dispute, the primary identity can be optionally traced through group signatures, achieving the dual protection of "anonymity + auditability".

[0024] In this embodiment, a distributed power trading method capable of protecting identity and data privacy includes the following steps: Step 1: The client constructs a transaction request (off-chain): like Figure 2 As shown in the figure, during the transaction initiation phase, power supplier A and consumer B each construct their own electricity transaction requests on the client. Each transaction request must include key fields, including the amount of electricity to be traded (in kWh), the desired price (in RMB / kWh), the transaction initiation timestamp, the user's role identifier (e.g., "buyer" or "seller"), and the pseudonymous address to be used. To protect user identity privacy from on-chain tracking, the system generates multiple subaddresses for each user based on the BIP32 hierarchical deterministic key derivation mechanism. Each transaction uses a unique, unused subaddress as the sender address, achieving identity obfuscation and anonymization. Once the transaction data is constructed, the system performs attribute-based encryption (ABE). Access policies (e.g., "visible only to supplier" or "accessible only to buyer") ensure that data decryption permissions are restricted to specific roles. Furthermore, to prevent data tampering, users digitally sign the transaction data with their private key, and the signature information is submitted along with the encrypted data. Finally, the constructed and encrypted transaction request is submitted to the off-chain matching system for subsequent processing. The off-chain system will determine whether it matches based on the strategy and transfer it to the on-chain evidence storage process.

[0025] Step 2: Call the smart contract to issue a transaction request: After the client constructs and encrypts the trade request, the off-chain matching system receives the encrypted data packets from Client A and Client B and begins the transaction on-chain process. First, the off-chain system encapsulates the user's trade request into a data structure that complies with consortium blockchain standards and calls the publishTrade() smart contract function deployed on the consortium blockchain platform. This function is responsible for officially registering the user's encrypted trade information on the blockchain network. Transaction data remains encrypted during transmission, ensuring that on-chain nodes cannot access the plaintext content, thereby ensuring a trusted record of transactions while protecting privacy. During this stage, the smart contract does not parse the transaction details but instead acts as a relay for information registration and evidence storage, writing the data to the consensus-pending block. Each trade request also includes the user's signature for subsequent verification. After the publishTrade() call is completed, the off-chain system submits the encapsulated request to the consortium blockchain platform for processing by the consensus nodes and consensus verification.

[0026] Step 3: The consortium chain platform distributes transactions to consensus nodes: Once a trade request submitted by the off-chain matching system through the publishTrade() smart contract enters the consortium chain platform, the platform immediately initiates the consensus process. As a permissioned, multi-node consortium chain network, it utilizes the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism to ensure the consistency and immutability of transaction data across multiple nodes. During this phase, the consortium chain platform broadcasts the received encrypted trade request to all consensus nodes. Each consensus node independently performs verification operations, specifically verifying the integrity of the data structure format, signature validity, caller address legitimacy, and the presence of valid access control policies (such as access role attributes and transaction identity roles). Notably, because the transaction data itself is encrypted using the ABE attribute, consensus nodes do not decrypt the plaintext data during the verification process; instead, they only verify the integrity of the signature and metadata. Once a majority consensus is reached through the three PBFT phases of pre-prepare, prepare, and commit, the trade request is deemed valid and is written to the blockchain ledger, proceeding to the next phase of on-chain data storage and privacy matching preparation.

[0027] Step 4: Write to blockchain (encrypt transaction data): Once consensus nodes reach consensus on a transaction request using the PBFT algorithm, the transaction is deemed valid and officially recorded in the consortium chain platform's blockchain ledger. Because the user-submitted data undergoes attribute-based encryption (ABE) and signature processing off-chain, the data written to the chain remains encrypted and does not contain any plaintext information about electricity consumption, electricity prices, or identities that can be deciphered by nodes. The blockchain then serves as an immutable record storage with privacy protection. All nodes can collectively witness the existence and submission time of the transaction request, but cannot access the specific transaction content. Furthermore, each transaction is associated with the user's BIP32 subaddress, ensuring that even if the same user conducts multiple transactions, their address appears on-chain as multiple, unlinkable identities, further enhancing anonymity. This step provides a trusted data source for the subsequent off-chain matching engine, while also ensuring data integrity and traceability. Throughout this process, on-chain evidence storage does not trigger any plaintext transactions or matching logic, fully adhering to the system design principle of "encryption on-chain, decryption for matching, and privacy verification."

[0028] Step 5: Off-chain transaction matching: After a transaction request is successfully written to the blockchain, the off-chain matching system begins the transaction matching process. This module periodically or in real time pulls all pending encrypted transaction requests from the consortium chain and determines data permissions based on access control policies and user roles. Specifically, Customer A, the power supplier, can only decrypt the content authorized for access in Customer B's transaction request, and vice versa. This decryption process is based on the ABE attribute policy established during encryption, ensuring that data is only accessible to authorized parties. After data decryption, the matching engine compares the transaction requests and performs matching based on pre-defined matching criteria, such as price matching, quantity matching, and time window overlap. The system can optimize matching using heuristic matching or linear programming models to improve matching efficiency and resource utilization. Upon successful matching, the matching system generates a matching result structure (Result), which contains the subaddresses, price, quantity, and other transaction metadata of both the supplier and the demander. This structure serves as the basis for subsequent on-chain verification and transaction execution, effectively connecting the supply and demand sides while ensuring privacy.

[0029] Step 6: Submit the matching results to the chain: After the off-chain matching system completes the matching of supply and demand, it encapsulates the successful transaction result in a Result structure and prepares it for submission to the consortium chain for on-chain recording and verification. This structure typically contains the BIP32 subaddresses of the power supplier and consumer, the electricity price, the electricity quantity, the matching timestamp, the matching ID, and other necessary transaction metadata. To ensure data consistency and integrity, the matching system re-signs the result and calls the updateTrade() smart contract function deployed on-chain to submit the result to the consortium chain ledger. This operation effectively generates a formal, pre-verified on-chain entry for a "candidate transaction," paving the way for subsequent privacy verification and execution. It is important to emphasize that key fields in the matching result remain encrypted or decrypted, and compliance verification is performed only off-chain or through zero-knowledge verification mechanisms to ensure that the identities of both parties and transaction details are not disclosed during the on-chain process. This step effectively connects off-chain matching with on-chain trust mechanisms and is a core component of the "off-chain computation, on-chain verification" privacy transaction architecture.

[0030] Step 7: Perform privacy verification (zero-knowledge proof, ZKP): After the matching results are successfully submitted to the consortium chain, the system initiates a privacy verification process to ensure that the matching results meet legality and compliance requirements without exposing plaintext data. During this phase, the consortium chain platform automatically invokes the on-chain privacy computing module and uses zero-knowledge proof (ZKP) technology to verify key fields in the matching results. First, the system verifies that the electricity prices used by the supply and demand parties in the transaction are consistent. The comparison function is called comparison(x,y) to determine whether the two encrypted electricity prices match. Second, the system calls range_compare(min,x,max) to verify that the supply and demand quantities fall within a reasonable range to prevent malicious matching or abnormal transactions. This entire verification process does not require the disclosure of plaintext data such as electricity prices and quantities. Instead, it uses mathematical proof to confirm that a certain condition holds. The verification result is returned as a Boolean value (true / false) and stored in the smart contract state as a prerequisite for subsequent transaction execution. This verification mechanism not only enhances the system's privacy protection capabilities but also ensures the authenticity and compliance of on-chain data, laying a secure and reliable foundation for the next stage of customer confirmation and automated transaction execution.

[0031] Step 8: Notify both parties to sign and confirm the transaction: After the matching results have been verified for privacy via a zero-knowledge proof (ZKP) module, the consortium chain platform will proactively notify both matching clients—power supplier A and consumer B—to confirm and sign the matching results. The system will send an on-chain transaction summary to each user, including essential information such as the matching transaction number, transaction time, electricity price, electricity consumption, and their respective subaddresses. The user will then be prompted to digitally sign the transaction using the private key corresponding to their BIP32 subaddress. This signature serves a dual purpose: first, it signifies the user's acceptance and authorization of the matching results, ensuring legal validity; second, it serves as a prerequisite for subsequent automated transaction execution, ensuring that each on-chain transaction is explicitly authorized by both parties. During this process, the user does not need to reveal their primary identity or the plaintext transaction content; the signature data is verified as part of the smart contract execution logic. If either party fails to sign within the specified timeframe, the system deems the transaction a failure and automatically retracts the matching result. Only after both parties have signed will the consortium chain platform proceed to the subsequent transaction execution phase, formally transferring electricity and funds.

[0032] Step 9: Execute the transaction (transfer of funds and electricity): Once both customer A (the power supplier) and customer B (the user) have completed digital signature confirmation of the matchmaking result, the consortium chain platform immediately triggers the automated transaction execution process. This process is executed by calling the smart contract function payTransaction() and is uniformly managed by the on-chain state control logic. Transaction execution is carried out simultaneously in two dimensions: Funds Transfer Layer: Based on the transaction amount defined in the matchmaking results, the system deducts the corresponding funds (which can be on-chain points, tokens, or a bound fiat currency account balance) from the electricity user's (Customer B) account and transfers them to the power supplier's (Customer A) account. Funds transactions are typically conducted through an on-chain token module or an off-chain escrow account to ensure irreversibility and payment integrity.

[0033] Energy Delivery Layer: Simultaneously, the power supplier delivers the matching amount of electricity to the user via the power transmission system. This process can be monitored in real time within the physical grid, or it can be recorded and confirmed in a virtual space using mechanisms such as a "power ledger" or energy gateway. The system can integrate with smart meters, IoT interfaces, and other technical infrastructure to automatically synchronize and verify the consistency of power delivery data with on-chain settlement data.

[0034] The entire transaction process is executed atomically under the control of smart contracts and cannot be split or rolled back, ensuring that once the funds are successfully transferred, the electricity will also be delivered, and vice versa, thus establishing a reliable, efficient and automated closed loop for electricity trading.

[0035] Step 10: Abnormal audit and identity tracing (optional): During system operation, if abnormal behavior occurs, such as malicious submission of false transaction requests, signature timeouts, intentional matching of abnormal prices, or attempts to tamper with on-chain data, the platform will trigger the anomaly detection mechanism and refer the matter to the system administrator for intervention. At this time, the administrator can initiate the audit process according to the platform policy and submit an audit request to the consortium chain to obtain all data related to the abnormal transaction, including transaction records, signature content, BIP32 subaddresses, etc.

[0036] To balance user privacy and traceability, this system introduces a group signature mechanism. Group signature technology allows users to remain anonymous in daily transactions, but with legal authorization, auditors can decrypt and trace the true identity of the signer. Administrators can call the group signature verification module to decrypt the signature in a specific transaction and restore the underlying identity (such as the primary address or registered account) of the principal involved in the transaction, which is used for responsibility determination and subsequent accountability.

[0037] After the audit is completed, the system will generate an audit report and record it on-chain, serving as the basis for handling disputes, arbitration, and supervision. Through this mechanism, the system not only protects users' daily privacy and anonymity, but also ensures the controllability and traceability of malicious behavior, providing strong support for the compliance, risk control, and governance capabilities of power transactions within the alliance chain.

[0038] It should be noted that conventional systems use fixed identity addresses, making it easy to track user behavior. This system uses a different identity for each transaction, making it impossible to establish a user profile. The method in this embodiment uses BIP32 subaddress anonymization. After each user registers, a master private key is generated. Multiple subaddresses are generated using the BIP32 hierarchical derivation mechanism, with each transaction using a different subaddress. Each transaction automatically calls BIP32 in Step 1 to generate a new address. Anonymity is supported by on-chain signature verification, ensuring that transactions remain verifiable.

[0039] It's important to note that traditional systems encrypt and then decrypt them centrally. This system allows encrypted data to be decrypted only by authorized users, achieving fine-grained control. With ABE (Attribute-Based Encryption), transaction data is encrypted off-chain using ABE encryption, with the encryption policy bound to the "role" attribute (e.g., buyer / seller). Encryption occurs when the customer constructs the transaction in Step 1. During matching in Step 5, decryption is performed off-chain based on the attribute policy.

[0040] It should be noted that standard on-chain verification requires exposing fields in plaintext; this system protects privacy while implementing conditional verification, balancing compliance and confidentiality. The zero-knowledge proof (ZKP) verification mechanism uses functions such as comparison() and range_compare() to verify conditions such as electricity price and power consumption without exposing plaintext. The Step 7 consortium chain calls the privacy verification module and automatically runs ZKP to verify the correctness of the matching results.

[0041] It should be noted that ordinary anonymous systems are difficult to audit and oversee; this system achieves both "anonymous transactions and auditability." The group signature mechanism combines auditable anonymity. In daily transactions, users use anonymous group signatures, and administrators hold audit keys to trace user identities when necessary. In Step 10, system administrators can initiate audit requests and verify the responsible parties through group signature verification.

[0042] It should be noted that consensus nodes are the core components of consortium chains (such as FISCO BCOS). They are responsible for verifying the legitimacy and integrity of transaction requests and participating in consensus to determine whether data can be written to the chain. The system uses the PBFT (Practical Byzantine Fault Tolerance) algorithm for fault-tolerant consensus. The verification process is as follows: Signature verification: Verify whether the transaction request is signed by a valid BIP32 subaddress; Structural verification: Check whether the transaction data conforms to the predefined structure format (for example, whether the fields such as electricity price, electricity consumption, role identification, etc. are complete); Permission field check: confirm whether a valid access policy is set in the ABE encrypted data; Timestamp and repeatability check: Determine whether the transaction is within the valid time window and whether it is a repeated submission.

[0043] Each consensus node performs the aforementioned verification on the received transaction; nodes communicate with each other through a three-phase process: pre-prepare, prepare, and commit. Once more than two-thirds of the consensus nodes agree, the transaction is written to the consortium chain ledger. It's worth noting that because transaction data is encrypted with ABE, nodes only verify the structure and signature, not the content, ensuring privacy.

[0044]

[0045] In some embodiments, the above-mentioned distributed power trading method and system capable of protecting identity and data privacy may also be implemented in the following manner.

[0046] The user initially submits and broadcasts a transaction request to the system based on their own needs. The system then uses the off-chain matching code to perform distributed matching on the received transactions and returns the matched transaction information to the user. After confirmation, the user signs the transaction and submits it to the alliance chain for certification. After being certified by the consensus node in the alliance chain, the transaction information can be uploaded to the chain. Finally, the smart contract executes the transaction content and transfers the transaction electricity and transaction amount.

[0047] During this process, this embodiment is supplemented by "triple privacy protection". The first level uses BIP32 to provide users with identity privacy protection, thereby protecting user identity information; the second level uses attribute encryption to set up specific access structures for users and traceability data, thereby achieving fine-grained access control of data; the third level uses group signatures to achieve traceability of user identities, and based on zero-knowledge proof, achieves equality of transaction result amounts and consistency of transaction volume ranges, thereby verifying the legitimacy of transactions.

[0048] This embodiment takes distributed transactions as the scenario, designs an electricity trading system based on the alliance chain, and uses a variety of cryptographic technologies to protect the identity and privacy of users in the system.

[0049] The system's business process is as follows Figure 2 As shown, the overall framework of the system is as follows Figure 3 As shown, the confidential transaction query is shown as follows Figure 4As shown; 1. Data linking process: Clients A and B construct an encrypted transaction request → submit it to the blockchain using the publishTrade() smart contract; the consensus node completes verification, and the transaction request (encrypted) is written to the blockchain; the data cannot be tampered with on the chain and remains encrypted to prevent nodes or other users from peeping.

[0050] 2. Matching process (off-chain): The off-chain matching system periodically pulls all valid transactions on the chain. According to the role access policy, customer A can only decrypt customer B's quote (and vice versa). The matching algorithm (such as based on electricity price / volume matching, minimum cost / maximum benefit) is executed. After a successful match, a matching result structure (Result) is generated, including fields such as the sub-addresses of both parties, electricity price, and electricity volume.

[0051] 3. Verification data generation (on-chain verification): The matching system calls updateTrade() to submit the matching results to the consortium chain; the consortium chain triggers the ZKP verification module to perform verification: electricity price consistency verification → use comparison() to determine whether the electricity prices of both parties are equal; power rationality verification → use range_compare(min,x,max) to determine the power range; the verification result is a Boolean value, which is written into the contract status to determine whether the transaction is executable; the verification process does not expose plaintext fields to protect privacy.

[0052] At the business layer, processing and calculation modules for various parts of data are deployed, such as relevant hardware information of the client, model information of the server, and so on. The server implements the service of transmitting the above data, completes the processing and is responsible for the persistence of the data. The data layer defines specific entities, which are mainly responsible for the persistent storage of data. The software architecture of the system is divided into the network configuration layer, the smart contract layer, the middleware layer and the website application layer from the bottom to the top. Among these four layers, the smart contract layer and the middleware layer are the most important parts. The smart contract layer defines how users interact with the alliance chain ledger, while the middleware layer can handle registration issues on the one hand, and on the other hand, it can call smart contracts to achieve transaction matching in a collaborative way on the chain and off the chain. Including: function introduction, authorization and authentication of user identity, trusted power trading and security audit, confidential transaction query, reliable data storage, data visualization analysis; Key points in the implementation plan: The first is a distributed power trading consortium chain: This distributed power trading identity and data privacy protection system, based on privacy computing, combines the technical characteristics of consortium chains with distributed (decentralized) power trading to develop and design smart contracts for power trading, store transaction information and results, and automatically execute fund transfers. This embodiment uses FISCO BCOS as the underlying blockchain platform. Based on the diverse business scenarios of the distributed power trading market, this system utilizes distributed ledgers, high-speed consensus, and smart contract technologies to build a high-yield and highly reliable trading platform. It can accommodate no fewer than 50 node users and implement identity authentication, power query, user transactions, and information storage.

[0053] The second is the transaction process: transactions are the core of the blockchain system and are responsible for recording everything that happens on the blockchain. After the introduction of smart contracts in the blockchain, transactions have transcended the original definition of "value transfer" and should be more accurately defined as a digital record of a transaction in the blockchain. Regardless of the size of the transaction, transactions require the participation of transactions. Figure 5 shown.

[0054] It's important to note that transactions are at the core of blockchain systems, responsible for recording all events and actions on the blockchain. With the introduction of smart contracts, the concept of transactions has evolved beyond its original definition of "value transfer" to become a digital record of every transaction on the blockchain. Regardless of the size of the event, transactions are required for confirmation and evidence.

[0055] In the trusted power transaction and security audit scenario, such as Figure 5 As shown, the blockchain records not only changes in electricity consumption or amount, but also the execution details of each order and the user's operation behavior. This mechanism ensures the traceability and immutability of the system.

[0056] Furthermore, to protect user rights, the system also features an "Order Complaint" feature: If a user disagrees with an order, they can proactively file a complaint, stating the reason for the complaint and submitting supporting documentation. The system will then verify and handle the complaint according to the appropriate procedures. This mechanism enhances the transparency and fairness of the trading system.

[0057] The third is smart contracts: This embodiment designs smart contracts such as power transaction request on-chain, power transaction matching result on-chain, power query and fund transfer. Figure 6As shown, the smart contract is written in Solidity and compiled into abi and bin files on the WeBase management platform. The first step in the smart contract is to define the content of the consortium chain database record. To this end, two structures, Request (transaction request) and Result (matching result), are defined to record the transaction data submitted by the user and the transaction matching results reached after the transaction is completed. This example then creates four functions in the smart contract: publishTrade, updateTrade, payTransaction, and getTrades, representing the upload of power transaction requests to the blockchain, the upload of power transaction matching results to the blockchain, fund transfers, and power queries, respectively.

[0058] Fourth, the access mechanism: Based on the introduction of the group concept, node access management can be divided into network access and group access mechanisms. The rules of the access mechanism are recorded in the configuration. After the node starts, it reads this configuration information to determine network and group access. Configuration items related to node access management include: P2P node connection list, node certificate, CA blacklist, group node initial list, and group node system table.

[0059] Fifth, the consensus algorithm: FISCO BCOS uses the PBFT algorithm to ensure the consistency of the entire system. The general process is: each node first independently executes the same block, and then the nodes exchange their execution results. If more than 2 / 3 of the nodes reach the same execution result, it means that the block has been agreed upon by the majority of nodes, and the nodes will start to generate blocks.

[0060] Sixth, privacy protection for distributed power trading identities: This ensures anonymity and concealment of power trader identity information, ensuring user identity privacy during the security authentication process of the blockchain-based distributed power trading system. It also provides the ability to track and trace specific user identities. A privacy protection module is provided for node developers, deployed as a low-level component of the trading platform. Specifically, the BIP32 protocol is used to anonymize user identity information, and randomized group signature cryptography is employed to ensure privacy protection for power traders and, where necessary, audit tracking.

[0061] Seventh, the BIP32 protocol: To protect node transaction data, the most direct method is to encrypt the transaction data and transmit the data in ciphertext form. However, decrypting the data in a brute force manner may also cause the transaction data to be leaked. In addition, if a user uses the same address for multiple transactions, malicious nodes may track the user and steal the user's electricity usage habits based on observation and data prediction, thereby tampering with their transaction data. The above problems pose a great threat to user privacy. Therefore, this embodiment is designed to solve the problem from the source: First, through the BIP32 protocol, the user has multiple sub-addresses to ensure that the transactions reached by the user come from different addresses, thereby forcing malicious nodes to be unable to track the user and obtain the user's electricity usage habits. Second, the user uses different sub-addresses under his account to transfer transactions, thereby confusing electricity transactions with other users, and further protecting the user's transaction data. Specifically, in the power trading system of this project, users will have their account names and account addresses after registration. This embodiment uses the account address as a parameter to generate different sub-addresses for the user to choose when trading. At the same time, this embodiment will also generate corresponding mnemonics based on the user's account address. The user only needs to remember the mnemonics to find the sub-address to prevent the user from forgetting. For example, the account address of user A is "0xa9b65ff4e84790bc0c36d48e8d86267a609b252b", and the account address of user B is "0xc4a291d903e710b5320a45f782164d7ee5e27793". The mnemonics and sub-addresses corresponding to each account can be obtained through the BIP32 protocol, as follows Figure 7 As shown below: Next, user A and user B can use different subaddresses to trade electricity and simultaneously use the subaddresses under their accounts to conduct transfer transactions: user A uses subaddress 1 as the seller to trade electricity with user B's subaddress 2 as the buyer. User A uses subaddress 14 as the buyer to trade with user B's subaddress 15 as the seller. User A uses subaddress 2 to conduct a transfer transaction with subaddress 15 of the same account. User B uses subaddress 1 to conduct a transfer transaction with subaddress 14 of the same account. User A can only see that they used two different subaddresses to trade electricity with two unknown addresses and that they conducted a transfer transaction with their own two addresses. User A is completely unaware of transaction four, and user B is similarly unaware of transaction three. However, to other users not participating in these transactions or malicious nodes, the four transactions are completely unknown data, and all transaction addresses appear to be different, seemingly belonging to different accounts. In this scenario, it is impossible to infer the participants and transaction types of the transactions, thereby obfuscating transaction data and transfer data, protecting user privacy.

[0062] Eighth, randomized group signature: One of the advantages of blockchain is traceability. In order to protect user information in the power trading system, this embodiment needs to protect user identity and transaction data. However, when a transaction conflict occurs, it is necessary to track the user and transaction data, that is, the transaction needs to be traced. In this scenario, this embodiment is designed to use randomized group signature cryptography technology to anonymously transform user identity information to achieve privacy protection of the power trader's identity and audit tracking when necessary. This embodiment is designed to ensure that all users participating in the transaction belong to the same group. Users participating in the same transaction need to perform randomized group signatures on the transaction at the same time, and the system, as the group administrator, is responsible for interacting with group members. The specific process is as follows: Group signature generation is as follows: Figure 8 As shown, when a transaction conflict occurs, the signature can be verified and tracked by the following methods: Figure 9 shown.

[0063] The ninth area is distributed electricity privacy trading: privacy protection of transaction prices and volumes during private transactions, as well as private computational updates of transaction data. After the transaction is completed, transaction results can be verified without disclosing the transaction result data. A decentralized trading module will be developed for nodes, deployed at every node in a fully connected node network. It will have the following functions: transaction matching (matchmaking); the ability to perform encrypted computations to protect sensitive transaction data; and the ability to provide zero-knowledge proofs of the equality of transaction amounts and the range of transaction amounts.

[0064] (1) Privacy calculation update of transaction data: In order to design a decentralized electricity trading algorithm, it is deployed to each node of the network. Node users interact and negotiate with each other (the nodes directly interact with each other on transaction price and transaction volume). Transactions are completed by transmitting transaction price and transaction volume information, ultimately maximizing market benefits. That is, The specific explanation of market efficiency maximization is: represents the cost of n, Indicates benefits. When it is a positive number, it means n is a generator. The larger it is, The greater the power generation, The higher the cost; When it is a negative number, it means n is a user. The smaller it is, the greater the power consumption. The smaller (equivalently, The larger the value, the greater the benefits. This algorithm also ensures the privacy of transaction information during the transaction process, protecting the transaction price and volume during negotiation and preventing security issues caused by privacy leaks. During data exchange, the privacy of the transaction price and volume during power transaction negotiation is protected, as is the private computation and update of transaction data. After the transaction is completed, zero-knowledge proof technology is used to provide proof of equality of transaction amounts and proof of transaction volume range without disclosing transaction results. A proof of transaction volume range verifies that the total transaction volume (power) of a single node is within its own upper and lower power limits.

[0065] (2) Verifying transaction results: In distributed power privacy transactions, it is very important to verify the transaction results to ensure the correctness and credibility of the transaction. At the same time, the privacy of the transaction results needs to be protected, so privacy computing is required. After the transaction is completed, the parties involved can use multi-party computing technologies such as zero-knowledge proof (ZKP), secure multi-party computing (SMC), or homomorphic encryption to verify the transaction results without leaking the transaction result data.

[0066] (3) Role-based access control: This system is an electricity trading system, in which the user roles are buyers and sellers. While the transaction information between the buyer and seller is encrypted and uploaded to the chain, combined with the project's own requirements and information security protection, users with the role of buyer can only obtain the seller's transaction information; the same applies to sellers. This embodiment adopts a role-based access control method (RBAC) to assign permissions to users according to their roles in the system. RBAC provides fine-grained control and a simple and manageable access management method. Compared with assigning permissions individually, this method is less prone to errors. Another advantage of RBAC is that it provides system administrators with a relatively abstract access control hierarchy similar to the usual business management of enterprises. By defining and establishing different roles, the relationship between roles, and corresponding restrictions, administrators can dynamically or statically regulate user behavior. Specifically, the system administrator must first define roles according to the current system requirements. Roles can only be defined by the system administrator, and the addition and removal of role members can only be performed by the system administrator. That is, only the system administrator has the right to define and assign roles. Next, the system administrator will define multiple permissions and pair each role with different permissions. There is also a many-to-many relationship between permissions and roles, which can be flexibly determined according to business needs. For the user application process, the user will first initiate an admission request to the system, which contains the role selected by the user. The management will issue a role-based key based on the user information. Figure 10 As shown, in this embodiment, the role is temporarily the buyer: and sellers The buyer's rights include: {get the transaction information of the seller in this round and match the transaction locally to check the price after matching}, the seller's rights include: {get the transaction information of the buyer in this round}, the seller The seller's permission SS can be executed, but the buyer's permission BB cannot be executed. Similarly, the buyer This is also true. That is, in this embodiment, based on the RBAC policy, the system defines two roles. Each role can perform certain functions. Different users are assigned corresponding roles based on their functions and responsibilities. Once a user becomes a member of a role, the user can perform the functions of the role.

[0067] (4) On-chain and off-chain collaborative technology: In order to meet the needs of privacy protection, only the ciphertext of the transaction request can be stored on the chain. If you want to match transactions, this embodiment can use homomorphic encryption to directly call the smart contract to execute on the chain. However, this embodiment can also execute the distributed algorithm locally off-chain, and use attribute-based access control to cooperate with the off-chain to obtain the on-chain ciphertext for decryption. According to the on-chain and off-chain collaborative architecture, part of the transaction process is placed off-chain to improve transaction processing capabilities. The process of off-chain transaction matching is as follows: the administrator calls the function in the smart contract to obtain the quotation information submitted by the user, and then uses the off-chain matching code to perform distributed transaction matching and obtain the transaction results. In order to write the transaction results back to the chain, the off-chain matching code calls the function in the smart contract through the administrator and writes the matching results to the alliance chain ledger. The client and management diagram visualization interface is as follows: Figure 11 As shown: (5) Distributed matching algorithm: The cost or benefit to each participant is modeled as a quadratic function: , Is a given parameter, which has no corresponding actual meaning. It is the power generation or consumption, with upper and lower power limits. Here, n represents the participant number. This embodiment assumes that the unit time length is 1 hour, so that the power and electricity values ​​are equal. The system optimization goal of local execution is ,in, is the expected electricity consumption of users of other properties. Constraints include price constraints and constraints on the total transaction electricity consumption based on the user's expected electricity consumption. Specifically, users submit their expected transaction prices and electricity consumption in this system every 5 minutes. These are uploaded to the chain as transaction requests. The local user then retrieves the transaction request of the other party on the chain according to role-based access control. First, the local user matches the transaction request object that meets its expected price according to its own transaction price. Second, the local user retrieves the corresponding parameters ({an, bn}) from the chain based on the transaction request and fills them into the objective function. The constraints are obtained by combining its own needs with all successfully matched transaction requests. After that, the optimization calculation of the local objective function can be performed. Finally, after a series of steps such as constructing the Lagrangian function, solving the Lagrangian dual problem, solving the dual problem, and inferring the optimal solution, the transaction matching result is finally obtained. Figure 12 The system demonstrates its innovative design in user identity authorization and authentication: after the user completes identity access, the system automatically generates and displays a unique session key and mnemonic phrase to ensure that their identity can be safely restored in the future. This dual identity credential mechanism enhances the user's control over their own on-chain identity, while supporting multi-sub-address binding and unified management, greatly improving operational flexibility and system compatibility. Through convenient interactive functions such as "one-click copy", users can efficiently call identity information to participate in blockchain transactions and smart contract execution, truly realizing the combination of decentralized identity management and multi-account collaborative authorization. This design not only improves the user experience, but also provides higher security and operational efficiency for actual application scenarios such as trusted power transactions, reflecting the practicality and innovation of the system in the blockchain identity system. Such as Figure 13 The following is a schematic diagram of the distributed matching algorithm: Specifically, zero-knowledge proof includes the following: Algorithm module: This system uses the Groth16 algorithm, which corresponds to the ppzksnark proof system in the libsnark library.

[0068] Basic modules: a) Generation algorithm: G(C, lambda): Input parameters: logic program C, parameter lambda; Return: public parameters (pk, vk), where pk is the proving key and vk is the verification key; b) Proof algorithm: P(pk, public_input, witness): Input parameters: pk proving key, public_input public input, witness secret value; Return: proof; c) Verification algorithm: V(vk, public_input, proof): Input parameters: vk verification key, public_input public input, proof; Return: true or false; Calling modules: a) Comparison module for two numbers: comparison(x,y); b) Comparison module for ranges: range_compare(min,x,max); Regarding transaction equality: Users receive the electricity price returned after the transaction is matched. After confirmation by both parties, the electricity and funds are transferred. During the transfer, it is necessary to verify that the transaction price is equal to the transferred funds and reach consensus with other nodes. The comparison module, called comparison(x,y), is used. If x and y are equal, "x=y" is output.

[0069] Regarding transaction volume range correctness: When initiating a transaction request, the user's power consumption must meet their own power limits, or the power delivered or received must be within a reasonable range for reaching transaction consensus (transmission losses may apply). Prove the correctness of the power range and reach consensus with other nodes. Use the range comparison module range_compare(min,x,max) to output "min<=x<=max" if x falls within the range [min,max].

[0070] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the present invention and the claims, all of which are protected by the present invention.

Claims

1. A distributed power trading method capable of protecting identity and data privacy, characterized in that: The following steps are involved: S1: Get the power transaction request based on the key field information; S2: Publish the electricity transaction request to the alliance chain platform using a smart contract; S3: Broadcast the electricity trading request to all consensus nodes and use the practical Byzantine fault tolerance algorithm to confirm the legitimacy of the electricity trading request; S4: Writing the power transaction request into the blockchain account book based on the legitimacy of the power transaction request; S5: Decrypt and match the blockchain ledger to obtain a matching result structure; S6: Obtain the on-chain registration item using the smart contract based on the matching result structure; S7: Verify the on-chain registration item and update the smart contract status; S8: Obtain a signed transaction contract based on the smart contract state and private key; S9: Execute the transaction according to the signed transaction contract to obtain the transaction result.

2. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: Step S1 specifically includes: S11: using the BIP32 protocol to obtain multiple sub-addresses; S12: obtaining a digital signature based on the private key; S12: obtaining an electricity trading request based on key field information using attribute encryption and digital signature.

3. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: The key field information includes the intended transaction power, expected electricity price, transaction initiation timestamp, user role identification, and user anonymous identity address.

4. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: Step S5 specifically includes: S51: decrypting the blockchain account book according to the access control policy and user role to obtain the authorized access content; S52: matching the authorized access content and the set matching conditions to obtain a matching result structure.

5. The distributed power trading method capable of protecting identity and data privacy according to claim 4, characterized in that: The set matching conditions include matching electricity prices, matching electricity quantities, and overlapping time windows.

6. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: Step S7 specifically includes: using zero-knowledge proof to verify whether the electricity prices of the supply and demand parties in the transaction are consistent, using zero-knowledge proof to verify whether the supply and demand electricity volume falls within a preset range, and obtaining a verification result based on whether the electricity prices are consistent and whether the supply and demand electricity volume falls within the preset range; updating the smart contract status based on the verification result.

7. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: Step S8 specifically includes: S51: obtaining an on-chain transaction summary based on the smart contract status; S52: digitally signing the on-chain transaction summary to obtain a signed transaction contract.

8. The distributed power trading method capable of protecting identity and data privacy according to claim 7, characterized in that: The on-chain transaction summary includes the matched transaction number, transaction time, electricity price, and sub-addresses of both the electricity supply and demand parties.

9. The distributed power trading method capable of protecting identity and data privacy according to claim 1, characterized in that: Also includes: Conduct abnormal audit and identity tracing based on the transaction results to obtain an audit report; The blockchain is updated according to said audit report.

10. A distributed power trading system capable of protecting identity and data privacy, characterized in that: The system includes the following modules: The transaction request construction module is configured to: obtain the power transaction request according to the key field information; A transaction request publishing module is configured to: publish the power transaction request to the alliance chain platform using a smart contract; A transaction request distribution module is configured to: broadcast the power transaction request to all consensus nodes and confirm the legitimacy of the power transaction request using a practical Byzantine fault tolerance algorithm; a transaction data encryption module configured to: write the power transaction request into the blockchain account book based on the legitimacy of the power transaction request; The transaction chain matching module is configured to: decrypt and match the blockchain ledger to obtain a matching result structure; The transaction matching and on-chain module is configured to: obtain the on-chain registration item using the smart contract according to the matching result structure; A privacy verification module configured to: verify the on-chain registration item and update the smart contract status; A transaction confirmation module is configured to: obtain a signed transaction contract based on the smart contract state and private key; The transaction execution module is configured to: execute the transaction according to the signed transaction contract to obtain the transaction result.

Images