Cross-chain atomic interaction method of multi-chain cooperation platform for power data transaction

Abstract

The invention provides a cross-chain atomic interaction method of a multi-chain cooperation platform for power data transaction, and relates to the technical field of power data transaction. A payment signature is bound with a data decryption condition through an adapter signature mechanism, so that payment is confirmed on a public chain and can be decrypted into an inseparable event with data on an alliance chain, cross-chain atomic delivery can be completed without a hash time lock, interaction turns on the chain are reduced, and the transaction success rate is remarkably improved. And secondly, a large amount of calculation-intensive data analysis operation is migrated into the TEE to be executed, and the alliance chain and the public chain only need to store lightweight data such as result hash and signature, so that the calculation load on the chains is greatly reduced, and the overall throughput capacity and response efficiency are improved. Finally, the method does not depend on block header verification, multi-signature bridging or external verifiers, can flexibly adapt to block chains with different consensus mechanisms and different performance characteristics, and realizes good portability and deployment convenience.

Description

Technical Field

[0001] This invention relates to the field of power data trading technology, specifically to a cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading. Background Technology

[0002] With the increasing penetration of new energy sources and the widespread deployment of smart meters, the amount of data generated in the power industry is growing exponentially, and the demand for sharing, trading, and collaborative analysis of power data is also rising rapidly. To improve transparency and traceability, blockchain technology is gradually becoming an important infrastructure for power data exchange. However, due to factors such as high on-chain storage overhead and high smart contract execution costs, a single chain structure cannot simultaneously support large-scale data processing tasks and high-frequency payment settlement logic, resulting in limited system throughput, high processing latency, and insufficient scalability.

[0003] Currently, a common technical approach involves deploying power data processing tasks on permissioned blockchains such as consortium blockchains, while relying on public blockchains for value transfer processes such as token payments. While this "dual-system architecture" improves flexibility to some extent, the lack of a reliable coordination mechanism between the data chain and the payment chain prevents data delivery and payment settlement from being automatically linked, thus affecting the overall credibility of transactions. Furthermore, cross-chain communication becomes a bottleneck for the entire system, necessitating the design of effective cross-chain interaction methods for heterogeneous blockchain environments.

[0004] Existing cross-chain technologies can be broadly categorized into three types: external verification, native verification, and local verification based on hash time locks. External verification relies on third-party validators or multi-signature bridges to synchronize events between chains, but it carries the risk of centralization. Native verification requires the target chain to verify the source chain's block header or proof structure. While this offers higher security, it incurs enormous computational overhead, making it difficult to meet the performance requirements of power data-intensive scenarios. Cross-chain exchange mechanisms based on hash time locks can complete value exchange in a trustless environment, but they require multiple rounds of on-chain interaction. Processing latency fluctuates significantly with the chain's block generation speed, and they struggle to support combined transaction requirements such as "off-chain data + on-chain payment."

[0005] To ensure the security and efficiency of cross-chain power data transactions, an ideal cross-chain method needs to simultaneously meet the following key attributes: (1) Atomicity, meaning that successful payment must be strictly bound to successful data delivery; (2) High throughput, maintaining stable processing capabilities under high request volumes; and (3) Low overhead, minimizing the number of on-chain operations and state updates. However, it is not easy for existing technologies to simultaneously meet these three points. External verification schemes have trust risks, native verification schemes have high resource overhead, and time-lock-based schemes have long processing delays and are not suitable for heterogeneous chain environments, resulting in insufficient overall availability and scalability. Summary of the Invention

[0006] To address the shortcomings of existing technologies, the present invention aims to propose a cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading, comprising:

[0007] For nodes in the trusted execution environment oracle network participating in power data transactions, construct the corresponding task data packets for the nodes in the power data hosting cloud;

[0008] Based on the power data transaction request constructed by the data buyer, determine the master node among all nodes in the trusted execution environment oracle network, select y nodes as execution nodes, and obtain the execution node set;

[0009] Based on power data transaction requests, a task structure containing a specified master node is constructed and the task structure is broadcast to each execution node;

[0010] The execution node retrieves its corresponding task data package from the power data hosting cloud. The master node and the execution node analyze and process the task data package to obtain the aggregation result. ;

[0011] Data buyers obtain aggregated results The settlement interface of the RPUC contract on the consortium blockchain is invoked to confirm that the aggregation result has been successfully received. .

[0012] Optionally, the task data packet corresponding to the building node includes:

[0013] All participants in the power data transaction register their identities to obtain a set of participating entities, and each participant registers its identity identifier. and public key The participants include data buyers, data sellers, and all nodes in the trusted execution environment oracle network;

[0014] Data sellers use data keys Power data Encryption is performed to obtain ciphertext data. Based on the public key of each node in the trusted execution environment oracle network, the data key is... The data is encapsulated to obtain data node encapsulation, and the data seller then transmits the encrypted data. All data nodes are encapsulated and uploaded to the power data hosting cloud;

[0015] Data buyer uses program key For the preset analysis program Encryption is performed to obtain the program ciphertext. Based on the public key of each node in the trusted execution environment oracle network, the program key is... The process involves encapsulation to obtain program node encapsulation, and the data buyer then transmits the encrypted program data. All program nodes are packaged and uploaded to the power data hosting cloud;

[0016] In the power data hosting cloud, each node in the trusted execution environment oracle network corresponds to a task data packet, which includes encrypted data. ciphertext and node encapsulation The node encapsulation This includes data node encapsulation and program node encapsulation.

[0017] Optionally, the power data transaction request is represented as follows: ;

[0018] in, For the entity that buys the data, The set of entities that are data sellers participating in the transaction. For the cross-day time range of power data transaction requests, For the intraday time range of power data transaction requests, Indicates the region to which the power data belongs. This indicates the data type of the power data transaction request. This indicates the number of tokens the data buyer needs to pay on the payment chain. This represents the trusted computation parameters required to execute the task. AGG is the address of the master node responsible for result aggregation in the trusted execution environment oracle network.

[0019] Optionally, the method for determining the master node is as follows:

[0020] The master node is determined based on AGG in the power data transaction request.

[0021] Optionally, select y nodes as execution nodes to obtain a set of execution nodes, including:

[0022] The data buyer submits the Power Data Transaction Request (PDT) to the Data Transaction Request Contract (DTRC). DTRC receives the PDT and uses a hash algorithm to generate the PDT's Task Identifier (TID). DTRC triggers a cross-contract call or throws an on-chain event for the Oracle Task Scheduling Contract (OTDC) to capture. OTDC selects y nodes from all nodes in the Trusted Execution Environment Oracle Network as execution nodes and obtains the execution node set.

[0023] Optionally, the execution node retrieves its corresponding task data package from the power data hosting cloud, and the master node and execution node analyze and process the task data package to obtain the aggregation result. ,include:

[0024] Each execution node obtains its corresponding task data package in the power data hosting cloud, processes the task data package, obtains a node report, and sends it to the master node.

[0025] The master node receives node reports, generates a target request based on the task structure and the node reports, and submits it to the result credential on-chain contract RPUC; the target request includes a task identifier (TID) and an aggregation result. and voucher list ;

[0026] The RPUC contract, which records the result credential on-chain, receives the target request, processes and verifies it, and stores the aggregation result upon successful verification. And trigger on-chain events.

[0027] Optionally, each execution node retrieves its corresponding task data packet from the power data hosting cloud, processes the task data packet, obtains a node report, and sends it to the master node, including:

[0028] For each execution node, the execution node obtains the corresponding task data packet from the power data hosting cloud through the predefined ECALL secure call interface function, and passes it to the execution node's secure enclave module;

[0029] In the secure enclave module, the private key of the execution node is used. Encapsulation of nodes Decrypt to obtain the data key. and program key Using data keys and program key , respectively for the encrypted data and program ciphertext Perform the decryption operation to obtain the power data. With analysis program ;

[0030] Execution node running analysis program For power data The analysis was performed, and the results were obtained. The execution node uses a hash algorithm to calculate a summary of the analysis results. Based on the private key of the execution node Generate summary signature Analysis results ,summary and signature The result data packet is composed of the execution node, which exports the result data packet from the secure enclave module through the OCALL security interface or security return value mechanism, and encapsulates the result data packet in a structured manner through a trusted channel to obtain a node report, which is then sent to the master node.

[0031] Optionally, the master node receives node reports, generates a target request based on the task structure and the node reports, and submits it to the result credential on-chain contract RPUC, including:

[0032] The master node receives node reports and uses the public key of the execution node corresponding to the node report to verify the signature in the node report. When the verification is successful, it indicates that the signature of the node report is a valid signature. When the verification fails, it indicates that the signature of the node report is an invalid signature. After the number of node reports containing valid signatures received is greater than a preset number α, the analysis results are extracted from all node reports containing valid signatures to construct a result matrix.

[0033] The aggregated result is obtained by aggregating the result matrix using aggregation functions. Report the corresponding node entity of all nodes containing valid signatures. ,summary and signature Package and obtain a list of vouchers. , call The function combines the task identifier (TID) and the aggregation result. and voucher list The target request is submitted to the result certificate on-chain contract RPUC.

[0034] Optionally, the RPUC contract on-chain the result certificate receives the target request, processes and verifies it, and stores the aggregation result when the verification is successful. And trigger on-chain events, including:

[0035] The resulting credential on-chain contract RPUC receives the target request and determines whether all node entities in the target request belong to the execution node set. If any node entity in the target request does not belong to the execution node set, the target is discarded. If all node entities in the target request belong to the execution node set, a signature verification function is used to verify the public key, digest, and signature corresponding to each execution node in the target request, obtaining a verification result. If the verification result indicates that the verification fails, the node entity, digest, and signature of that execution node are deleted from the credential list, resulting in a filtered credential list. If the number of execution nodes in the filtered credential list is less than a preset threshold, the transaction is terminated. If the number of execution nodes in the filtered credential list is greater than or equal to the preset threshold, it indicates that the RPUC verification is successful, and the aggregation result is stored. And trigger on-chain events.

[0036] Optionally, the data buyer obtains the aggregated results. ,include:

[0037] The master node generates a random secret value r within the Trusted Execution Environment (TEE) and calculates the public commitment to the random secret value r. Where G represents the elliptic curve generator, and the master node uses a random secret value r as the symmetric encryption key to perform aggregation on the result. Perform encryption operations to generate aggregated ciphertext. , will aggregate ciphertext And publicly commit R to send to the data buyer;

[0038] The data buyer receives the aggregated ciphertext The transaction is terminated if the publicly committed commitment R is not a valid point on the elliptic curve; otherwise, a payment transaction pointing to the master node address is constructed. The payment transaction includes the token amount to be paid. Construct a payment pre-signature based on the adapter signature algorithm. The data buyer will pay for pre-signed data. and Send to the master node, the master node receives the payment pre-signature. and And combined with a random secret value r, the payment pre-signature Convert to a valid signature ;

[0039] Will have a valid signature payment transactions Broadcast to the payment chain, in the payment transaction Valid signature after confirmation by the payment chain Publicly available;

[0040] Data buyer obtains valid signature And calculate the valid signature. and payment pre-signature The difference between them is used to calculate the random secret value. The data buyer aggregates ciphertext using random secret values. Perform the decryption operation to obtain the aggregated result. .

[0041] The beneficial effects of adopting the above technical solution are as follows:

[0042] By binding payment signatures with data decryption conditions through an adapter signature mechanism, the confirmation of payment on the public blockchain and the decryption of data on the consortium blockchain become inseparable events. This achieves atomic cross-chain delivery without hash time locks, reducing on-chain interaction rounds and significantly improving transaction success rates. Secondly, this invention migrates a large number of computationally intensive data analysis operations to the TEE (Transaction Execution Environment). The consortium and public blockchains only need to store lightweight data such as result hashes and signatures, significantly reducing on-chain computational load and improving overall throughput and response efficiency. Finally, this invention does not rely on block header verification, multi-signature bridging, or external validators, and can flexibly adapt to blockchains with different consensus mechanisms and performance characteristics, achieving good portability and deployment convenience, and possessing significant engineering application value. Attached Figure Description

[0043] Figure 1 This is a diagram of a power data trading platform under a dual-chain architecture in an embodiment of the present invention;

[0044] Figure 2 This is a flowchart illustrating the cross-chain atomic interaction method for a multi-chain collaboration platform for power data transactions in an embodiment of the present invention.

[0045] Figure 3 This is a flowchart of the power data transaction process under the dual-chain architecture in this embodiment of the invention. Detailed Implementation

[0046] The specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and are not intended to limit the scope of the invention.

[0047] This invention addresses the common problems in existing cross-chain power data trading systems, such as difficulty in synchronizing data delivery and value settlement, low efficiency due to reliance on multiple on-chain operations for cross-chain interaction, poor security, and high on-chain execution load. It proposes a cross-chain power data trading method and system based on a dual-chain collaborative architecture and adapter signature mechanism. Currently, power data analysis tasks are typically executed on consortium blockchains, while payment settlement is completed on public blockchains. The lack of a reliable coordination mechanism between the two chains means that successful payment does not necessarily guarantee data decryption and delivery, posing a risk of inconsistent transaction results. Furthermore, existing cross-chain interaction methods mostly rely on external validators or hash time-lock technology. The former suffers from centralized trust issues, while the latter requires multiple on-chain interactions, resulting in high transaction latency and a high failure rate. In addition, some on-chain cross-chain verification schemes require verification of the source chain block header, incurring high computational overhead and failing to meet the high throughput and low latency requirements of power data scenarios. Therefore, it is necessary to design a novel cross-chain power data trading method that combines cross-chain atomicity, high performance, and low on-chain load.

[0048] To address the aforementioned technical challenges, this invention constructs a dual-chain collaborative power data trading system comprised of a consortium blockchain (Data Chain, DC), a public blockchain (Payment Chain, PC), a Trusted Execution Environment (TEE) oracle network, and a data storage layer. Structurally, the consortium blockchain deploys a Data Transaction Request Contract (DTRC), a Task Scheduling Contract (OTDC), and a Result Certificate Update Contract (RPUC), responsible for recording data requests, scheduling off-chain analysis tasks, and registering final delivery certificates, respectively. The public blockchain receives payment transactions from data buyers and records payment signature results. The TEE oracle network handles off-chain data analysis, result aggregation, and cross-chain adapter signature calculations. The data storage layer stores encrypted power data, analysis results, and related contextual information. All modules establish connections through encrypted communication channels and on-chain calls, forming a clearly structured and well-defined multi-chain collaborative framework.

[0049] The system's software execution flow is as follows: The data buyer submits a data request to the DTRC, which distributes the task to the oracle network. The oracle performs data analysis within the TEE and generates a result hash. Simultaneously, it generates a random key and constructs an adapter pre-signature for the data delivery transaction based on this key. The pre-signature, public key, and encrypted data are then returned to the data buyer. The data buyer constructs a payment pre-signature on the public blockchain and sends it to the oracle. The oracle uses the random key to complete the payment pre-signature into a full payment signature and submits it to the public blockchain for confirmation. The data buyer recovers the random key from the payment signature, decrypts the data, and constructs the final data delivery signature based on this key. The buyer then submits this signature and data delivery certificate to the RPUC. This technical solution achieves clear collaboration between modules and ensures consistency between data flow, signature flow, and value flow in a cross-chain state.

[0050] like Figure 1 As shown, the system of the present invention consists of a data chain DC, a payment chain PC, a trusted execution environment oracle network TON, a data hosting cloud PDHC, a data seller PDS, and a data buyer PDB. The data chain is used to manage data requests, task scheduling, and result credentials; the payment chain is used for value settlement; the oracle network provides off-chain trusted computing capabilities; and the data hosting cloud is used for hosting encrypted data and encrypted programs.

[0051] Based on this, the present invention provides a cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading, combined with Figure 2 and Figure 3 This may include the following steps:

[0052] Step 1: For nodes in the trusted execution environment oracle network participating in power data transactions, construct the corresponding task data packets for the nodes in the power data hosting cloud;

[0053] All participants in the power data transaction register their identities. These participants include data buyers, data sellers, and all nodes in the trusted execution environment oracle network. All participants must complete identity registration based on public key infrastructure within the blockchain network to obtain a set of participating entities. ,in, For the data buyer entity, The set of data sellers participating in the transaction, and the set of trusted execution environment oracle network nodes, are represented as: Participant registration identification and public key ;

[0054] The data trading platform pre-deploys three types of core smart contracts in the data trading module: the Data Transaction Request Contract (DTRC), used for registration. Parameters and generate task identifiers The Oracle Task Scheduling Contract (OTDC) maintains a list of available oracle nodes and is responsible for executing a random scheduling algorithm to select the execution set from all nodes in the network. The Result Certificate On-Chain Contract (RPUC) records the signature certificate and determines whether it meets the requirements. Strategy. Where x is the total number of nodes participating in this task (Total), and y is the threshold required to reach consensus (Threshold), the decision condition becomes: (Actual significant number) .

[0055] To protect the privacy and integrity of off-chain data analysis, the platform employs a two-layer encryption scheme. Data sellers use data keys. Power data Encryption is performed to obtain ciphertext data. The power data includes, but is not limited to, historical load curves, user electricity consumption behavior characteristics, and voltage and current time-series data; based on the public key of each node in the trusted execution environment oracle network, the data key is... The data is encapsulated to obtain data node encapsulation, and the data seller then transmits the encrypted data. All data nodes are encapsulated and uploaded to the power data hosting cloud.

[0056] Data buyer uses program key For the preset analysis program Encryption is performed to obtain the program ciphertext. Based on the public key of each node in the trusted execution environment oracle network, the program key is... The process involves encapsulation to obtain program node encapsulation, and the data buyer then transmits the encrypted program data. All program nodes are encapsulated and uploaded to the power data hosting cloud.

[0057] In the power data hosting cloud, each node in the trusted execution environment oracle network corresponds to a task data packet, which includes encrypted data. ciphertext and node encapsulation The node encapsulation This includes data node encapsulation and program node encapsulation.

[0058] Step 2: Based on the power data transaction request constructed by the data buyer, determine the master node among all nodes in the trusted execution environment oracle network, select y nodes as execution nodes, and obtain the execution node set;

[0059] Among them, power data transaction requests ,in, For the entity that buys the data, The set of entities that are data sellers participating in the transaction. For the cross-day time range of power data transaction requests, For the intraday time range of power data transaction requests, Indicates the region to which the power data belongs. This indicates the data type of the power data transaction request. This indicates the number of tokens the data buyer needs to pay on the payment chain. The PDT represents the trusted computing parameters required to execute the task. AGG is the address of the master node responsible for result aggregation in the trusted execution environment oracle network. The above PDT constitutes the unified input format for data requests in this invention, and also provides complete parameter basis for the DTRC contract to generate task number TID and the subsequent scheduling process.

[0060] Based on this, the master node is determined according to the AGG in the power data transaction request. During the task request and scheduling phase, the data buyer submits the PDT to the data transaction request contract DTRC. DTRC receives the PDT and uses a hash algorithm to generate the task identifier TID of the PDT. DTRC triggers a cross-contract call or throws an on-chain event for the oracle task scheduling contract OTDC to capture. OTDC selects y nodes as execution nodes from all nodes in the trusted execution environment oracle network and obtains the execution node set. ;

[0061] Step 3: Based on the power data transaction request, construct a task structure that includes the specified master node and broadcast the task structure to each execution node;

[0062] Build task structure , where T includes and The internal task allocation function is called to broadcast the task structure to each execution node.

[0063] Step 4: In the off-chain power data analysis and execution phase, the execution node obtains its corresponding task data package from the power data hosting cloud. The master node and the execution node analyze and process the task data package to obtain the aggregation result. ;

[0064] Step 4.1: Each execution node obtains its corresponding task data packet from the power data hosting cloud, processes the task data packet, obtains a node report, and sends it to the master node;

[0065] After the task request and scheduling phase is completed, the system enters the off-chain power data analysis and execution phase. In this phase, to prevent data leakage in memory after key decryption, the platform deploys a Trusted Execution Environment (TEE) (Intel SGX) in each oracle node to support the confidentiality and verifiability of off-chain computation. Taking Intel SGX as an example, this architecture constructs an isolated secure enclave within the processor, providing complete protection for code and data, preventing external systems (including operating systems and hypervisors) from interfering with the execution behavior within the enclave. This mechanism collaboratively ensures privacy, security, and access boundary control at each stage of data extraction, transmission, and analysis.

[0066] For each execution node, during the startup phase, the node automatically loads the Enclave module (secure enclave module) supported by Intel SGX, creating an Enclave region protected by hardware isolation. Since the memory of the Enclave region under the SGX architecture cannot be directly accessed from the outside, the execution node obtains the task data packet corresponding to the execution node from the power data hosting cloud through the predefined ECALL secure call interface function, and passes it to the secure enclave module of the execution node to complete the cross-boundary call;

[0067] In the secure enclave module, the private key of the execution node is used. Encapsulation of nodes Decrypt to obtain the data key. and program key Using data keys and program key , respectively for the encrypted data and program ciphertext Perform the decryption operation to obtain the power data. With analysis program ;

[0068] Execution node running analysis program For power data Analysis was conducted, and the results were obtained. Dimensional index vector, i.e., analysis results ,in, This represents the computation result of execution node i in the m-th analysis dimension, where m represents the dimension of the analysis result. To verify the authenticity of the result, the execution node uses a hash algorithm to calculate a summary of the analysis result. Based on the private key of the execution node Generate summary signature Analysis results ,summary and signature The result data packet is composed of data in the Enclave area that cannot be directly accessed from the outside. The execution node exports the result data packet from the secure enclave module through the OCALL security interface or a secure return value mechanism, and then encapsulates the result data packet in a structured manner through a trusted channel to obtain the node report. The node report is sent to the master node;

[0069] Step 4.2: To improve the execution efficiency and response consistency of the oracle network with multiple nodes, the platform adopts a star topology, with the master oracle node acting as the central node for unified coordination. Specifically, the master node receives node reports, generates a target request based on the task structure and the node reports, and submits it to the result credential on-chain contract RPUC. The target request includes a task identifier (TID) and an aggregation result. and voucher list ;

[0070] The master node receives node reports and uses the public key of the execution node corresponding to the node report to verify the signature in the node report. If the verification passes, the signature in the node report is considered valid; if the verification fails, the signature in the node report is considered invalid. Once the number of received node reports containing valid signatures exceeds a preset number α, the analysis results are extracted from all node reports containing valid signatures to construct... The resulting matrix is ​​represented as follows:

[0071] ;

[0072] The aggregated result is obtained by aggregating the result matrix using aggregation functions. ,in It is an analytical aggregation operator that operates on a set of structured vectors, reporting the corresponding node entities for all nodes containing valid signatures. ,summary and signature Package and obtain a list of vouchers. , call The function combines the task identifier (TID) and the aggregation result. and voucher list The target request is submitted to the result certificate on-chain contract RPUC;

[0073] Step 4.3: The RPUC contract receives the target request, processes and verifies it, and stores the aggregation result when the verification is successful. And trigger on-chain events ;

[0074] After receiving the target request, the RPUC on-chain contract immediately initiates the final on-chain verification process. Specifically, it determines whether all node entities in the target request belong to the execution node set to ensure the legitimacy of the data source. If any node entity in the target request does not belong to the execution node set, the target is discarded. If all node entities in the target request belong to the execution node set, a signature verification function is used. The system verifies the public key, digest, and signature corresponding to each execution node in the target request, obtaining the verification result. If the verification result indicates that the verification fails, the node entity, digest, and signature of that execution node are deleted from the credential list, resulting in a filtered credential list. This ensures that subsequent statistics are based only on genuine and valid credentials. If the number of execution nodes in the filtered credential list is less than a preset threshold, the transaction is terminated. If the number of execution nodes in the filtered credential list is greater than or equal to the preset threshold, it indicates that the RPUC verification has passed, and the aggregation result is stored. And trigger on-chain events This serves as the on-chain confirmation mark that the task has met the delivery conditions;

[0075] Step 5: In the payment and results delivery phase, the data buyer receives the aggregated results. The settlement interface of the RPUC contract on the consortium blockchain is invoked to confirm with the consortium blockchain that the aggregation result has been successfully received. ;

[0076] After the off-chain computation task passes the RPUC contract verification and triggers the ResultVerified event, the system enters the atomic delivery phase dominated by the Adapter Signature protocol. The master node generates a one-time random secret value within the Trusted Execution Environment (TEE). (in, (where r is the scalar domain of the elliptic curve group), compute the public commitment to the random secret value r. Where G represents the elliptic curve generator, and the master node uses a random secret value r as the symmetric encryption key to perform aggregation on the result. Perform encryption operations to generate aggregated ciphertext. , will aggregate ciphertext And publicly committed R to be sent to the data buyer via a secure channel;

[0077] The data buyer receives the aggregated ciphertext The transaction is terminated if the publicly committed commitment R is not a valid point on the elliptic curve; otherwise, a payment transaction pointing to the master node address is constructed. The payment transaction includes the token amount to be paid. To ensure an atomic binding between payment and data delivery, the buyer does not directly sign the transaction, but instead constructs a payment pre-signature based on the adapter signature algorithm. The pre-signature The mathematical structure implicitly contains the commitment. While it is not a valid signature recognized by the public chain consensus protocol, it possesses specific algebraic homomorphic properties, meaning it only works when combined with the secret value. Only then can it be converted into a complete and valid signature. .

[0078] The data buyer will pay for the pre-signed data. and Send to the master node, the master node receives the payment pre-signature. and In order to obtain the transaction The funds in the payment, combined with a random secret value r, will be pre-signed for payment. Convert to a valid signature Specifically, by utilizing its private secret value Perform adaptation and completion operations on the pre-signature to calculate the complete signature that conforms to the public chain verification rules. .

[0079] Will have a valid signature payment transactions Broadcast to the payment chain, in the payment transaction Valid signature after confirmation by the payment chain Publicly available;

[0080] In the final stage of the agreement, the data buyer obtains a valid signature. And calculate the valid signature. and payment pre-signature The difference between them is used to calculate the random secret value. The data buyer aggregates ciphertext using random secret values. Perform the decryption operation to obtain the aggregated result. ,

[0081] The data buyer calls the settlement interface of the RPUC contract on the consortium blockchain to confirm to the consortium blockchain that it has successfully received the aggregation result. This enables fair exchange of cross-chain data and value without the need for a trusted third party.

[0082] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading, characterized in that: include: For nodes in the trusted execution environment oracle network participating in power data transactions, construct the corresponding task data packets for the nodes in the power data hosting cloud; Based on the power data transaction request constructed by the data buyer, determine the master node among all nodes in the trusted execution environment oracle network, select y nodes as execution nodes, and obtain the execution node set; Based on power data transaction requests, a task structure containing a specified master node is constructed and the task structure is broadcast to each execution node; The execution node retrieves its corresponding task data package from the power data hosting cloud. The master node and the execution node analyze and process the task data package to obtain the aggregation result. ; Data buyers obtain aggregated results The settlement interface of the RPUC contract on the consortium blockchain is invoked to confirm that the aggregation result has been successfully received. .

2. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 1, characterized in that, The task data packet corresponding to the construction node includes: All participants in the power data transaction register their identities to obtain a set of participating entities, and each participant registers its identity identifier. and public key The participants include data buyers, data sellers, and all nodes in the trusted execution environment oracle network; Data sellers use data keys Power data Encryption is performed to obtain ciphertext data. Based on the public key of each node in the trusted execution environment oracle network, the data key is... The data is encapsulated to obtain data node encapsulation, and the data seller then transmits the encrypted data. All data nodes are encapsulated and uploaded to the power data hosting cloud; Data buyer uses program key For the preset analysis program Encryption is performed to obtain the program ciphertext. Based on the public key of each node in the trusted execution environment oracle network, the program key is... The process involves encapsulation to obtain program node encapsulation, and the data buyer then transmits the encrypted program data. All program nodes are packaged and uploaded to the power data hosting cloud; In the power data hosting cloud, each node in the trusted execution environment oracle network corresponds to a task data packet, which includes encrypted data. ciphertext and node encapsulation The node encapsulation This includes data node encapsulation and program node encapsulation.

3. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 1, characterized in that, The power data transaction request is represented as follows: ; in, For the entity that buys the data, The set of entities that are data sellers participating in the transaction. For the cross-day time range of power data transaction requests, For the intraday time range of power data transaction requests, Indicates the region to which the power data belongs. This indicates the data type of the power data transaction request. This indicates the number of tokens the data buyer needs to pay on the payment chain. This represents the trusted computation parameters required to execute the task. AGG is the address of the master node responsible for result aggregation in the trusted execution environment oracle network.

4. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data transactions according to claim 3, characterized in that, The method for determining the master node is as follows: The master node is determined based on AGG in the power data transaction request.

5. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 3, characterized in that, Select y nodes as execution nodes and obtain the set of execution nodes, including: The data buyer submits the Power Data Transaction Request (PDT) to the Data Transaction Request Contract (DTRC). DTRC receives the PDT and uses a hash algorithm to generate the PDT's Task Identifier (TID). DTRC triggers a cross-contract call or throws an on-chain event for the Oracle Task Scheduling Contract (OTDC) to capture. OTDC selects y nodes from all nodes in the Trusted Execution Environment Oracle Network as execution nodes and obtains the execution node set.

6. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 5, characterized in that, The execution node retrieves its corresponding task data package from the power data hosting cloud. The master node and the execution node analyze and process the task data package to obtain the aggregation result. ,include: Each execution node obtains its corresponding task data package in the power data hosting cloud, processes the task data package, obtains a node report, and sends it to the master node. The master node receives node reports, generates a target request based on the task structure and the node reports, and submits it to the result credential on-chain contract RPUC; the target request includes a task identifier (TID) and an aggregation result. and voucher list ; The RPUC contract, which records the result credential on-chain, receives the target request, processes and verifies it, and stores the aggregation result upon successful verification. And trigger on-chain events.

7. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 1, characterized in that, Each execution node retrieves its corresponding task data packet from the power data hosting cloud, processes the task data packet, generates a node report, and sends it to the master node, including: For each execution node, the execution node obtains the corresponding task data packet from the power data hosting cloud through the predefined ECALL secure call interface function, and passes it to the execution node's secure enclave module; In the secure enclave module, the private key of the execution node is used. Encapsulation of nodes Decrypt to obtain the data key. and program key Using data keys and program key , respectively for the encrypted data and program ciphertext Perform the decryption operation to obtain the power data. With analysis program ; Execution node running analysis program For power data The analysis was performed, and the results were obtained. The execution node uses a hash algorithm to calculate a summary of the analysis results. Based on the private key of the execution node Generate summary signature Analysis results ,summary and signature The result data packet is composed of the execution node, which exports the result data packet from the secure enclave module through the OCALL security interface or the security return value mechanism, and encapsulates the result data packet in a structured manner through the trusted channel to obtain the node report, and sends the node report to the master node.

8. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 6, characterized in that, The master node receives node reports, generates target requests based on the task structure and node reports, and submits them to the result credential on-chain contract RPUC, including: The master node receives node reports and uses the public key of the execution node corresponding to the node report to verify the signature in the node report. When the verification is successful, it indicates that the signature of the node report is a valid signature. When the verification fails, it indicates that the signature of the node report is an invalid signature. After the number of node reports containing valid signatures received is greater than a preset number α, the analysis results are extracted from all node reports containing valid signatures to construct a result matrix. The aggregated result is obtained by aggregating the result matrix using aggregation functions. Report the corresponding node entity of all nodes containing valid signatures. ,summary and signature Package and obtain a list of vouchers. , call The function combines the task identifier (TID) and the aggregation result. and voucher list The target request is submitted to the result certificate on-chain contract RPUC.

9. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 6, characterized in that, The RPUC contract, which records the result credential on-chain, receives the target request, processes and verifies it, and stores the aggregation result upon successful verification. And trigger on-chain events, including: The resulting credential on-chain contract RPUC receives the target request and determines whether all node entities in the target request belong to the execution node set. If any node entity in the target request does not belong to the execution node set, the target is discarded. If all node entities in the target request belong to the execution node set, a signature verification function is used to verify the public key, digest, and signature corresponding to each execution node in the target request, obtaining a verification result. If the verification result indicates that the verification fails, the node entity, digest, and signature of that execution node are deleted from the credential list, resulting in a filtered credential list. If the number of execution nodes in the filtered credential list is less than a preset threshold, the transaction is terminated. If the number of execution nodes in the filtered credential list is greater than or equal to the preset threshold, it indicates that the RPUC verification is successful, and the aggregation result is stored. And trigger on-chain events.

10. The cross-chain atomic interaction method for a multi-chain collaboration platform for power data trading according to claim 1, characterized in that, Data buyers obtain aggregated results ,include: The master node generates a random secret value r within the Trusted Execution Environment (TEE) and calculates the public commitment to the random secret value r. Where G represents the elliptic curve generator, and the master node uses a random secret value r as the symmetric encryption key to perform aggregation on the result. Perform encryption operations to generate aggregated ciphertext. , will aggregate ciphertext And publicly commit R to send to the data buyer; The data buyer receives the aggregated ciphertext The transaction is terminated if the publicly committed commitment R is not a valid point on the elliptic curve; otherwise, a payment transaction pointing to the master node address is constructed. The payment transaction includes the token amount to be paid. A payment pre-signature is constructed based on the adapter signature algorithm. The data buyer will pay for pre-signed data. and Send to the master node, the master node receives the payment pre-signature. and And combined with a random secret value r, the payment pre-signature Convert to a valid signature , Will have a valid signature payment transactions Broadcast to the payment chain, in the payment transaction Valid signature after confirmation by the payment chain Publicly visible; Data buyer obtains valid signature And calculate the valid signature. and payment pre-signature The difference between them is used to calculate the random secret value. The data buyer aggregates ciphertext using random secret values. Perform the decryption operation to obtain the aggregated result. .

Images