Privacy protection system and method for high-concurrency cross-channel transactions of alliance chain facing semi-trusted intermediaries

Abstract

The application provides a high-concurrency cross-channel transaction privacy protection system for a consortium chain facing a semi-trusted intermediary, wherein an application layer is used to provide an encryption mode required by a client for a transaction and select an intermediary for delivering transaction information; an intelligent contract layer is used to provide an intelligent contract for a cross-channel transaction; a network layer is used to assemble a blockchain network and pass through a normal node and the intermediary of the blockchain network, so that the normal node and the intermediary perform the cross-channel transaction according to the intelligent contract of the normal node and the intermediary; and a data layer is used to record the cross-channel transaction. The application realizes the use and invisibility of cross-channel transaction data by the semi-trusted intermediary by encrypting the cross-channel transaction data based on a homomorphic encryption algorithm, and aims at the cross-channel transaction data privacy leakage risk caused by the semi-trusted intermediary.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically relating to a privacy protection system and method for high-concurrency cross-channel transactions in consortium blockchains oriented towards semi-trusted intermediaries. Background Technology

[0002] As a core production factor in the digital economy era, data security and privacy protection have become crucial issues for enhancing competition and strengthening cooperation, especially for highly sensitive and valuable transaction data. Researchers in the blockchain field have clearly recognized this and are taking corresponding measures. Cryptocurrency blockchain systems, such as Monero, utilize cryptographic techniques to protect the privacy of on-chain transactions. Consortium blockchain systems also employ channel isolation to protect privacy within channels. Consortium blockchain cross-channel transaction processing solutions based on semi-trusted intermediaries exchange information by sharing channel transaction data with a semi-trusted intermediary, but this comes at the cost of transaction data confidentiality and user privacy. The semi-trusted intermediary has the ability to collect, analyze, and correlate transaction data, increasing the risk of sensitive data leakage. Modern services requiring high privacy place higher demands on consortium blockchain cross-channel transaction processing systems, and existing solutions cannot meet these requirements.

[0003] After years of development, consortium blockchains have achieved a high level of technological maturity and show promising application prospects in various industries. However, large-scale project implementation remains challenging. During business collaboration and value transfer, cross-channel transactions require both parties to share transaction data with a semi-trusted intermediary. This semi-trusted intermediary could potentially attack and then transfer the transaction data, posing threats to cross-channel transaction security and data privacy. Therefore, as a crucial aspect of consortium blockchain technology's practical application, high performance and privacy guarantees in cross-channel transactions are essential for its further commercialization. Optimizing the performance of cross-channel technologies for information transmission and value transfer based on consortium blockchains has become a key research direction. However, factors such as transaction processing limitations hinder the further development of cross-channel transaction systems based on consortium blockchains.

[0004] Current research mainly focuses on realizing a cross-channel transaction processing system based on trusted intermediaries sharing data. On this basis, it provides services for cross-channel asset transfer scenarios and applications, solving the problems of value silos and channel isolation in consortium blockchains.

[0005] Zheng Zhiming et al. used hash sharding technology to distribute data blocks and combined it with Shamir secret sharing technology to design a key management system. This achieved a data sharing protocol design that balances privacy protection and data availability, solving the problem that current technical solutions cannot balance data privacy and security with data availability, and improving the data management efficiency of the supply chain system.

[0006] Wei Ming and others invented a patent entitled "A Blockchain Data Security and Privacy Protection System Based on Decentralized Technology". The blockchain data management platform communicates with the database server through a wireless communication module. The database server includes a data acquisition module, an information filtering module, an information shielding module, an information retrieval module, an identity verification module, a security testing module, and a data testing module. By establishing the blockchain data management platform and the database server in cooperation, a privacy protection effect is formed. At the same time, multi-level identity verification steps are set up to achieve a good privacy protection effect.

[0007] To address the privacy concerns arising from sharing interaction data with semi-trusted intermediaries during cross-channel interactions in consortium blockchains, researching privacy protection for high-concurrency cross-channel transactions based on consortium blockchains is a crucial development direction. However, current intermediary-oriented cross-channel transaction methods based on consortium blockchains have the following drawbacks:

[0008] (1) Existing solutions can realize value flow between channels through consortium blockchain cross-channel transaction processing methods using intermediaries, but the assumption that the intermediary is completely trustworthy is too strong and difficult to meet the actual needs of the production environment. At present, consortium blockchain cross-channel transaction processing based on intermediaries is only applicable to transaction scenarios where the intermediary is completely trustworthy. In practical applications, semi-trusted intermediaries will faithfully complete cross-channel transaction processing, but may carry out attacks such as eavesdropping on transactions, leaking transaction data and destroying the privacy of transaction data.

[0009] (2) Cross-channel transaction process requires locking the intermediary’s assets to ensure strong atomicity. This cross-channel transaction processing mode limits the intermediary’s processing efficiency for cross-channel transactions. The intermediary can only process one transaction at a time, and the remaining transactions are blocked and waiting. The sequential execution of transactions leads to low system transaction processing efficiency, which affects the efficiency of the alliance system in providing services to users. Summary of the Invention

[0010] To address the aforementioned problems in existing technologies, this invention provides a high-concurrency cross-channel transaction privacy protection system and method for consortium blockchains with semi-trusted intermediaries. The technical problem to be solved by this invention is achieved through the following technical solution:

[0011] In the first aspect, the present invention provides a privacy protection system for high-concurrency cross-channel transactions in consortium blockchains with semi-trusted intermediaries. The privacy protection system for high-concurrency cross-channel transactions in consortium blockchains with semi-trusted intermediaries consists of a four-layer structure, namely the application layer, the smart contract layer, the network layer, and the data layer.

[0012] The application layer provides clients with the encryption methods required for transactions and selects intermediaries for transmitting transaction information; encryption methods include homomorphic encryption algorithms.

[0013] The smart contract layer provides smart contracts for cross-channel transactions;

[0014] The channels include source channels and target channels. The smart contract stipulates that intermediaries do not have access to the transaction data and the method of converting the encrypted transaction data.

[0015] The network layer is used to build a blockchain network and enable ordinary nodes and intermediaries in the blockchain network to conduct cross-channel transactions according to their own smart contracts.

[0016] The data layer is used to record cross-channel transactions.

[0017] Secondly, this invention provides a method for protecting privacy in high-concurrency cross-channel transactions in consortium blockchains with semi-trusted intermediaries. Utilizing the first aspect's system for protecting privacy in high-concurrency cross-channel transactions in consortium blockchains with semi-trusted intermediaries, the method includes:

[0018] S100, the client coroutine concurrently initiates a transaction request for cross-channel asset transfer;

[0019] The transaction request carries transaction information;

[0020] S200: The client uses a transaction pool to queue all transaction requests and randomly selects a middleman from the middleman group corresponding to the initiator.

[0021] S300: The encryption module set up by the client encrypts the transaction data carried in the transaction request and verifies the legality of the transaction request. If the verification is successful, the encrypted data is sent to the selected intermediary.

[0022] S400: The client constructs a composite key for transaction information based on the account corresponding to the same intermediary.

[0023] In S500, the middleman adds the composite key to the transaction pool and converts the transaction data in the composite key into a ciphertext vector. Then, privacy calculations are performed on the ciphertext vector to obtain the ciphertext of the transaction settlement result.

[0024] S600: The intermediary updates its own account based on the encrypted transaction settlement result and sends a success message to the client.

[0025] S600: Upon receiving a success notification, the client invokes the smart contract on the target channel and completes the transaction based on the composite key on the source channel and the transaction data received by the intermediary.

[0026] S700: The middleman deducts the corresponding transaction data from his own account, traverses the cross-channel query composite key result set, obtains the target account and encrypted data, then calculates the transferred data based on the exchange rate of the transaction data and updates the target account, while simultaneously sending the transaction result back to the receiving client.

[0027] (1) To address the privacy leakage problem of cross-channel transaction data caused by semi-trusted intermediaries, this invention designs a consortium blockchain cross-channel transaction privacy protection model that includes two encryption algorithms. Based on the AES (Advanced Encryption Standard) encryption algorithm and the CKKS (Cheon-Kim-Kim-Song) encryption algorithm, this invention designs an encrypted transmission mechanism and a privacy calculation mechanism. In addition, to address the problem of high overhead caused by encryption methods, a ciphertext conversion module is designed to convert the array of encrypted transaction amounts to be processed into a ciphertext vector for processing in one step.

[0028] (2) Based on the intermediary mechanism, the present invention designs a cross-channel transaction preprocessing model, which mainly includes composite key construction and transaction pool addition, which are responsible for recording the relationship between cross-channel transactions and storing composite keys respectively, without locking the intermediary's assets; and designs an incremental accumulation method to record the change of each transaction of the intermediary, and finally settles it.

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0030] Figure 1 This is a logical architecture diagram of a high-concurrency cross-channel transaction privacy protection system for consortium blockchains with a semi-trusted intermediary, provided by an embodiment of the present invention.

[0031] Figure 2 This is a model diagram of a high-concurrency cross-channel transaction privacy protection system for consortium blockchains with semi-trusted intermediaries, provided by an embodiment of the present invention.

[0032] Figure 3 This is an interface diagram of the cross-channel transaction smart contract functional module of a high-concurrency cross-channel transaction privacy protection system for semi-trusted intermediaries in a consortium blockchain, provided by an embodiment of the present invention.

[0033] Figure 4 This is a diagram illustrating the ciphertext conversion process of a high-concurrency cross-channel transaction privacy protection system for semi-trusted intermediaries in a consortium blockchain, provided by an embodiment of the present invention.

[0034] Figure 5 This is an interactive flowchart of a high-concurrency cross-channel transaction privacy protection system for consortium blockchains with a semi-trusted intermediary, provided by an embodiment of the present invention. Detailed Implementation

[0035] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.

[0036] Combination Figures 1 to 4 As shown, the present invention provides a high-concurrency cross-channel transaction privacy protection system for consortium blockchains with semi-trusted intermediaries. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains with semi-trusted intermediaries consists of a four-layer structure, namely the application layer, the smart contract layer, the network layer, and the data layer.

[0037] The application layer is used to provide clients with the encryption methods required for transactions and to select the intermediary used to transmit transaction information;

[0038] The application layer includes various funds and points-based services applicable to cross-channel blockchain, such as interbank transfers in the financial sector, international aid in the public welfare sector, and points rewards in the gaming sector.

[0039] The smart contract layer provides smart contracts for cross-channel transactions;

[0040] The system comprises source and target channels, and the smart contract layer includes system smart contracts and cross-channel smart contracts. System smart contracts are responsible for ensuring internal system stability. Cross-channel smart contracts enable cross-channel transactions within the consortium blockchain.

[0041] The network layer is used to build a blockchain network and enable ordinary nodes and intermediaries in the blockchain network to conduct cross-channel transactions according to their own smart contracts.

[0042] The network layer includes ordinary nodes and intermediary nodes. Ordinary nodes are those that can initiate and receive cross-channel transactions. Intermediary nodes are those that process cross-channel transactions. An intermediary institution can have one or more intermediary nodes. Intermediary nodes are responsible for the transmission of transactions between the source channel and the target channel, specifically including receiving source channel transactions and distributing target channel transactions. By sharing a composite key transaction pool through intermediary nodes, the consistency of multi-channel transactions is ensured.

[0043] The data layer is used to record cross-channel transactions.

[0044] The data layer comprises the ledger, the blockchain, and the CouchDB database. Ordinary nodes in the blockchain store copies of the blockchain, and each node maintains a CouchDB database instance as a state database, storing the world state of the entire blockchain. The ledger, as a unification of these two elements, is an abstract concept provided by the data layer to the upper layers of the entire blockchain system.

[0045] The application layer contains a client, which includes an encryption module and a transaction preprocessing module; the smart contract layer contains a transaction collection module, a ciphertext conversion module, a transaction settlement module, a transaction synchronization module, and a decryption module.

[0046] like Figure 2 The document describes six functional mechanisms included in the privacy protection system for high-concurrency cross-channel transactions in consortium blockchains.

[0047] The encryption module is used to encrypt the transaction data in the transaction request initiated by the client and transmit the encrypted data to the transaction preprocessing module;

[0048] Transaction data primarily refers to the transaction amount. During cross-channel transaction processing, the encryption module transmits the encrypted transaction to the smart contract within the system for further processing. Transactions are encrypted immediately upon initiation by the user, ensuring the secure transmission of the transaction request to the consortium blockchain cross-channel transaction network.

[0049] The transaction preprocessing module is used to construct composite keys from transaction information based on the accounts corresponding to the same intermediary.

[0050] Each intermediary receives transaction data from the transaction initiator and sends the transaction data to the recipient.

[0051] The transaction collection module is used to collect all composite keys, extract encrypted transaction data from the composite keys, and assemble the encrypted transaction data into an encrypted array;

[0052] The ciphertext conversion module is used to convert encrypted data into a ciphertext vector;

[0053] The transaction clearing module is used to perform privacy calculations on the transaction data carried in the ciphertext vector to obtain the ciphertext of the transaction clearing result;

[0054] The transaction synchronization module is used to synchronize the encrypted transaction settlement results to the target channel;

[0055] The decryption module is used to restore the ciphertext of the transaction settlement result to plaintext and write the transaction data to the target account according to the target channel.

[0056] This invention designs a model and transaction privacy protection processing mode for a high-concurrency cross-channel transaction privacy protection system in a consortium blockchain. The model includes six modules: encryption, transaction collection, ciphertext conversion, transaction settlement, transaction synchronization, and decryption. The transaction settlement module is the core module of the system model, enabling semi-trusted intermediary nodes to analyze and calculate ciphertext transaction data. The cross-channel transaction privacy protection system features clear functional modules, is easy to maintain, and its batch processing design allows the intermediary to process multiple transactions at once, facilitating improved cross-channel transaction processing efficiency while protecting transaction privacy.

[0057] Furthermore, the transaction clearing module is used to perform internal ciphertext rotation and ciphertext multiplication on the transaction data carried in the ciphertext vector to obtain the ciphertext of the transaction clearing result.

[0058] The ciphertext internal summation is the summation of the components in the ciphertext vector, while the ciphertext multiplication is the multiplication of the transaction data in the ciphertext vector by the exchange rate after the semi-trusted intermediary receives the encrypted transaction.

[0059] The encryption module is used to verify the legitimacy of transaction requests initiated by the client. Only after successful verification will the encrypted data be sent to the intermediary.

[0060] Before encrypting the transaction data in the transaction request initiated by the client, the encryption module initializes the parameters. The initialized parameters include: the dimension of the ring, the ciphertext modulus, the variance of the error polynomial, the multiplication depth, and the plaintext scaling ratio.

[0061] Before converting the ciphertext data, the encryption parameters need to be initialized, including the ring dimension, ciphertext modulus, variance of the error polynomial, multiplication depth, and plaintext scaling ratio.

[0062] The ring dimension is used to define the degree of the cyclotomic polynomial and the number of plaintext / ciphertext polynomial coefficients, and exists in power of 2 form; the ciphertext modulus is related to the ring dimension, and when the ring dimension is fixed, the larger the maximum ciphertext modulus, the lower the security and the lower the performance; the variance of the error polynomial is related to security, and the larger the variance of the error polynomial, the higher the security; the computation depth represents the finite number of multiplications allowed before correct decryption; the plaintext scaling ratio is used in power of 2 form and is related to the precision of the ciphertext output and the number of re-encryption operations before overflow.

[0063] The dimension of the ring: used to define the degree of the cyclotomic polynomial and the number of plaintext / ciphertext polynomial coefficients. It exists in the form of a power of 2. This parameter has an important impact on the security and performance of the algorithm. As the dimension of the ring increases, the security increases, but the performance decreases. Therefore, it needs to be carefully selected to achieve the expected results of the solution.

[0064] Maximum ciphertext modulus: This is related to the dimension of the ring. The choice of this parameter has a great impact on the performance and security of the scheme. When the dimension of the ring is determined, the larger the maximum ciphertext modulus, the lower the security and the lower the performance.

[0065] Variance of the error polynomial: This parameter is also closely related to the safety of the scheme; the larger the variance of the error polynomial, the higher the safety.

[0066] Operational depth: The finite number of multiplications allowed before the noise becomes too great to decrypt correctly;

[0067] Plaintext scaling: In the CKKS encryption algorithm, complex numbers need to be encoded into polynomials with integer coefficients. In this process, the original value needs to be scaled. This parameter is also used in the form of a power of 2 and is related to the precision of the ciphertext output and the number of times it needs to be re-encrypted before overflow.

[0068] Key complexity is crucial to the security of the entire encryption system. The keys involved in this scheme mainly include public and private keys, Galois keys, and relinearization keys. The keys are stored in the privacy dataset of the channel and are not visible to semi-trusted middlemen.

[0069] The key conversion module generates a conversion key based on the initialization parameters and stores the conversion key in the privacy dataset of the transaction channel. The conversion key includes the public and private keys, the Galois key, and the relinearization key. The privacy dataset has an access permission, but the man-in-the-middle does not have access to the privacy dataset.

[0070] After receiving the key conversion module, the key conversion module generates a public-private key pair for each transaction.<sk,pk> Distribute to the source channel and the target channel;

[0071] In this process, the public key pk is used to encrypt transaction data on the source channel, and the private key sk is used by the target channel to decrypt the ciphertext.

[0072] The key conversion module converts encrypted data into a ciphertext vector through ciphertext rotation, and during the rotation process, it uses the Galois key set to sum multiple values ​​within a single ciphertext vector.

[0073] In this invention, ciphertext computation is performed through ciphertext rotation, which is essentially a cyclic movement operation within the slots of the ciphertext vector. The Galois key set is used during the rotation to sum multiple values ​​within a single ciphertext vector.

[0074] The key conversion module generates a relinearized key using the GenRelinearizationKey function.

[0075] Since CKKS is a ring-based homomorphic encryption scheme, multiplication homomorphic operations usually lead to an increase in the ciphertext dimension and a decrease in computational efficiency. Therefore, it is necessary to generate a relinearization key to suppress ciphertext growth. The relinearization key is generated by the GenRelinearizationKey function.

[0076] The encryption module uses the AES encryption algorithm. The ciphertext conversion module uses the conversion key to split the encrypted data compound key, obtain the ciphertext of the transaction amount, and save it into a string array. The man-in-the-middle calls the ciphertext conversion interface to convert the string array into a CKKS ciphertext vector.

[0077] To achieve a privacy-preserving consortium blockchain cross-channel transaction concurrent processing system, this invention combines AES and CKKS encryption algorithms to ensure privacy throughout the entire cross-channel transaction process. In the implementation of the CKKS encryption algorithm, transaction data can be encrypted individually, i.e., only one piece of data is encrypted at a time. Then, a semi-trusted intermediary adds the ciphertexts of multiple transaction data together during transaction clearing. Ingeniously, CKKS's SIMD mode perfectly matches the batch processing operation of the semi-trusted intermediary in this paper. Since the semi-trusted intermediary processes many transactions simultaneously, requiring numerous isomorphic operations, this solution maps multiple transaction data into the plaintext space of CKKS during algorithm implementation, encrypting them uniformly in vector form, reducing transaction data encryption latency and improving transaction processing efficiency.

[0078] like Figure 3 The interface design of the cross-channel transaction smart contract module in the high-concurrency cross-channel transaction privacy protection system of the consortium blockchain is described below.

[0079] Encrypted transmission: Given that the CKKS algorithm is more suitable for processing multiple homogeneous data, the AES encryption algorithm is used first to ensure the confidential transmission of transactions to the consortium blockchain network, aiming to guarantee lightweight encrypted transmission of client transactions;

[0080] Ciphertext Conversion: Responsible for converting AES encrypted ciphertext strings into CKKS ciphertext vectors to support ciphertext calculations. First, the composite key containing encrypted information is split to obtain the ciphertext of the transaction amount and save it into a string array. The man-in-the-middle calls the ciphertext conversion interface to convert the string array into a CKKS ciphertext vector.

[0081] Privacy calculation of transaction amount: mainly includes internal rotation summation of ciphertext and ciphertext multiplication. Internal rotation summation of ciphertext is to sum the components in the ciphertext vector. Ciphertext multiplication is mainly used after the semi-trusted intermediary node receives the encrypted transaction. Since the asset values ​​on the two channels are different, the amount ciphertext needs to be multiplied by an exchange rate before being transferred to the accounts of each transaction recipient.

[0082] Decryption and writing: Responsible for restoring the ciphertext result of the transaction amount to plaintext in order to update the account balances of the semi-trusted intermediary and the transaction recipient;

[0083] This invention designs the functional interface and ciphertext conversion process based on a cross-channel transaction privacy protection system. Combining the cross-channel transaction privacy protection system model, it ensures efficient execution of cross-channel transactions while maintaining confidentiality and sharing of transaction data. Key complexity is crucial to the security of the entire encryption system and requires proper management. The AES encryption algorithm uses a symmetric key K, which is shared by the user client and the source channel and is encrypted and stored on the source channel, invisible to semi-trusted intermediaries. The CKKS encryption algorithm uses an asymmetric encryption key method. The source channel can use the publicly available key pk from the target channel to encrypt the transaction data. After obtaining the encrypted result, the target channel decrypts it using its private key sk. The keys on both the source and target channels are stored in the channel's privacy dataset, invisible to semi-trusted intermediaries. In the implementation of the CKKS encryption algorithm, transaction data can be encrypted individually, i.e., only one piece of data is encrypted at a time. Then, during transaction clearing, the semi-trusted intermediary adds the ciphertexts of multiple transaction data together. Ingeniously, the SIMD mode of CKKS perfectly matches the batch processing operation of the semi-trusted intermediary in this paper.

[0084] Figure 4 This section briefly describes the specific process of ciphertext conversion in a high-concurrency cross-channel transaction privacy protection system on a consortium blockchain:

[0085] Split composite key: Split the composite key containing encrypted information to obtain the ciphertext of the transaction amount and save it to a string array;

[0086] Encrypted data recovery: Iterate through the array to decrypt and obtain the original data;

[0087] Encoding: The imaginary part of the source data is set to 0, it is represented as a complex number and stored in an array, and the array is encoded into plaintext;

[0088] Encryption: The plaintext is encrypted into ciphertext using the CKKS encryption algorithm.

[0089] This invention designs a high-concurrency transaction processing procedure based on a cross-channel transaction privacy protection system. When transactions are initiated concurrently, encrypted transactions are saved to a transaction pool using a composite key, avoiding direct read / write access to the transaction account. By summarizing and statistically analyzing the composite keys, the total amount received by the intermediary is accumulated from multiple encrypted transactions. This amount is then multiplied by the exchange rate of the two assets to obtain the final amount for the target channel, which is then decrypted and written. This not only ensures that transaction data is not leaked during the intermediary's transaction processing but also reduces the possibility of concurrent conflicts under high-concurrency transactions. This high-concurrency transaction privacy processing procedure gives the system excellent transaction performance.

[0090] Figure 5 The flowchart describes the interaction process of a method for protecting privacy in high-concurrency cross-channel transactions in consortium blockchains. The method for protecting privacy in high-concurrency cross-channel transactions in consortium blockchains with a semi-trusted intermediary provided by this invention includes:

[0091] S100, the client coroutine concurrently initiates a transaction request for cross-channel asset transfer;

[0092] The transaction request carries transaction information;

[0093] S200: The client uses a transaction pool to queue all transaction requests and randomly selects a middleman from the middleman group corresponding to the initiator.

[0094] S300: The encryption module set up by the client encrypts the transaction data carried in the transaction request and verifies the legality of the transaction request. If the verification is successful, the encrypted data is sent to the selected intermediary.

[0095] The legitimacy verification process includes checking if the account exists and if the balance is sufficient. If the verification fails, the failure result will be sent back to the client. Only if the verification is successful will the deduction be made from the account balance.

[0096] S400: The client constructs a composite key for transaction information based on the account corresponding to the same intermediary.

[0097] In S500, the middleman adds the composite key to the transaction pool and converts the transaction data in the composite key into a ciphertext vector. Then, privacy calculations are performed on the ciphertext vector to obtain the ciphertext of the transaction settlement result.

[0098] The middleman adds the composite key to the transaction pool. The middleman key is used as the primary key for fuzzy queries. The transaction pool is then traversed to obtain all composite keys containing this primary key. The composite keys in the query result set are split to obtain all encrypted transaction amounts transferred to the middleman and stored in an array.

[0099] S600: The intermediary updates its own account based on the encrypted transaction settlement result and sends a success message to the client.

[0100] The middleman calls the ciphertext conversion interface to convert the encrypted array consisting of the ciphertext transaction amount into a CKKS ciphertext vector. The final amount transferred is obtained by summing the contents of the CKKS ciphertext vector. Finally, the middleman's account is updated, and a success result is sent back to the client.

[0101] S600: Upon receiving a success notification, the client invokes the smart contract on the target channel and completes the transaction based on the composite key on the source channel and the transaction data received by the intermediary.

[0102] Once the client receives the success notification, it calls the smart contract on the target channel to perform the final asset transfer, and calls the cross-channel query function to obtain all composite keys on the source channel and the amount received by the intermediary.

[0103] S700: The middleman deducts the corresponding transaction data from his own account, traverses the cross-channel query composite key result set, obtains the target account and encrypted data, then calculates the transferred data based on the exchange rate of the transaction data and updates the target account, while simultaneously sending the transaction result back to the receiving client.

[0104] The intermediary account deducts the corresponding asset value, iterates through the cross-channel query composite key result set, obtains the target account and the encrypted transaction amount, then calculates the transfer amount based on the exchange rate of the two assets and updates the target account, while returning the result to the client.

[0105] This invention provides a privacy protection system for high-concurrency cross-channel transactions in a consortium blockchain with a semi-trusted intermediary. The system comprises: an application layer providing clients with the necessary encryption methods and selecting an intermediary for transmitting transaction information; a smart contract layer providing smart contracts for cross-channel transactions; a network layer for building a blockchain network and enabling ordinary nodes and intermediaries to conduct cross-channel transactions according to their smart contracts; and a data layer for recording cross-channel transactions. This invention addresses the privacy risks of cross-channel transaction data leakage caused by semi-trusted intermediaries by using homomorphic encryption algorithms to encrypt cross-channel transaction data, achieving usability without visibility of cross-channel transaction data for semi-trusted intermediaries.

[0106] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0107] Although this application has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, the disclosure, and the appended claims in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality.

[0108] The above description, in conjunction with specific preferred embodiments, provides a further detailed explanation of the present invention. It should not be construed that the specific implementation of the present invention is limited to these descriptions. For those skilled in the art, various simple deductions or substitutions can be made without departing from the concept of the present invention, and all such modifications and substitutions should be considered within the scope of protection of the present invention.

Claims

1. A high-concurrency cross-channel transaction privacy protection system for consortium blockchains with semi-trusted intermediaries, characterized in that: The privacy protection system for high-concurrency cross-channel transactions in the consortium blockchain for semi-trusted intermediaries consists of four layers: application layer, smart contract layer, network layer, and data layer. The application layer is used to provide the client with the encryption methods required for transactions and to select the intermediary for transmitting transaction information; the encryption methods include homomorphic encryption algorithms. The smart contract layer provides smart contracts for cross-channel transactions; The channels include source channels and target channels. The smart contract stipulates that intermediaries do not have access to the transaction data and the method of converting the encrypted transaction data. The network layer is used to build a blockchain network and enable ordinary nodes and intermediaries in the blockchain network to conduct cross-channel transactions according to their own smart contracts. The data layer is used to record cross-channel transactions; The application layer includes a client, which contains an encryption module and a transaction preprocessing module; the smart contract layer includes a transaction collection module, a ciphertext conversion module, a transaction settlement module, a transaction synchronization module, and a decryption module. The encryption module is used to encrypt the transaction data in the transaction request initiated by the client and transmit the encrypted data to the transaction preprocessing module; The transaction preprocessing module is used to construct composite keys from transaction information based on the accounts corresponding to the same intermediary. Each intermediary receives transaction data from the transaction initiator and sends the transaction data to the recipient. The transaction collection module is used to collect all composite keys, extract encrypted transaction data from the composite keys, and assemble the encrypted transaction data into an encrypted array; The ciphertext conversion module is used to convert an encrypted array into a ciphertext vector; The transaction clearing module is used to perform privacy calculations on the transaction data carried in the ciphertext vector to obtain the ciphertext of the transaction clearing result; The transaction synchronization module is used to synchronize the encrypted transaction settlement results to the target channel; The decryption module is used to restore the ciphertext of the transaction settlement result to plaintext and write the transaction data to the target account according to the target channel.

2. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 1, characterized in that, Before encrypting the transaction data in the transaction request initiated by the client, the encryption module initializes its parameters. The initialized parameters include: the dimension of the ring, the ciphertext modulus, the variance of the error polynomial, the multiplication depth, and the plaintext scaling ratio.

3. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 2, characterized in that, The dimension of the ring is used to define the degree of the circumradical polynomial and the number of plaintext / ciphertext polynomial coefficients, and exists in power of 2 form; the ciphertext modulus is related to the dimension of the ring. When the dimension of the ring is determined, the larger the maximum ciphertext modulus, the lower the security and the lower the performance; the variance of the error polynomial is related to security. The larger the variance of the error polynomial, the higher the security; the computation depth represents the finite number of multiplications allowed before correct decryption; the plaintext scaling ratio is used in power of 2 form and is related to the precision of the ciphertext output and the number of re-encryption operations before overflow.

4. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 2, characterized in that, The ciphertext conversion module generates a conversion key based on the initialized parameters and stores the conversion key in the privacy dataset of the transaction channel; The conversion key includes a public-private key, a Galois key, and a relinearization key. The privacy dataset has an access permission, and the man-in-the-middle does not have access to the privacy dataset.

5. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 4, characterized in that, The ciphertext conversion module generates a public-private key pair for each transaction. , Distribute to the source channel and the target channel; In this process, the public key pk is used to encrypt transaction data on the source channel, and the private key sk is used by the target channel to decrypt the ciphertext. The ciphertext conversion module converts the encrypted array into a ciphertext vector by ciphertext rotation, and during the rotation process, it uses the Galois key set to sum multiple values ​​within a single ciphertext vector; The ciphertext conversion module generates a relinearization key using the GenRelinearizationKey function.

6. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 5, characterized in that, The encryption module uses the AES encryption algorithm. The ciphertext conversion module uses the conversion key to split the encrypted data composite key, obtain the ciphertext of the transaction amount, and save it into a string array. The man-in-the-middle calls the ciphertext conversion interface to convert the string array into a CKKS ciphertext vector.

7. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 1, characterized in that, The transaction clearing module is used to perform internal ciphertext rotation and ciphertext multiplication on the transaction data carried in the ciphertext vector to obtain the ciphertext of the transaction clearing result. The ciphertext internal summation is the summation of the components in the ciphertext vector, while the ciphertext multiplication is the multiplication of the transaction data in the ciphertext vector by the exchange rate after the semi-trusted intermediary receives the encrypted transaction.

8. The high-concurrency cross-channel transaction privacy protection system for consortium blockchains oriented towards semi-trusted intermediaries as described in claim 1, characterized in that, The encryption module is used to verify the legitimacy of transaction requests initiated by the client. Only after successful verification will the encrypted data be sent to the intermediary.

9. A method for protecting privacy in high-concurrency cross-channel transactions in consortium blockchains with semi-trusted intermediaries, characterized in that: The high-concurrency cross-channel transaction privacy protection system for consortium blockchains with semi-trusted intermediaries as described in any one of claims 1 to 8, wherein the method for high-concurrency cross-channel transaction privacy protection for consortium blockchains with semi-trusted intermediaries includes: S100, the client coroutine concurrently initiates a transaction request for cross-channel asset transfer; The transaction request carries transaction information; S200: The client uses a transaction pool to queue all transaction requests and randomly selects a middleman from the middleman group corresponding to the initiator. S300: The encryption module set up by the client encrypts the transaction data carried in the transaction request and verifies the legality of the transaction request. If the verification is successful, the encrypted data is sent to the selected intermediary. S400: The client constructs a composite key for transaction information based on the account corresponding to the same intermediary. In S500, the middleman adds the composite key to the transaction pool and converts the transaction data in the composite key into a ciphertext vector. Then, privacy calculations are performed on the ciphertext vector to obtain the ciphertext of the transaction settlement result. S600: The intermediary updates its own account based on the encrypted transaction settlement result and sends a success message to the client. S600: Upon receiving a success notification, the client invokes the smart contract on the target channel and completes the transaction based on the composite key on the source channel and the transaction data received by the intermediary. S700: The middleman deducts the corresponding transaction data from his own account, traverses the cross-channel query composite key result set, obtains the target account and encrypted data, then calculates the transferred data based on the exchange rate of the transaction data and updates the target account, while simultaneously sending the transaction result back to the receiving client.

Images