Carbon transaction privacy protection method based on cross-chain data fusion

Abstract

The invention discloses a carbon transaction privacy protection method based on cross-chain data fusion, and the method comprises the steps: obtaining a plurality of transaction data from a plurality of application chains through a block chain interaction interface according to a transaction hash value, and transmitting the transaction data to a transaction analysis interface; the transaction analysis interface analyzes the obtained transaction data based on the intelligent contract method organization and the mapping table to obtain entity data and entity classification data; the data fusion unit fuses the application data in the entity data to obtain fused data, generates a transaction verification hash which can be used for verifying the fused data, and finally uploads the fused data and the transaction verification hash to a cross-chain network; and the cross-chain network uplinks the fused data and the transaction verification hash to an application chain. According to the method, algorithms in the aspects of transaction analysis, entity analysis, data fusion and the like are designed and put forward for the problem of transaction data dispersion among different block chains at present, and the problems of transaction fusion of different block chains and chaining of fused data are solved.

Description

Technical Field

[0001] The present invention belongs to the technical field of electronic communication security, and in particular relates to a secure, efficient and lightweight certificateless signature scheme for an ADS-B system. Background Art

[0002] Carbon trading is a general term for greenhouse gas emission rights trading. Carbon trading-based buying and selling can realize a complete mechanism to manage carbon emissions. Enterprises and institutions conduct reasonable carbon trading under the carbon trading mechanism, so that carbon emissions are reasonably distributed, and ultimately the overall carbon emissions of society can be reduced. At the same time, carbon trading also focuses on the supervision, incentives, and penalties of enterprises and institutions in terms of carbon emissions, and through these measures, regulates the carbon emissions and trading behaviors of enterprises and institutions.

[0003] Blockchain is a distributed shared ledger system with features such as immutability, distributed storage, and decentralization. The features of blockchain are well suited to the needs of carbon trading. The decentralization of blockchain makes carbon trading independent of a single central management agency. The immutability of blockchain makes every carbon transaction recorded in the blockchain ledger, and historical carbon transactions can be traced at any time. At the same time, according to the application of smart contracts, blockchain platforms can use smart contracts to automatically execute the terms and conditions of carbon trading, reducing the cost of manual intervention.

[0004] However, due to the emergence of multiple blockchain projects such as Ethereum, Hyperledger Ledger, Fisco Bcos, etc. in the process of blockchain development, different carbon trading organizations may use different blockchain projects as their underlying blockchains. In addition, due to differences in smart contracts and data structure designs in the process of carbon trading deployment, it is difficult for existing carbon trading blockchains to achieve data interoperability, which increases the user's tracing costs for carbon transactions on different blockchains. Summary of the invention

[0005] In view of this, the present invention proposes a carbon trading privacy protection method based on cross-chain data fusion. Aiming at the current problem of scattered transaction data among different blockchains, algorithms for transaction parsing, entity parsing, data fusion, etc. are designed and proposed. This solves the problem of fusion of transactions of different blockchains and uploading of fused data to the chain, and protects the privacy of transaction data.

[0006] In order to achieve the above object, the present invention provides the following technical solutions:

[0007] The present invention provides a carbon trading privacy protection method based on cross-chain data fusion, comprising:

[0008] Obtain some transaction data from multiple application chains AC according to the transaction hash value through the blockchain interaction interface CII, and send it to the transaction analysis interface TAI;

[0009] The transaction analysis interface TAI analyzes the acquired transaction data based on the smart contract method organization CMO and the mapping table MT obtained from the fusion management unit FMU to obtain entity data SD and entity classification data EC;

[0010] After receiving the entity data SD, mapping table MT and entity classification data EC sent by the transaction analysis interface TAI, the data fusion unit DFU fuses the application data AD in the entity data SD to obtain the fused data FD, and generates a transaction verification hash FVH that can be used to verify the fused data FD, and finally uploads the fused data FD and the transaction verification hash FVH to the cross-chain network;

[0011] The cross-chain network uploads the fusion data FD and the transaction verification hash FVH to the fusion transaction information FTX of the application chain AC.

[0012] Preferably, the smart contract method organization CMO includes multiple smart contract method groups;

[0013] A smart contract method group is a collection of multiple smart contract methods CM of the same type in reality. There are multiple smart contract method groups according to the number of types.

[0014] Among them, the smart contract method CM is the hash value of a method of any smart contract, which is obtained by hashing the total string formed by concatenating the smart contract address and the relevant method string.

[0015] Preferably, the transaction analysis interface TAI performs the following steps in the process of analyzing the acquired transaction data:

[0016] Analyze the transaction data of different application chains AC respectively, and for the i-th transaction data Tx i Parse and generate the corresponding smart contract method CM i and application data AD i The two-tuple of:

[0017] Tx i →(CM i ,AD i )

[0018] The binary groups corresponding to multiple transaction data are stored together to form an entity data SD, forming a vector of tx_num dimension. The value of tx_num is the total number of transactions involved in this fusion:

[0019]

[0020] Determine the CM of each smart contract method iWhether they belong to the same smart contract method group CMO j The following formula must be satisfied:

[0021]

[0022] If it does not meet the requirements, it is determined that the fusion condition is not met and the fusion is not selected;

[0023] If satisfied, then determine the application data AD i Key-value pairs The key in ApplicationKey;

[0024] Determine for and Does it satisfy the following formula:

[0025]

[0026] Among them, MT(CM i , ApplicationKey indicates that CM i The mapping relationship between the value and its corresponding key ApplicationKey consisting of a two-tuple to FusionKey, MT (CM j , ApplicationKey) indicates that CM j The mapping relationship between the value and its corresponding key ApplicationKey and FusionKey;

[0027] When the conditions are met, they are determined to be the same entity; when the conditions are not met, they are determined to be different entities, and entity classification data EC is obtained.

[0028] Preferably, the data fusion unit DFU performs data fusion on the same entity in the entity data SD and the entity classification data EC by using a HEF algorithm, wherein the HEF algorithm process specifically includes:

[0029] For multiple identical entities, the application data AD corresponding to each entity data SD is weighted and then sorted from large to small according to the weight;

[0030] For the i-th application data AD i Key-value pairs The key ApplicationKey in the CM field determines its corresponding smart contract method CM i The corresponding key value mapping relationship:

[0031] (CM i ,ApplicationKey)→FusionKey

[0032] Among them, FusionKey represents the fusion data FD generated after fusion FusionKey Keys;

[0033] The i-th application data AD i Mapping from application data AD to the corresponding position of fusion data FD:

[0034]

[0035] Complete data fusion for the same entity.

[0036] Preferably, the data fusion unit DFU performs data fusion on different entities in the entity data SD and the entity classification data EC through a DEF algorithm, wherein the DEF algorithm process specifically includes:

[0037] According to each entity classification data EC, its corresponding application data AD is determined and fused through HEF algorithm;

[0038] Traverse the FusionKey in the fused data and follow the fusion function OP defined by FMU in turn FusionKey Calculate the FusionKey and store it in FD in sequence FusionKey , thereby completing the data fusion of different entities.

[0039] Preferably, the steps of generating the transaction verification hash FVH include:

[0040] For the merged transaction data, first obtain the keys corresponding to multiple application chains AC from the local fusion server LFS;

[0041] Hash multiple keys and concatenate the results and hash them again:

[0042]

[0043] Among them, FK represents the first operation result, ACN represents the total number of application chains AC involved in the fusion, SK' i Represents the key of the i-th application chain AC;

[0044] Perform hash operation on the fused transaction data distribution, and connect the operation results to the fused data FD:

[0045]

[0046] Wherein, TCM represents the second operation result;

[0047] The transaction verification hash FVH is calculated by the HMAC algorithm:

[0048]

[0049] The present invention has achieved at least the following beneficial effects:

[0050] 1. Propose a multi-chain data fusion solution, use the local fusion server to obtain and parse multi-chain carbon trading data, and eliminate the data structure differences when processing carbon trading data from different blockchains.

[0051] 2. In response to the problems of data duplication and inconsistency in different carbon trading-related blockchains, the solution designs a transaction data fusion algorithm TDF. The TDF algorithm classifies carbon trading entities through the transaction entity resolution algorithm TER, and realizes the fusion of carbon trading data through the same entity transaction fusion (HEF) algorithm and the different entity transaction fusion (DEF) algorithm.

[0052] 3. In the data fusion stage, the scheme uses the HMAC algorithm, obtains the FD-based message authentication code through the blockchain key managed by LFS, and designs a message authentication code verification method to ensure the credibility of the fused data.

[0053] 4. In the stage of fusion data on-chain, the solution uses cross-chain technology to ensure the atomicity of fusion data on-chain.

[0054] Other advantages, objectives and features of the present invention will be described in the following description and will be apparent to those skilled in the art to some extent, or those skilled in the art may be taught from the practice of the present invention. The objectives and other advantages of the present invention may be realized and obtained through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to make the purpose, technical solution and beneficial effects of the present invention clearer, the present invention provides the following drawings for illustration:

[0056] Figure 1 This is a general process framework diagram of a carbon trading privacy protection method based on cross-chain data fusion in an embodiment of the present invention;

[0057] Figure 2 It is a pseudo code schematic diagram of a transaction entity parsing algorithm in an embodiment of the present invention;

[0058] Figure 3 A pseudo code diagram of the HEF algorithm designed for transaction fusion of the same entity in an embodiment of the present invention;

[0059] Figure 4 A pseudo code diagram of a DEF algorithm designed for transaction integration of different entities in an embodiment of the present invention;

[0060] Figure 5 A flowchart of the specific steps of generating FVH in an embodiment of the present invention;

[0061] Figure 6 4 is a process diagram of FVH verification in an embodiment of the present invention. DETAILED DESCRIPTION

[0062] The preferred embodiments of the present invention are described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0063] The carbon trading privacy protection method based on cross-chain data fusion provided by the present invention proposes a multi-chain data fusion scheme (MCDFS) to address the current problem of scattered transaction data between different blockchains. The scheme design proposes algorithms for transaction parsing, entity parsing, data fusion, etc., which solves the problem of fusion of transactions from different blockchains and uploading fusion data to the chain. Figure 1 ,include:

[0064] Application Chain (AC): The blockchain where the application is located in the actual process. The transactions in AC are the objects of MCDFS fusion.

[0065] Local Fusion Server (LFS): The main implementation unit of MCDFS, which is mainly responsible for acquiring blockchain transaction data, parsing blockchain transaction data, fusing blockchain transaction data, generating fusion data hash values, etc. It consists of CII, TAI, DFU, and FMU.

[0066] Blockchain Interaction Interface (CII): Establishes a connection with each blockchain. Its main tasks include obtaining transactions through transaction hashes and transmitting transaction information to TAI.

[0067] Smart Contract Method Organization (CMO): CMs pointing to the same type of time in reality are divided into an organization. CMO maintains the organization information. The storage result of CMO is shown in Formula 1. There are multiple CMOs, and each CMO consists of several CMs.

[0068]

[0069] Smart Contract Method (CM): CM is the hash value of a method of a smart contract, as shown in Formula 2, which is obtained by hashing the total string formed by concatenating the smart contract address with the relevant method string.

[0070] CM=H(contract n ame+method s tring)#(2)

[0071] Application Data (AD): AD is a string of key-value pairs, including basic data such as the transaction initiator account, gas fee, timestamp, and smart contract call parameters. It is also the data to be integrated by parsing the transaction.

[0072] Entity Data (SD): SD contains AD and CM data generated by the analysis of each transaction.

[0073] Fusion data (FD): FD, like AD, is also a string of key-value pairs, which is the fusion result data generated after multiple ADs are fused.

[0074] Transaction Verification Hash (FVH): The hash value generated by hashing the transaction using the key owned by LFS can be used to verify whether the FD on the chain is credible.

[0075] Fusion Transaction (FTX): A transaction that stores fused data back on the chain after data fusion.

[0076] Entity Classification (EC): EC is the process data generated during the parsing process. It is classified according to whether the transaction points to the same entity in reality. EC consists of multiple sets, each of which is a set of transactions pointing to the same real entity. The structure of EC is expressed by formula 3. Each EC consists of several transactions.

[0077]

[0078] Transaction Analysis Interface (TAI): Obtains transaction information from CII. TAI is mainly responsible for the analysis of transaction information, including transaction CM analysis, same CMO determination, and the generation of corresponding EC and application data AD.

[0079] Mapping table (MT): managed by FMU, stores the mapping information from AD field to FD field.

[0080] Smart Contract Method Organization (CMO): CMs pointing to the same type of time in reality are divided into one organization, and CMO maintains the organization information.

[0081] Fusion Management Unit (FMU): FMU mainly includes two tasks. The first is to manage the classification of CMs into different CM organizations (CMOs). The second is to manage the mapping relationship between the fields in each CM and the FD fields, which are stored as a mapping table (MT).

[0082] Data Fusion Unit (DFU): obtains CM from TAI, and CMO and MT from FMU, performs transaction data fusion, FD hash value generation and other steps, and can call the SDK interface provided by the cross-chain network to upload fusion information.

[0083] In the specific implementation, the architecture of LFS is mainly composed of three layers, including blockchain interaction layer (CIL), transaction analysis layer (TAL), and data fusion layer (DFL). The specific implementation of the three-layer architecture is achieved by introducing CII in CIL, TAI in TAL, and DFU in DFL;

[0084] The blockchain interaction layer CIL connects AC and TAL, obtains AC transactions and passes them to TAL or initiates transactions to AC. Since AC is a different type of blockchain in the production environment, LFS needs to interact with AC through the blockchain interaction interface (CII) in CIL. According to different blockchains, it can be divided into FISCO BCOS2 CII, Hyperledge fabric CII, etc.

[0085] The transaction analysis layer TAL connects CIL and DFL. It is a necessary processing layer before data fusion. It is mainly used to parse transactions of different ACs to form a standardized data to be fused, including smart contract methods (CM) and application data (AD). The analysis of the transaction is shown in Formula 4. i Parse and generate CM i and AD i At the same time, the data will be parsed to determine whether the CM is in the same CMO and generate the EC value.

[0086] Tx i →(CM i ,AD i )#(4)

[0087] For TAL entity resolution, the solution proposes a transaction entity resolution (TER) algorithm. The TER algorithm is used to determine whether a transaction is in the same CMO and to generate EC. The specific algorithm will be introduced in Chapter 4.

[0088] The transaction data is integrated in the data fusion layer DFL, and the data to be integrated is obtained from TAL. The DFU is mainly used to integrate AD and generate hash values.

[0089] DFU mainly fuses data. It selects the subsequent fusion method based on the entity analysis results, including the same CMO different entities, the same CMO same entities, and different CMOs. It uses the DEF algorithm, HEF algorithm, and no fusion algorithms and processing methods respectively. The specific fusion algorithm will be introduced in Chapter 4.

[0090] At the same time, DFU needs to generate FVH. The generation of FVH is based on FD, source transaction hash TxA and the key managed by LFS. FVH is uploaded to AC's FTX along with FD, source transaction and other information to provide the verifiability of FTX.

[0091] In a specific implementation process, MCDFS is divided into four major steps: transaction acquisition, transaction analysis, transaction fusion, and data upload, which can be further divided into eight small steps:

[0092] 1. Retrieve transactions: CII retrieves several transactions from multiple ACs based on the transaction hash values.

[0093] 2. Send transaction: CII forwards the transaction obtained in step 1 to TAI.

[0094] 3. Send (CMO, MT): FMU sends the CMO and MT managed by itself to TAI.

[0095] 4. Entity analysis: TAI parses AC’s transactions into SD, EC and other data, and performs entity analysis in the secondary process to determine the entity relationship of the transaction.

[0096] 5. Send (SD, MT, EC): TAI sends SD, MT, EC data to DFU.

[0097] 6. Fusion: DFU performs operations such as fusion and TVH generation on AD in SD to obtain data such as FD, TVH, contract address, and transaction address.

[0098] 7. Upload data: DFU uploads the fused data to the cross-chain network.

[0099] 8. Transaction upload: The cross-chain network generates transactions based on the uploaded fusion data and uploads them to the AC chain.

[0100] In a specific embodiment, the solution design proposes a transaction data fusion algorithm (TDF), which mainly includes three parts: entity resolution, data fusion, and FVH generation and verification. It proposes a transaction entity resolution (TER) algorithm, a same entity transaction fusion (HEF) algorithm, a different entity transaction fusion (DEF) algorithm, and a FVH generation and verification scheme.

[0101] In a specific embodiment, entity resolution is the first step of TDF and is performed in DFL.

[0102] definition:

[0103] 1. List of smart contract methods for data to be integrated (CM i ), i represents different transactions in a fusion, as shown in Formula 5. The CM and AD corresponding to each transaction form a tuple and are stored in SD. SD forms a vector of tx_num dimension, and the value of tx_num is the number of transactions in this fusion.

[0104]

[0105] 2. Smart Contract Method Organization (CMO j ), each CMO j Store several CMs for different sets i .

[0106] 3. Key-value pairs of data to be fused i represents different transaction coordinates in a fusion, and ApplicationKey represents the key in the key-value pair.

[0107] 4. Fusion Data FD FusionKey , the data generated after fusion, FusionKey represents the key of the fusion data.

[0108] 5. Mapping relationship Indicates that a CM i The corresponding mapping relationship of key value to is expressed by formula 6.

[0109] (CM i ,ApplicationKey)→FusionKey#(6)

[0110] The mapping relationship is a mapping relationship between a CM value and ApplicationKey and a FusionKey, which is defined as the function MT(CM, ApplicationKey) = FusionKey. j There is a FusionKey in the FD that is set to the AP position, which is equivalent to FD FusionKey The primary key in .

[0111] Entity resolution consists of two steps:

[0112] Step 1: Identify all CMs i Existing under the same CMO j In this case, formula 7 must be satisfied:

[0113]

[0114] When there is a mismatch, the fusion is interrupted and determined to be unsuitable for fusion.

[0115] Step 2: Determine the Satisfies formula 8:

[0116]

[0117] Depending on whether they meet the formula in step 2, they are divided into two categories: the same entity and different entities, and the two are merged according to different algorithms.

[0118] Design the Transaction Entity Resolution Algorithm (TER) as follows Figure 2 .

[0119] The TER algorithm mainly consists of three parts: transaction analysis, CMO determination, and EC generation.

[0120] The transaction analysis part analyzes the transaction: obtains FD, CM and other information from the transaction.

[0121] CMO judgment part: Based on the CM obtained from the transaction and the CMO obtained from the FMU, it is judged whether the transaction CMs all belong to the same CMO, that is, whether the transaction satisfies Formula 7. If so, it proves that the transactions point to the same type of events in reality and can be fused. Otherwise, they cannot be fused and the fusion event is interrupted.

[0122] EC generation part: Classify the entities that the transaction points to according to Formula 8.

[0123] In a specific embodiment, a HEF algorithm is proposed for the transaction fusion design of the same entity. The following is a description of the HEF algorithm.

[0124] definition:

[0125] Weight: Weight is an n-dimensional vector, where n is the number of transactions, satisfying Formula 9:

[0126] weight=(weight 1 ,weight 2 ,…,weight n )∈R n #(9)

[0127] CM: CM is an n-dimensional vector that satisfies Formula 10 and identifies the specific CM value of each transaction.

[0128] CM=(CM 1 ,CM 2 ,…,CM n )#(10)

[0129] Algorithm core:

[0130] The HEF algorithm mainly implements the process of mapping AD to FD. First, you need to obtain the corresponding FusionKey through formula 4-2, and use formula 11 to map the data from AD to the corresponding position of FD.

[0131]

[0132] An important issue that the HEF algorithm needs to solve is data conflict. AD i Mapped to FD, AD in HEFi They are the same entity and point to the same event. Therefore, when a conflict occurs in the mapping based on MT, Formula 12 is satisfied:

[0133]

[0134] At this time, it is mapped to the corresponding FD FusionKey There are multiple values ​​for , HEF uses weight comparison to solve it, that is, select the largest weight i , i is the transaction sequence index, the corresponding AD i Map to FD according to its ApplicationKey. If the mapping location is FD FusionKey If it is not empty, it proves that there is an AD with a higher priority i If this position is occupied, this mapping will no longer be performed.

[0135] The HEF algorithm deals with the data fusion of the same entity. The same entity should not have multiple values ​​for one FD field. Therefore, HEF assigns FD from large to small by comparing weights using AD weights as indicators. Through the HEF algorithm, multiple AD data can be fused to generate a new FD data. The pseudo code of the HEF algorithm is as follows: Figure 3 shown.

[0136] In a specific embodiment, a DEF algorithm is proposed for the transaction integration design of different entities. The pseudo code of the DEF algorithm is as follows: Figure 4 As shown:

[0137] The algorithm needs to be performed under the condition that the entity classification EC is obtained according to formula 12. EC will divide the CM in this fusion into multiple organizations according to whether they are the same entity. EC stores the transaction coordinate values ​​and unifies EC into an ECS set, as shown in formula 13.

[0138]

[0139] The DEF algorithm is mainly divided into two steps. The first step is to merge the AD in each EC into an entity data ED through the HEF algorithm. The second step is to traverse the FusionKey and calculate the OP in turn. FusionKey Calculate the FusionKey of FD. FusionKey is the fusion function defined by FMU, OP FusionKey It has high flexibility to cope with different application scenarios, among which the most common OP FusionKey For redundant storage, the data corresponding to the FusionKey in each ED is stored in FD in sequence. FusionKey .

[0140] In a specific embodiment, the FVH generation stage is performed in LFS. The FVH generation is performed using HMAC as the underlying algorithm. The HMAC algorithm is a password-related hash operation. The HMAC algorithm is used to generate a message authentication code for the fusion process, which ensures the credibility of the fusion data transaction. The HMAC algorithm integrates the key into the process of generating the hash value, so that the acquisition of the correct hash value requires the correct key to participate in the hash operation to improve the immutability of the message. The description of HMAC is shown in Formula 14:

[0141] HMAC(key,m)=H((key′⊕opad)+h((key′⊕ipad)+m))#(14)

[0142] Among them, key is the secret key, m is the message to be encrypted, key' is generated by padding key to 64 bytes, opad and ipad are internal padding and external padding respectively, opad is 0x36, ipad is 0x5c, HMAC calculates key' with opad and ipad respectively, performs hash operation with the value calculated with opad, concatenates the value calculated with ipad with the m string and performs hash operation, then concatenates the two values ​​and performs hash operation again to generate a fixed-length message authentication code, which can be used to protect the data integrity of the message.

[0143] The generation of FVH depends on data such as keys and transaction information. The specific steps of FVH generation are as follows: Figure 5 To express:

[0144] Taking the fusion of two transactions as an example, the TVH generation phase first needs to obtain transaction information Tx1, Tx2 and the secret key in LFS from the blockchain. LFS configures the corresponding key (SK) for each AC, and the key is stored in the key set SKset, which stores the SK for different ACs:

[0145] SKset=(SK 1 ,SK 2 ,SK 3 ,…)#(15)

[0146] For different transaction sources AC, LFS uses different SKs for HMAC algorithm. The first step is to extract the corresponding SKs according to the AC source, and define the extraction result as SK' i , where i is the subscript of the extracted SK.

[0147] LFS needs to SK' i Perform hash operations respectively and define ACN to represent the number of related ACs involved in the fusion:

[0148]

[0149] SK' i The results of the hash operations are connected and hashed again to obtain FK, which will be used as the key in the HMAC algorithm.

[0150] LFS also needs to perform hash operations on the transaction data separately, and concatenate the result strings of the hash elements and concatenate them with FD to obtain a string TCM:

[0151]

[0152] The TCM result is used as m of the HMAC algorithm. The following formula uses the HMAC algorithm to calculate FVH:

[0153]

[0154] FK and TCM are used as the key and m of the HMAC algorithm to calculate FVH. FVH is uploaded to the chain along with the fusion information and can be used to verify that the fusion transaction information on the chain comes from LFS, thus protecting the verifiability of the data source of the transaction.

[0155] The security of FHV verification comes from the irreversibility and anti-collision of HMAC. The irreversibility of HMAC allows LFS to quickly obtain FVH through FK and TCM, while attackers cannot obtain FK through FVH and TCM within the effective time. The anti-collision of HMAC prevents attackers from finding the string TCM' that makes formula 19 true.

[0156] FVH=HMAC(FK,TCM)=HMAC(FK,TCM′)#(19)

[0157] The process of FVH verification is as follows Figure 6 As shown, the main purpose is to verify the trusted source of the transaction FTX generated after the on-chain fusion.

[0158] Verification first requires obtaining FTX from the application chain, parsing FTX to obtain three types of data: FVH, FD, and transaction address. The source transaction information can be obtained from AC through the transaction address. LFS performs the FVH generation steps described in the previous section on the source transaction, FD, and FK to generate FVH for verifying FTX. Then, FVH is compared with FVH. If they are equal, it proves that FTX is credible, otherwise it is untrustworthy.

[0159] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made in form and details without departing from the scope defined by the claims of the present invention.

Claims

1. A carbon trading privacy protection method based on cross-chain data fusion, characterized in that: include: Obtain some transaction data from multiple application chains AC according to the transaction hash value through the blockchain interaction interface CII, and send it to the transaction analysis interface TAI; The transaction analysis interface TAI analyzes the acquired transaction data based on the smart contract method organization CMO and the mapping table MT obtained from the fusion management unit FMU to obtain entity data SD and entity classification data EC; After receiving the entity data SD, mapping table MT and entity classification data EC sent by the transaction analysis interface TAI, the data fusion unit DFU fuses the application data AD in the entity data SD to obtain the fused data FD, and generates a transaction verification hash FVH that can be used to verify the fused data FD, and finally uploads the fused data FD and the transaction verification hash FVH to the cross-chain network; The cross-chain network uploads the fusion data FD and the transaction verification hash FVH to the fusion transaction information FTX of the application chain AC.

2. According to claim 1, a carbon trading privacy protection method based on cross-chain data fusion is characterized in that: The smart contract method organization CMO includes multiple smart contract method groups; A smart contract method group is a collection of multiple smart contract methods CM of the same type in reality. There are multiple smart contract method groups according to the number of types. Among them, the smart contract method CM is the hash value of a method of any smart contract, which is obtained by hashing the total string formed by concatenating the smart contract address and the relevant method string.

3. According to a carbon trading privacy protection method based on cross-chain data fusion according to claim 1, it is characterized in that: The transaction analysis interface TAI performs the following steps in the process of analyzing the acquired transaction data: Analyze the transaction data of different application chains AC respectively, and for the i-th transaction data Tx i Parse and generate the corresponding smart contract method CM i and application data AD i The two-tuple of: Tx i →(CM i ,AD i ) The binary groups corresponding to multiple transaction data are stored together to form an entity data SD, forming a vector of tx_num dimension. The value of tx_num is the total number of transactions involved in this fusion: Determine the CM of each smart contract method i Belong to the same smart contract method group CMO j The following formula must be satisfied: If it does not meet the requirements, it is determined that the fusion condition is not met and the fusion is not selected; If satisfied, then determine the application data AD i Key-value pairs The key in ApplicationKey; Determine for and Does it satisfy the following formula: Among them, MT(CM i , ApplicationKey) indicates that CM i The mapping relationship between the value and its corresponding key ApplicationKey consisting of a two-tuple to FusionKey, MT (CM j , ApplicationKey) indicates that CM j The mapping relationship between the value and its corresponding key ApplicationKey and FusionKey; When the conditions are met, they are determined to be the same entity; when the conditions are not met, they are determined to be different entities, and entity classification data EC is obtained.

4. According to claim 1, a carbon trading privacy protection method based on cross-chain data fusion is characterized in that: The data fusion unit DFU performs data fusion on the same entities in the entity data SD and the entity classification data EC through the HEF algorithm, wherein the HEF algorithm process specifically includes: For multiple identical entities, the application data AD corresponding to each entity data SD is weighted and then sorted from large to small according to the weight; For the i-th application data AD i Key-value pairs The key ApplicationKey in the CM field determines its corresponding smart contract method CM i The corresponding key value mapping relationship: (CM i ,ApplicationKey)→FusionKey Among them, FusionKey represents the fusion data FD generated after fusion FusionKey Keys; The i-th application data AD i Mapping from application data AD to the corresponding position of fusion data FD: Complete data fusion for the same entity.

5. According to claim 4, a carbon trading privacy protection method based on cross-chain data fusion is characterized in that: The data fusion unit DFU performs data fusion on different entities in the entity data SD and the entity classification data EC through the DEF algorithm, wherein the DEF algorithm process specifically includes: According to each entity classification data EC, its corresponding application data AD is determined and fused through HEF algorithm; Traverse the FusionKey in the fused data and follow the fusion function OP defined by FMU in turn FusionKey Calculate the FusionKey and store it in FD in sequence FusionKey , thereby completing the data fusion of different entities.

6. According to claim 1, a carbon trading privacy protection method based on cross-chain data fusion is characterized in that: The steps of generating the transaction verification hash FVH include: For the merged transaction data, first obtain the keys corresponding to multiple application chains AC from the local fusion server LFS; Hash multiple keys and concatenate the results and hash them again: Among them, FK represents the first operation result, ACN represents the total number of application chains AC involved in the fusion, SK' i Represents the key of the i-th application chain AC; Perform hash operation on the fused transaction data distribution, and connect the operation results to the fused data FD: Wherein, TCM represents the second operation result; The transaction verification hash FVH is calculated by the HMAC algorithm:

Images