A trusted cross-chain transaction privacy protection method

Abstract

The application discloses a kind of trusted cross-chain transaction privacy protection methods, comprising the following steps: step 1, user creates a transaction on main chain, asset is sent to the address on side chain, transaction input is converted into a set of public parameters and secret parameters;Step 2, using zk_SNARKs algorithm generates a proof, proves the validity of transaction, and protects the privacy of transaction.Step 3, the secret parameter in the proof is encrypted using AES encryption algorithm, and the ciphertext is stored in SGX;Step 4, the proof is sent to the verification node on side chain, and the verification node uses zk_SNARKs algorithm to verify the validity of the proof.Step 5, if the proof is verified successfully, the verification node on side chain can use the key inside SGX to decrypt the secret parameter, so as to carry out transaction.The application saves the proof generated by zk_SNARKs and key into SGX, so that cross-chain transaction is more private and secure.

Description

Technical Field

[0001] This invention relates to the field of zero-knowledge proof technology in blockchain cryptography, specifically a trusted method for protecting privacy in cross-chain transactions. Background Technology

[0002] With the rapid development of blockchain in recent years, unlike traditional databases, blockchain features decentralization, collaborative maintenance, transparency, and traceability. These characteristics enable blockchain to better adapt to data management systems with high security requirements. However, as blockchain applications become more widespread, the demand for cross-chain technology between multiple blockchains is also gradually increasing. Currently, mainstream cross-chain technologies include atomic swap technology, cross-chain communication protocols, and multi-chain interoperability protocols.

[0003] Cross-chain technology aims to connect independent blockchains, enabling value exchange between blockchains with different value systems. Because blockchain ledgers are public and transparent, privacy protection has become a major concern. In recent years, numerous attacks have targeted cross-chain transactions. In July 2021, the cross-chain project AnySwap suffered a hack after its administrator's private key was stolen, resulting in losses exceeding $8 million. In August 2021, the Poly Network cross-chain interoperability protocol was hacked, causing losses exceeding $600 million. Therefore, ensuring system security and protecting privacy during cross-chain transactions is a crucial issue that deserves serious consideration. Summary of the Invention

[0004] (a) Technical problems to be solved

[0005] The purpose of this invention is to protect private parameters generated during cross-chain transactions using zk_SNARKs from being stolen by attackers. This is achieved through a hardware protection technology, Intel SGX, for encrypted storage. While ensuring a trustworthy cross-chain environment, the private parameters generated by zk_SNARKs are stored and encrypted in SGX. The proof generated by the zk_SNARKs algorithm is then sent to the verification nodes on the sidechain for verification. If verification is successful, the verification nodes on the sidechain can decrypt the private parameters using the key within SGX, and then perform the cross-chain transaction. Using SGX for encrypted storage of private parameters further ensures the security and privacy of cross-chain transactions.

[0006] (II) Technical Solution

[0007] To achieve the above objectives, the present invention provides the following technical solution: a reliable cross-chain transaction privacy protection method, specifically implemented according to the following steps:

[0008] Step 1: The user creates a transaction on the main chain and sends the assets to an address on the side chain of the main chain. The transaction input is converted into a set of public parameters and private parameters. The public parameters include public information of the main chain and the side chain, and the private parameters include private information of the transaction, such as the input and output amounts of the transaction.

[0009] Step 2: Use the zk_SNARKs algorithm to generate a proof that demonstrates the validity of the transaction and protects the privacy of the transaction; the proof includes the hash values ​​of the public and private parameters, as well as a random number and the calculation result;

[0010] Step 3 involves encrypting the private parameters in the proof using the AES encryption algorithm and storing the encrypted ciphertext in the SGX. The key used in the encryption process can only be accessed internally by the SGX, thus ensuring the security of the private parameters. This is a security extension technology developed by Intel Corporation (Software Guard Extensions), abbreviated as Intel SGX.

[0011] Step 4: The proof is sent to the verification nodes on the sidechain. The verification nodes use the zk_SNARKs algorithm to verify the validity of the proof. The verification nodes only need to check whether the hash value in the proof matches the calculation result, without needing to know the private information in the proof.

[0012] Step 5: If the verification is successful, the verification node on the sidechain uses the key inside SGX to decrypt the private parameters and then proceeds with the transaction.

[0013] Preferably, step 1 is implemented according to the following steps:

[0014] Step 1.1: Create a user named zendoo, add it to a group called sudo and assign a password to the zendoo user, then switch to the zendoo user;

[0015] Step 1.2: Start the main chain, then configure the side chain. Use the bootstrap tool to create wallet addresses on the side chain and enable WebSocket for communication between the main chain and the side chain; WebSocket is a protocol for full-duplex communication over a single TCP connection. Generate 200 blocks to activate the side chain and generate the side chain identifier; configure the configuration file and start the side chain.

[0016] Step 1.3: Send the transaction to the websocket used for communication between the main chain and the side chain, and then convert the websocket into a set of public and private parameters.

[0017] Preferably, step 2 is implemented according to the following steps:

[0018] Step 2.1, given a security parameter λ, through Setup(1 λ →PP z The algorithm generates a common parameter list PP z =(p,e,G1,P1,G2,P2,G) T ,P T (), where P is a prime number, e is a bilinear mapping, G1 is the first group used to store the field of the discrete logarithm problem; P1 is a generator in G1 used to generate elements in G1; G2 is the second group used to store the field of the discrete logarithm problem; P2 is a generator in G2 used to generate elements in G2; G T It is the target group, used to store the results of bilinear mappings; P T It is G T The generators in G are used to generate G. T Elements in;

[0019] G1×G2→G T All algorithms use PP. z As public default input parameters; public default input parameters include polynomials, public parameters of the signature proof system, public parameters of the verification proof system, and other parameters required for signature verification;

[0020] Step 2.2, given circuit C, use KeyGen(C)→(Pk) z Vk z The algorithm utilizes the common parameter PP. z Generate key pair (Pk) z Vk z );Pk z It is the proof key generated, Vk z It is the verification key for proof and verification;

[0021] Step 2.3, using GenProof(Pk) z The algorithm ,sk,pk)→π generates a zero-knowledge proof of π; Pk z is the proof key; pk is a public declaration and is the input of circuit C; sk is a private verification and is the auxiliary input of circuit C;

[0022] Step 2.4: Send the public parameters to the sidechain. The private parameters are known only to the generator and are used to verify the legality and security of this cross-chain transaction.

[0023] Preferably, step 3 is implemented according to the following steps:

[0024] Step 3.1: Use the OpenSSL cryptographic library to generate an RSA public and private key pair. The RSA public key is stored in SGX and can be made public to others. OpenSSL is an open-source cryptographic library.

[0025] Step 3.2: Serialize the proof and private parameters generated by the zk_SNARKs algorithm into a byte array, then use the serialized proof as input and encrypt the serialized proof using the public key to obtain the encrypted ciphertext;

[0026] Step 3.3: Create a new SGX project and define the corresponding Enclave in the code. Create a data structure in the Enclave to store the ciphertext; a hardware-protected secure execution environment (Software GuardExtensions Enclave), abbreviated as Enclave;

[0027] Step 3.4: Implement the code logic in the Enclave to convert plaintext into ciphertext and store it in the data structure created in the previous step; in the unprotected environment that communicates with the Enclave, create a function to accept plaintext as input and output the plaintext to the Enclave, and also create another function to retrieve the ciphertext from the Enclave;

[0028] Step 3.5: Implement another function on the host that converts the ciphertext within the Enclave into plaintext and returns the plaintext to the caller.

[0029] Preferably, step 4 is implemented according to the following steps:

[0030] Step 4.1: The verification node receives the transaction proof from the sidechain, including cross-chain transaction information and proof key;

[0031] Step 4.2: Before verifying the transaction proof, the verification node needs to prepare the relevant validity information and check whether the hash value and calculation result match. If the transaction proof is valid, proceed to the next step; if the transaction proof is invalid, reject the transaction.

[0032] Preferably, step 5 is implemented according to the following steps:

[0033] Step 5.1: The transaction has been verified as valid, and the verification node can execute the cross-chain transaction;

[0034] Step 5.2: During transaction execution, the verification node can use the key inside SGX to decrypt the private parameters and use them in the transaction process. This operation protects the private parameters from being stolen by malicious attackers.

[0035] (III) Beneficial Effects

[0036] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0037] This invention provides a trusted cross-chain transaction privacy protection method that utilizes SGX for privacy protection processing performance. It addresses the issue of malicious attacks or leaks of private parameters generated when zk_SNARKs rely on third-party trusted setup, and comparative experiments were conducted to evaluate its efficiency. To evaluate the performance of using SGX to store keys for transaction privacy protection, test transactions were performed on 10 sidechains. An Intel SGX hardware environment was used, with an SGX Trusted Execution Environment (TEE) running on each chain's node. When an account on the main chain sends a transaction to a sidechain, a zk_SNARKs proof is generated locally and sent to the target chain's SGX TEE for verification. The target chain's SGX TEE verifies the proof's correctness and provides the transaction result back to the participant who sent the transaction. Throughout this process, detailed transaction information is protected within the SGX TEE and will not be leaked to other participants or attackers. Experimental results show that, compared with traditional transaction privacy protection, the SGX-based solution for cross-chain transaction privacy protection takes only 1.2 seconds when there are 10 sidechains, and is more secure and private than traditional cross-chain transactions. Attached Figure Description

[0038] Figure 1 This is a flowchart of a trusted cross-chain transaction privacy protection method according to the present invention;

[0039] Figure 2 This is an overall architecture diagram of a trusted cross-chain transaction privacy protection method according to the present invention. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] Example:

[0042] This invention provides a reliable method for protecting privacy in cross-chain transactions, such as... Figure 1 As shown, please follow these steps:

[0043] In step 1, create a Zendoo user and compile using zend_oo from Horizen. After successful compilation, start Zend on the specified testnet. The main chain is then successfully started. Next, compile the sidechain SDK and use the bootstrap tool to generate VRF key pairs and ed25519 key pairs to initialize the sidechain.

[0044] Step 2 is as follows:

[0045] Step 2.1 requires configuring a configuration file to start the sidechain. First, generate a Schnorr key pair for the certificate signer in the bootstrap tool, which serves as the signer key and master key. Then, use the signer certificate generated in the previous step and the Schnorr public key list to generate data for certificate creation and verification.

[0046] Step 2.2: Using the address containing the generated initial transfer amount and the VRF public key, the `sc_create` command is used to declare the sidechain on the main chain, generating a sidechain ID. Then, information is retrieved from the main chain to form the sidechain genesis block, followed by updating the sidechain configuration file. Finally, the sidechain node is started.

[0047] Step 2.3, using the zk_SNARKs algorithm to protect transaction privacy, consists of two steps: generating a proof and verifying the proof. Certificate generation and verification rely entirely on the included SNARKs proof, which is defined by the sidechain. The main chain only knows the verification key and the verification interface. If the SNARKs proof and public parameters are valid, the certificate will be included in the main chain and processed. The basic interface of SNARKs is as follows:

[0048] true / false ← Verify(vk) WCert (public_input, proof)

[0049]

[0050] vk WCert wcert is used to verify the SNARKs generated during sidechain creation. sysdata This is part of the common input. `proofdata` is a portion of the input data, defined by the sidechain and passed along the withdrawal certificate; `MH(proofdata)` is the root hash of the Merkle tree, where the leaves are variables from `proofdata`; `proof` is the SNARKs proof submitted as part of the certificate.

[0051] Generating a proof requires the following steps: (1) Select the object to be proven and represent it as an arithmetic circuit. (2) Generate constraints based on the arithmetic circuit, which must be satisfied for every input and output value on the circuit. (3) Use the R1CS constraint system to convert the constraints into a set of long vector equations. (4) Use a zero-knowledge proof compiler to further convert the equations into a computable circuit required by the zk_SNARKs algorithm. (5) Generate a proof key and use it to encrypt and protect the proof information. (6) Use the proof key to compute the circuit and generate the proof.

[0052] Step 3 is as follows:

[0053] Step 3.1: Convert the proof key generated in step 2 into an encryptable format. Since zk_SNARKs uses elliptic curve cryptography to process the key, point compression and decompression operations are required for the proof key. That is, the verification key and a portion of the proof key need to be compressed into a point G1, and the other portion of the proof key needs to be compressed into another point G2.

[0054] Step 3.2: Encrypt the proof key using the AES algorithm. Assuming CBC mode is used to encrypt the proof key, a 128-bit random key K is selected as the AES encryption key. Then, a vector IV is used to initialize the encryption algorithm to ensure that the result is different for each encryption. Assuming the points G1 and G2 of the proof key are represented as P1 and P2 respectively, they can be concatenated into a string, i.e., salt = p1||p2. Then, in CBC mode, the salt is encrypted using the random key K to obtain the encrypted result, ciphertext. Finally, the encrypted proof key is stored in SGX to ensure its security.

[0055] Step 4 is as follows:

[0056] Step 4.1: The proof is sent to the verification nodes on the sidechain, which use the zk_SNARKs algorithm to verify the validity of the proof. The verification nodes only need to check whether the hash value in the proof matches the calculation result, without needing to know the private information in the proof.

[0057] Step 4.2: Retrieve the encrypted proof key from SGX.

[0058] Step 5 is as follows:

[0059] Step 5.1: Decrypt the proof key using the AES algorithm. This requires the same key K and vector IV as in the encryption stage. The obtained proof key ciphertext is used as input, and the decryption algorithm is used to decrypt it to obtain the decrypted proof key.

[0060] Step 5.2: Concatenate the verification key and the decrypted proof key into a complete proof key. Select the statement to be verified and represent it in arithmetic circuit form, then verify that the constraint system conforms to the proof key. Compute the proof using the obtained constraint system and generate an interactive zero-knowledge proof. Verify the proof using the decrypted proof key and a common reference point. If verification is successful, the transaction can proceed.

[0061] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A reliable method for protecting privacy in cross-chain transactions, characterized in that, The specific steps are as follows: Step 1: The user creates a transaction on the main chain and sends the assets to an address on the side chain of the main chain. The transaction input is converted into a set of public parameters and private parameters. The public parameters include public information of the main chain and the side chain, and the private parameters include private information of the transaction. Step 2: Use the zk_SNARKs algorithm to generate a proof that demonstrates the validity of the transaction and protects the privacy of the transaction; the proof includes the hash values ​​of the public and private parameters, as well as a random number and the calculation result; Step 3: Encrypt the private parameters in the proof using the AES encryption algorithm and store the encrypted ciphertext in SGX; The key used in the encryption process can only be accessed within SGX, thus ensuring the security of private parameters; Step 4: The proof is sent to the verification nodes on the sidechain. The verification nodes use the zk_SNARKs algorithm to verify the validity of the proof. The verification nodes only need to check whether the hash value in the proof matches the calculation result, without needing to know the private information in the proof. Step 5: If the verification is successful, the verification node on the sidechain uses the key inside SGX to decrypt the private parameters and then proceeds with the transaction. Step 2 is implemented in the following steps: Step 2.1, provide a security parameter ,pass The algorithm generates a common parameter list. Where P is a prime number, e is a bilinear mapping, G1 is the first group used to store the field of the discrete logarithm problem; P1 is a generator in G1 used to generate elements in G1; G2 is the second group used to store the field of the discrete logarithm problem; P2 is a generator in G2 used to generate elements in G2; G T It is the target group, used to store the results of bilinear mappings; P T It is G T The generators in G are used to generate G. T Elements in; All algorithms use PP. Z As public default input parameters; public default input parameters include polynomials, public parameters of the signature proof system, public parameters of the verification proof system, and other parameters required for signature verification; Step 2.2, given circuit ,pass The algorithm utilizes the common parameter PP Z Generate key pairs (PK) Z VK Z );PK Z It is the proof key generated, VK. Z It is the verification key for proof and verification; Step 2.3, through Algorithm to generate a zero-knowledge proof ;PK Z It is the proof key; It is a public declaration that it is the input of circuit C; It is a private verification, and it is an auxiliary input of circuit C; Step 2.4: Send the public parameters to the sidechain. The private parameters are known only to the generator and are used to verify the legality and security of this cross-chain transaction.

2. The trusted cross-chain transaction privacy protection method according to claim 1, characterized in that, Step 1 is implemented in the following steps: Step 1.1: Create a user named zendoo, add it to a group called sudo and assign a password to the zendoo user, then switch to the zendoo user; Step 1.2: Start the main chain, then configure the side chain, use the bootstrapping tool to create the wallet address on the side chain, and enable the websocket for communication between the main chain and the side chain; generate 200 blocks to activate the side chain and generate the side chain identifier; configure the configuration file and start the side chain. Step 1.3: Send the transaction to the websocket used for communication between the main chain and the side chain, and then convert the websocket into a set of public and private parameters.

3. The trusted cross-chain transaction privacy protection method according to claim 1, characterized in that, Step 4 is implemented in the following steps: Step 4.1: The verification node receives the transaction proof from the sidechain, including cross-chain transaction information and proof key; Step 4.2: Before verifying the transaction proof, the verification node needs to prepare the relevant validity information and check whether the hash value and calculation result match. If the transaction proof is valid, proceed to the next step; if the transaction proof is invalid, reject the transaction.

4. The trusted cross-chain transaction privacy protection method according to claim 1, characterized in that, Step 5 is implemented in the following steps: Step 5.1: The transaction has been verified as valid, and the verification node can execute the cross-chain transaction; Step 5.2: During transaction execution, the verification node can use the key inside SGX to decrypt the private parameters and use them in the transaction process. This operation protects the private parameters from being stolen by malicious attackers.

Images