A Carbon Trading Privacy Protection Method Based on Cross-Chain Data Fusion

Abstract

The present invention discloses a carbon trading privacy protection method based on cross-chain data fusion, which includes: obtaining a number of transaction data from multiple application chains according to the transaction hash value through a blockchain interaction interface and sending them to a transaction parsing interface; the transaction parsing interface parses the obtained number of transaction data based on a smart contract method and a mapping table to obtain entity data and entity classification data; a data fusion unit fuses the application data in the entity data to obtain fusion data, generates a transaction verification hash that can be used to verify the fusion data, and finally uploads the fusion data and the transaction verification hash to a cross-chain network; the cross-chain network uploads the fusion data and the transaction verification hash to the application chain. The present invention designs algorithms in aspects such as transaction parsing, entity parsing, and data fusion for the problem of scattered transaction data between different blockchains at present, and solves the problems of fusing different blockchain transactions and uploading the fusion data to the chain.

Description

Technical Field

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

[0002] Carbon trading is a general term for greenhouse gas emission rights trading. Based on carbon trading, a complete mechanism can be realized to manage carbon emissions. Enterprises and institutions conduct reasonable carbon trading under the carbon trading mechanism, so that carbon emissions can be reasonably allocated, and ultimately the overall social carbon emissions can be reduced. At the same time, carbon trading also pays attention to measures such as supervision, incentive, and punishment of enterprises and institutions in terms of carbon emissions. Through these measures, the carbon emissions and trading behaviors of enterprises and institutions are standardized.

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

[0004] However, during the development of blockchain, multiple blockchain projects such as Ethereum, Hyperledge ledge, and fisco bcos have emerged. Different carbon trading organizations may use different blockchain projects as their underlying blockchains. And due to differences in smart contracts and data structure designs during the deployment of carbon trading, it is difficult for existing carbon trading blockchains to achieve data interoperability, increasing the tracing cost of users for different blockchain carbon trading. 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, and designs algorithms for transaction parsing, entity parsing, data fusion, etc. to solve the problems of transaction fusion between different blockchains and uploading of fused data, protecting the privacy of transaction data.

[0006] To achieve the above object, the present invention provides the following technical solutions:

[0007] A carbon trading privacy protection method based on cross-chain data fusion provided by the present invention includes:

[0008] Obtain a number of 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 parsing interface TAI;

[0009] The transaction parsing interface TAI parses the obtained number of 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, the mapping table MT, and the entity classification data EC sent by the transaction parsing interface TAI, the data fusion unit DFU fuses the application data AD in the entity data SD to obtain fusion data FD, generates a transaction verification hash FVH that can be used to verify the fusion data FD, and finally uploads the fusion 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] The smart contract method group is a set of multiple smart contract methods CM pointing to the same type in reality, and 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 representing any smart contract, which is obtained by performing a hash operation on the total string formed by splicing the smart contract address and the relevant method string.

[0015] Preferably, during the process of the transaction parsing interface TAI parsing the obtained number of transaction data, it performs the following:

[0016] Parse the transaction data of different application chains AC respectively. For the i-th transaction data Tx i Parse and generate its corresponding smart contract method CM i and application data AD i of the binary tuple:

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

[0018] Store the binary tuples corresponding to multiple transaction data in a set to form an entity data SD, forming a vector with tx_num dimensions, where the value of tx_num is the total number of transactions participating in the fusion this time:

[0019]

[0020] Determine each smart contract method CM i Whether it belongs to the same smart contract method group CMO j In, the following formula needs to be satisfied:

[0021]

[0022] If not satisfied, it is determined that it does not meet the fusion conditions and it is not selected for fusion;

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

[0024] Determine for And Whether the following formula is satisfied:

[0025]

[0026] Among them, MT(CM i , ApplicationKey) represents the mapping relationship of the binary group composed of the value of CM i And its corresponding key ApplicationKey to FusionKey, MT(CM j , ApplicationKey) represents the mapping relationship of the binary group composed of the value of CM j And its corresponding key ApplicationKey to FusionKey;

[0027] When satisfied, it is determined as the same entity, and when not satisfied, it is determined as different entities, and entity classification data EC is obtained.

[0028] Preferably, the data fusion unit DFU performs data fusion on the entity data SD and the entity classification data EC for the same entities through the HEF algorithm. The specific process of the HEF algorithm includes:

[0029] For multiple identical entities, after weighting the application data AD corresponding to each entity data SD, sort them from largest to smallest according to the weight value;

[0030] For the i-th application data AD i Of the key-value pairs The key ApplicationKey in, determine the mapping relationship of the key value corresponding to its corresponding smart contract method CM i To:

[0031] (CM i, ApplicationKey) → FusionKey

[0032] Among them, FusionKey represents the key of the fused data FD generated after fusion FusionKey ;

[0033] Map the i-th application data AD i to the corresponding position of the fused data FD:

[0034]

[0035] Complete the data fusion of the same entity.

[0036] Preferably, the data fusion unit DFU performs data fusion on the entity data SD and the entity classification data EC for different entities through the DEF algorithm. The specific process of the DEF algorithm includes:

[0037] Determine the corresponding application data AD according to each entity classification data EC and fuse it through the HEF algorithm;

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

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

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

[0041] Perform a hash operation on multiple keys, concatenate the results, and then perform a hash operation again:

[0042]

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

[0044] Perform a hash operation on the distribution of the fused transaction data, concatenate the operation results, and then concatenate the fused data FD:

[0045]

[0046] Among them, TCM represents the second operation result;

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

[0048]

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

[0050] 1. A multi-chain data fusion scheme is proposed, and a local fusion server is used to obtain and parse multi-chain carbon trading data, erasing the data structure differences when processing carbon trading data of different blockchains.

[0051] 2. Aiming at problems such as data duplication and inconsistency existing in different carbon trading-related blockchains, the scheme designs a transaction data fusion algorithm TDF. The TDF algorithm classifies carbon trading entities through a transaction entity parsing algorithm TER, and realizes the fusion of carbon trading data through a same entity transaction fusion (HEF) algorithm and a different entity transaction fusion (DEF) algorithm.

[0052] 3. In the data fusion stage, the scheme uses the HMAC algorithm to obtain a message authentication code based on FD 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 uploading the fused data to the chain, the scheme uses cross-chain technology to ensure the atomicity of uploading the fused data.

[0054] Other advantages, objectives and features of the present invention will be elaborated in the subsequent specification, and to some extent will be obvious to those skilled in the art, or those skilled in the art can obtain teachings from the practice of the present invention. The objectives and other advantages of the present invention can be achieved and obtained through the following specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] To make the objectives, technical solutions and beneficial effects of the present invention clearer, the present invention provides the following drawings for illustration:

[0056] Figure 1 It is the overall 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 the pseudo-code schematic diagram of the transaction entity parsing algorithm in an embodiment of the present invention;

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

[0059] Figure 4 It is the pseudo-code schematic diagram of the DEF algorithm designed for the transaction fusion of different entities in an embodiment of the present invention;

[0060] Figure 5 It is the flowchart of the specific steps for FVH generation in the embodiments of the present invention;

[0061] Figure 6 It is the process diagram of FVH verification in the embodiments of the present invention. Specific Embodiments

[0062] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only for the purpose of illustrating and explaining the present invention, and are not used to limit the present invention.

[0063] A carbon trading privacy protection method based on cross-chain data fusion provided by the present invention proposes a multi-chain data fusion scheme (MCDFS) for the problem of scattered transaction data between different blockchains. Algorithms in aspects such as transaction parsing, entity parsing, and data fusion are designed in the scheme to solve the problems of fusing different blockchain transactions and uploading the fused data to the blockchain. Refer to Figure 1 , including:

[0064] Application Chain (AC): The blockchain where the application program is located in the actual process. The transactions in AC are the objects to be fused by MCDFS.

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

[0066] Blockchain Interaction Interface (CII): Establish connections with their respective blockchains. Its main tasks include obtaining transactions through transaction Hashes and transmitting transaction information to TAI.

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

[0068]

[0069] Smart Contract Method (CM): CM is the hash value of a method representing a certain smart contract, as shown in Formula 2, which is obtained by performing a hash operation on the total string formed by concatenating the smart contract address and 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 initiating account, fuel cost, timestamp, etc., and smart contract call parameters. It is also the data to be fused obtained by parsing the transaction.

[0072] Subject Data (SD): SD contains AD and CM data formed by parsing each transaction.

[0073] Fused Data (FD): FD is also a string of key-value pairs like AD, and it is the fused result data generated after fusing multiple ADs.

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

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

[0076] Entity Classification (EC): EC is the process data generated during the parsing process. It is classified according to whether the transactions point to the same entity in reality. EC consists of multiple sets, and each set is a set of transactions pointing to the same real entity. The structure of EC is represented by

[0077] Equation 3. Each EC consists of several transactions

[0078]

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

[0080] Mapping Table (MT): Managed by FMU, it stores the mapping information of AD fields to FD fields.

[0081] Smart Contract Method Organization (CMO): It classifies the CMs pointing to the same type of time in reality into an organization, and CMO maintains the information of this organization.

[0082] Fusion Management Unit (FMU): FMU mainly has two tasks. The first is to manage the classification of CMs, classifying them into different CM organizations (CMOs). The second is to manage the mapping relationship between the fields in each CM and the FD fields, and store it as a mapping table (MT).

[0083] Data Fusion Unit (DFU): It obtains CMs from TAI, and at the same time obtains CMOs and MTs from FMU, performs steps such as data fusion of transactions and generation of FD hash values, and can also call the SDK interface provided by the cross-chain network to upload fusion information.

[0084] In a specific implementation, the architecture of LFS mainly consists of three layers, including the Blockchain Interaction Layer (CIL), the Transaction Analysis Layer (TAL), and the 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;

[0085] The Blockchain Interaction Layer CIL connects AC and TAL, obtains AC transactions and transfers them to TAL or initiates transactions to AC. Since AC is different types of blockchains in the production environment, LFS needs to interact with AC through the Blockchain Interaction Interface (CII) in CIL. For different blockchains, it can be divided into FISCO BCOS2 CII, Hyperledge fabric CII, etc.

[0086] The Transaction Analysis Layer TAL connects CIL and DFL, and is a necessary processing layer before data fusion. It is mainly used to analyze transactions of different ACs to form a standardized data to be fused, including Smart Contract Methods (CM) and Application Data (AD). The analysis of transactions is shown in Formula 4. The original transaction Tx i is parsed to generate CM i and AD i as a binary tuple. At the same time, entity parsing will be performed on the data to obtain whether CM is in the same CMO and generate the EC value.

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

[0088] For the entity parsing of TAL, the Transaction Entity Resolution (TER) algorithm is proposed. The TER algorithm is used to solve the judgment of whether transactions are in the same CMO and the generation of EC. The specific algorithm will be introduced later.

[0089] In the Data Fusion Layer DFL, the fusion of transaction data is performed. The data to be fused is obtained from TAL, and the fusion of AD, the generation of hash values, etc. are mainly carried out through DFU.

[0090] DFU mainly performs data fusion. According to the entity parsing results, including three results of different entities in the same CMO, the same entity in the same CMO, and different CMOs, subsequent fusion methods are selected, and the DEF algorithm, HEF algorithm, and non-fusion are used respectively. The specific fusion algorithms will be introduced later.

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

[0092] In a specific implementation process, MCDFS is divided into four major steps: transaction acquisition, transaction parsing, transaction fusion, and data upload. Specifically, it can be further divided into eight small steps:

[0093] 1. Retrieve transactions: CII retrieves several transactions from multiple ACs according to the transaction hash value.

[0094] 2. Send transactions: CII forwards the transactions obtained in step 1 to TAI.

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

[0096] 4. Entity analysis: TAI parses the transactions of the AC to form data such as SD and EC, and performs entity parsing during this process to judge the entity relationship of the transactions.

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

[0098] 6. Fusion: DFU performs operations such as fusing the AD in SD and generating TVH to obtain data such as FD, TVH, contract address, and transaction address.

[0099] 7. Upload data: DFU uploads the data generated by fusion to the cross-chain network.

[0100] 8. Transaction upload: The cross-chain network generates a transaction based on the uploaded fusion data and uploads it to the AC chain.

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

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

[0103] Definition:

[0104] 1. List of smart contract methods for data to be fused (CM i ), where i represents different transactions in one fusion. As shown in formula 5, the CM and AD corresponding to each transaction form a binary group and are stored in SD. SD forms a vector with a dimension of tx_num, and the value of tx_num is the number of transactions in this fusion.

[0105]

[0106] 2. Smart Contract Method Organization (CMO j ), and each CMO j is a different set that stores several CMs i .

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

[0108] 4. Fused data FD FusionKey , which is the data generated after fusion, and FusionKey represents the key of the fused data.

[0109] 5. Mapping relationship represents the mapping relationship from the key value corresponding to a certain CM i , and the relationship is represented by formula 6.

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

[0111] The mapping relationship is the mapping relationship from a binary tuple composed of a CM value and ApplicationKey to FusionKey, defined as the function MT(CM, ApplicationKey) = FusionKey. At the same time, there is a bit set as the determination bit (AP) in FusionKey in the same CMO j , which is equivalent to the primary key in FD FusionKey .

[0112] Entity resolution includes two steps:

[0113] Step 1: Determine whether all CMs i exist in the same CMO j , that is, it is necessary to satisfy formula 7:

[0114]

[0115] When there is a non-conforming situation, the fusion is interrupted and it is determined that the fusion is not suitable.

[0116] Step 2: Determine for to satisfy formula 8:

[0117]

[0118] According to whether it conforms to the formula in step two, it is divided into two categories: the same entity and different entities, and the two are fused according to different algorithms.

[0119] Design a transaction entity resolution algorithm (TER) asFigure 2 .

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

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

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

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

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

[0125] definition:

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

[0127] weight=(weight1,weight2,…,weight n )∈R n #(9)

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

[0129] CM=(CM1,CM2,…,CM n )#(10)

[0130] Algorithm core:

[0131] The HEF algorithm mainly implements the process of mapping AD to FD. First, the corresponding FusionKey needs to be obtained through formula 6, and the data is mapped from AD to the corresponding position of FD using formula 11.

[0132]

[0133] An important issue that the HEF algorithm needs to solve is data conflict. AD i Mapped to FD, AD in HEF i 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:

[0134]

[0135] At this time, it is mapped to the corresponding FD FusionKey There are multiple values, and HEF solves it by comparing weights, that is, the largest weight is selected in turn i , where i is the subscript of the transaction sequence, and the corresponding AD i is mapped to FD according to its ApplicationKey. If the mapped position FD FusionKey is not empty, it proves that there is a higher-priority AD i occupying this position, and this mapping will no longer be performed.

[0136] The HEF algorithm processes the data fusion of the same entity. For a FD field of the same entity, there should not be multiple values. Therefore, HEF assigns values to FD from large to small with the AD weight weight as the index by comparing weights. Through the HEF algorithm, multiple AD data can be fused to generate a new FD data. The pseudocode of the HEF algorithm is as Figure 3 shown.

[0137] In a specific embodiment, the DEF algorithm is proposed for the transaction fusion design of different entities. The pseudocode of the DEF algorithm is as Figure 4 shown:

[0138] The algorithm needs to be carried out under the condition of obtaining the entity classification EC according to Formula 12. EC is the multiple organizations divided according to whether the CM in this fusion is the same entity. EC stores the transaction coordinate values and unifies EC into the ECS set, as shown in Formula 13

[0139]

[0140] The DEF algorithm is mainly divided into two steps. The first step is to fuse the ADs in each EC into an entity data ED through the HEF algorithm. The second step is to traverse the FusionKey and calculate the FusionKey of FD according to OP FusionKey in turn. Among them, OP FusionKey is a fusion function defined by FMU. OP FusionKey has high flexibility to cope with different application scenarios. The most common OP FusionKey is redundant storage, that is, the data corresponding to the FusionKey in each ED is stored into FD FusionKey in turn.

[0141] In a specific embodiment, the FVH generation phase is carried out in the LFS. The FVH generation is based on the HMAC as the underlying algorithm. The HMAC algorithm is a cryptographic hash operation. The HMAC algorithm is used to generate the message authentication code for the fusion process, ensuring the trustworthiness of the fusion data transaction. By incorporating the key into the process of generating the hash value, the correct hash value can only be obtained with the correct key participating in the hash operation to improve the immutability of the message. The description of HMAC is shown in Formula 14:

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

[0143] Where key is the 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 performs exclusive OR operations on key′ with opad and ipad respectively, performs a hash operation on the value generated by the calculation with opad, concatenates the value generated by the calculation with ipad with the m string and then performs a hash operation, and then concatenates the two values and performs another hash operation to generate a fixed-length message authentication code, which can be used to protect the data integrity of the message.

[0144] The generation of FVH depends on data such as keys and transaction information. The specific steps of FVH generation are represented by Figure 5 as follows:

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

[0146] SKset=(SK1,SK2,SK3,…)#(15)

[0147] For different source ACs of transactions, the LFS uses different SKs for the HMAC algorithm. In the first step, it is necessary to extract several corresponding SKs according to the AC source, and define the extraction result as SK′ i , where i is the subscript of the extracted SK.

[0148] The LFS needs to perform hash operations on SK′ i respectively, and define ACN to represent the number of relevant ACs participating in the fusion:

[0149]

[0150] Link SK′ i Connect the results of the hash operations performed separately, and perform the hash operation again to obtain FK. FK is used for operation as the key in the HMAC algorithm.

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

[0152]

[0153] The result of TCM is used as m in the HMAC algorithm. The following formula uses the HMAC algorithm to implement the calculation of FVH:

[0154]

[0155] Calculate FVH by using FK and TCM as the key and m in the HMAC algorithm. FVH is uploaded to the chain together with the fusion information and can be used to verify that the on-chain fusion transaction information comes from LFS, protecting the verifiability of the data source of the transaction.

[0156] The security of FVH verification comes from the irreversibility and collision resistance of HMAC. The irreversibility of HMAC enables LFS to quickly obtain FVH through FK and TCM, while an attacker cannot obtain FK through FVH and TCM within an effective time. The collision resistance of HMAC enables an attacker not to find a string TCM′ such that formula 19 holds.

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

[0158] The process of FVH verification is as Figure 6 shown, mainly for verifying the trustworthiness of the source of the transaction FTX generated after on-chain fusion.

[0159] For verification, first obtain FTX from the application chain, parse FTX to obtain three types of data: FVH, FD, and the transaction address. Through the transaction address, the source transaction information can be obtained from AC. LFS performs the FVH generation steps described in the previous subsection on the source transaction, FD, and FK to generate FVH for verifying FTX. Then compare FVH with the obtained FVH. If they are equal, it proves that FTX is trustworthy; otherwise, it is not trustworthy.

[0160] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not restrictive. 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, Including: Obtain a number of 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 parsing interface TAI; The transaction parsing interface TAI parses the obtained number of 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, the mapping table MT, and the entity classification data EC sent by the transaction parsing interface TAI, the data fusion unit DFU fuses the application data AD in the entity data SD to obtain fusion data FD, generates a transaction verification hash FVH that can be used to verify the fusion data FD, and finally uploads the fusion 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; 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. The specific process of the HEF algorithm includes: For multiple identical entities, weight the application data AD corresponding to each entity data SD and then sort them from largest to smallest according to the weights; For the i-th application data AD i key-value pair in the key ApplicationKey, determine the smart contract method CM i The mapping relationship of the binary tuple composed of CM and ApplicationKey to FusionKey: (CM i , ApplicationKey) → FusionKey Among them, FusionKey represents the key of the fused data FD generated after fusion FusionKey ; Map the i-th application data AD i to the corresponding position of the fusion data FD: Complete the data fusion of the same entities; 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. The specific process of the DEF algorithm includes: Determine the corresponding application data AD according to each entity classification data EC and fuse it through the HEF algorithm; Traverse the FusionKey in the fused data, and successively calculate the FusionKey according to the fusion function OP defined by the FMU FusionKey and store it in FD successively FusionKey , thus completing the data fusion of different entities.

2. The carbon trading privacy protection method based on cross-chain data fusion according to claim 1, wherein The smart contract method organization CMO includes multiple smart contract method groups; The smart contract method group is a set of multiple smart contract methods CM pointing to the same type in reality, and 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 representing any smart contract, which is obtained by performing a hash operation on the total string formed by splicing the smart contract address and the relevant method string.

3. A carbon trading privacy protection method based on cross-chain data fusion according to claim 1, characterized in that During the process of parsing the obtained number of transaction data by the transaction parsing interface TAI, the following operations are performed: Parse the transaction data of different application chains AC respectively. For the i-th transaction data Tx i Parse and generate its corresponding smart contract method CM i and application data AD i The binary tuple of: Tx i →(CM i ,AD i ) Store the binary groups corresponding to multiple transaction data in a set to form an entity data SD, forming a vector of tx_num dimensions, where the value of tx_num is the total number of transactions participating in the fusion this time: Judge each smart contract method CM i Whether it belongs to the same smart contract method group CMO j In, the following formula needs to be satisfied: If not satisfied, it is determined that the fusion condition is not met, and it is not selected for fusion; If the condition is met, determine the application data AD i key-value pair of the key ApplicationKey in; Determine for and whether the following formula is satisfied: Among them, MT(CM i , ApplicationKey) represents the mapping relationship of the binary tuple composed of the CM i value and its corresponding key ApplicationKey to FusionKey; When satisfied, it is determined as the same entity, and when not satisfied, it is determined as a different entity, and the entity classification data EC is obtained.

4. A carbon trading privacy protection method based on cross-chain data fusion according to claim 1, characterized in that The generation steps of the transaction verification hash FVH include: For the fused transaction data, first obtain the keys corresponding to multiple application chains AC from the local fusion server LFS; Perform a hash operation on multiple keys and connect the results and then perform a hash operation again: Among them, FK represents the first operation result, ACN represents the total number of application chains AC participating in the fusion, and SK′ i represents the secret key of the i-th application chain AC; Perform a hash operation on the fused transaction data respectively, connect the operation results, and then connect the fusion data FD: Among them, TCM represents the second operation result; Calculate the transaction verification hash FVH through the HMAC algorithm:

Images