On-chain transaction privacy protection scheme based on zero knowledge proof

Abstract

The invention relates to an on-chain transaction privacy protection scheme based on zero knowledge proof. The method specifically comprises the following steps: system initialization: generating a public parameter list; creating an account of an account initialization user, wherein the account is mainly divided into setting a plaintext balance, setting a hidden balance, generating a zero-knowledge proof voucher and generating a signature; recharging and withdrawing operation: mutually converting the plaintext balance and the hidden balance of the user; the operation of sending, replacing and storing the token voucher is carried out by hiding the balance, and the transaction relation hiding is realized by matching the operation of replacing the token voucher with the zero-knowledge proof and encryption signature technology. According to the method, the transaction privacy of the transaction privacy protection scheme is enhanced, and meanwhile, the calculation cost and the time overhead are relatively low.

Description

Technical Field

[0001] The present invention relates to the field of blockchain privacy protection, and in particular to transaction privacy protection, and specifically to an on-chain transaction privacy protection scheme based on zero-knowledge proof. Background Art

[0002] The Industrial Internet has created a new manufacturing service system that is fully interconnected. Security guarantees the development of the Industrial Internet. Due to the characteristics of blockchain, the security and privacy of on-chain transactions are threatened. For industrial transaction scenarios, hundreds or thousands of transactions per second may be required, but different specific scenarios have different requirements. Time performance must be considered while achieving privacy protection. First of all, the current focus on hiding transaction relationships is based on the UTXO model, and rarely on the account model. In particular, there is a lack of hidden implementation of transaction relationships in the research on transaction privacy protection of consortium chains. There are certain differences between public chains and consortium chains, which leads to the inability of public chain solutions to be directly applied to consortium chains. Additional design and implementation are required. At the same time, for industrial transactions that are not fully open, public chain solutions cannot be directly applied. Secondly, in the current research based on the account model, there are some problems that achieve a strong degree of privacy protection but with high computational overhead, long proof generation and verification time leading to high load on-chain computing, or have certain time performance advantages but only achieve the hiding of transaction amounts, resulting in a weak degree of privacy protection. That is, in a certain concurrent traffic environment, how to achieve a strong degree of privacy protection in a non-fully open scenario while having a certain degree of high efficiency is the problem. Therefore, achieving privacy protection for blockchain transactions while taking into account low time overhead has become a key challenge in current research and practice.

[0003] At present, there are some digital currencies based on zero-knowledge proof, which ensure the confidentiality of transaction amounts and anonymity of identities to a certain extent, such as Zerocoin, Zerocash, Quisquis, etc. They are designed for public blockchain systems and built on the UTXO model. However, they have certain challenges in the application of smart contracts, because these applications are usually more complex and require more storage and computing resources. At the same time, due to certain differences between public chains and consortium chains, these solutions based on the UTXO model cannot be directly applied to consortium chains. Some solutions based on the account model, such as Guan et al. proposed a privacy-preserving account model blockchain solution for Ethereum called BlockMaze, which uses zk-SNARK technology to hide transaction funds and transaction addresses, but the model has a high computational cost, resulting in low transaction efficiency, especially the tree structure used to hide transaction relationships stored in the transaction records, which further leads to poor time performance; Chen et al. used an additive homomorphic encryption scheme and a non-interactive zero-knowledge proof system to form a general structure based on the account model, and constructed an independent cryptocurrency structure. The key reuse strategy simplifies the system design to achieve lightweight encryption, thereby reducing time overhead, but The problem is the lack of privacy protection for the relationship between the two parties in the transaction; Ma et al. proposed an abstract framework for a decentralized smart contract system, using homomorphic encryption and non-interactive zero-knowledge proof to ensure the validity of the transaction. The researchers only achieved amount hiding, which has advantages in time performance overhead but weak privacy protection, and did not consider transaction relationship hiding; Hu et al. proposed a verifiable and privacy-protected account model based on a consortium chain called VmppToken, which uses zkSNRAK to achieve efficient time performance and greatly reduces time overhead, but the disadvantage is that its trusted setting overhead is large, and the lack of hiding the transaction relationship results in a small privacy protection range. Compared with the UTXO model, which can generate multiple random addresses, the account model is more challenging in achieving transaction relationship hiding because the user identity is bound to an account address. Summary of the invention

[0004] The purpose of the present invention is to propose an on-chain transaction privacy protection solution based on zero-knowledge proof to achieve blockchain transaction privacy protection while taking into account low time overhead.

[0005] The object of the present invention is achieved in this way:

[0006] The present invention designs an improved account model, including a plain text balance and a hidden balance. In the transaction preparation stage, the two balances can be converted to each other, and the hidden balance is used in the subsequent formal transaction stage. The transaction is divided into a transaction preparation stage and a formal transaction stage. The zero-knowledge proof technology used in the transaction preparation stage is used to reduce the time performance overhead by taking up less memory and verifying faster. In the formal transaction stage, the time overhead is reduced by reducing the data stored in the transaction record. The calculation of each stage is placed off-chain, and only verification is performed on the chain to further accelerate the transaction processing. The present invention defines a data structure called a token certificate and proposes a token certificate replacement method based on non-interactive zero-knowledge proof for hiding the relationship between the two parties in the transaction. The present invention designs and plans the algorithms for each process step.

[0007] The specific method is as follows:

[0008] A privacy protection scheme for on-chain transactions based on zero-knowledge proof includes the following steps:

[0009] Step 1: Transaction preparation stage: The system initialization operation is performed by the management node to generate a public parameter list, which is mainly divided into two parts, including initializing the zkSNARK protocol and initializing the ISES and sigma protocols. The parameters required for the zkSNARK protocol are initialized through the trusted settings of the management node, and the parameters required for encryption, signature, and zero-knowledge proof protocols are initialized using cryptographic tools;

[0010] Step 2: Create an account in the transaction preparation stage. The system initializes the user's account, which is mainly divided into setting the plain text balance, setting the hidden balance, generating zero-knowledge proof vouchers, and generating signatures;

[0011] Step 3, recharge and withdrawal operations in the transaction preparation stage, where the recharge operation is that the user converts part of his plaintext balance into a hidden balance for the subsequent sending of token certificates or replacement of token certificates or deposit of token certificates. It is mainly divided into calculating a new double balance, generating a zero-knowledge proof certificate of a new hidden balance, and generating a corresponding signature. The withdrawal operation is that the user converts part of his hidden balance into a plaintext balance. The logic is similar to the above-mentioned recharge operation. It is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification. The recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to a plaintext balance. The user converts part of his hidden balance into a plaintext balance. The logic is similar to the above-mentioned recharge operation. It is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification. The recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to a plaintext balance.

[0012] Step 4: Send the token certificate operation in the formal transaction stage. In this scheme, the sender is defined as S and the receiver is defined as R. K represents the range proof, which is used to transfer the amount v that the sender S wants to transfer from its hidden balance to the receiver's token certificate.

[0013] Step 5: The token voucher replacement operation in the formal transaction phase is that the receiver R obtains the token voucher transaction record of the sender S, parses the secret value and transfer ciphertext used by S to encrypt the token voucher, and decrypts the secret value and transfer amount. At this point, for the receiver R, the amount that S wants to transfer to himself is known, but how to hide the relationship of how S sends it to himself through the operation. This solution adopts the form of constructing a token voucher box of size N and constructing a new token voucher of the same value by oneself, and proves that the new token voucher is taken out of the token voucher box through zero-knowledge proof;

[0014] Step 6: In the formal transaction phase, the token voucher deposit operation is that the receiver R deposits the transfer amount of the sender S into his own hidden balance through the token voucher deposit algorithm, using the new token voucher generated by the replacement. One point that needs to be emphasized is that the token voucher replacement operation of this scheme must be performed before the token voucher is deposited. That is to say, for the receiver R, replacement must be performed before deposit. The generated zero-knowledge proof is used to prove that the difference between the receiver R's hidden balance before and after the deposit is the value of the token voucher, and the logic is similar to sending the token voucher.

[0015] Furthermore, the core content of the first part of the initialization operation in step 1 to initialize the zkSNARK protocol is as follows:

[0016] pp Z ←Setup(1 λ )

[0017]

[0018] First, the parameter pp required by the zkSNARK protocol is generated according to the security parameter λ Z , construct the arithmetic circuit Cir for creating accounts, recharging, and withdrawing cash i , via Cir i and pp Z Generate the corresponding key pair for zero-knowledge proof credential generation and verification, and finally generate the transaction preparation key set PK Z and VK Z In the subsequent transaction preparation phase algorithm, the key for generating zero-knowledge proof credentials is uniformly represented as PK Z , the verification key is uniformly represented as VK Z , where PK Z VK is a secret parameter built into each algorithm. ZIt is published in the ledger. If Cir i If it does not change, the algorithm only needs to be executed once, that is, PK Z and VK Z Reusable.

[0019] Furthermore, the core contents of the second part of the initialization operation in step 1, initializing ISES and sigma protocols, are as follows:

[0020]

[0021] pp: =(pp Z ,PK Z ,VK Z ,pp ISES ,pp NIZK )

[0022] Use tools from public cryptographic libraries such as OpenSSL to generate the parameters pp required for the ISES and zero-knowledge proof sigma protocols ISES ,pp NIZK Finally, the public parameter set pp in this scheme is output. It is stored in the system for subsequent transactions, updated on the chain through the alliance chain code, and used for subsequent verification of various types of transactions.

[0023] Furthermore, the core contents of setting the plain text balance PTbal=init_v and setting the hidden balance in step 2 are as follows:

[0024]

[0025] C v ←ISES.E(pk,init_v ZK ,r)

[0026] ZKbal:=(C v ,pk,sn,init_v ZK ,r),sn∈{0,1} n

[0027] The content of the generated zero-knowledge proof certificate is as follows:

[0028]

[0029] Generate signature σ←ISES.S(sk,{pk,PTbal,sn,C v ,proof Create}) and generate transaction records for verification.

[0030] Furthermore, the core content of calculating the new plaintext balance and hidden balance in step 3 is as follows:

[0031] PTbal*=PTbal-v R echarge

[0032]

[0033] The core content of the zero-knowledge proof for generating a new hidden balance is as follows:

[0034]

[0035] Generate signature And generate transaction records for verification. The withdrawal operation is the opposite of the recharge operation.

[0036] Furthermore, in step 4, the sender S constructs the token certificate Token of the receiver R R , first calculate the new hidden balance of S as follows:

[0037]

[0038] The token certificate ciphertext for calculating R is as follows:

[0039] T R ←ISES.E(pk R ,v,r Token_from_S )

[0040]

[0041] A R ←ElGamal.Enc(pk R ,{r Token_from_S ,v})

[0042] Token R :=(T R ,pk R ,v,r Token_from_s )

[0043] Generate a zero-knowledge proof to ensure that S's hidden balance value is equal before and after the transfer. The content is as follows:

[0044]

[0045] p2=NIZK{(r Token_from_S ,v)|T R =ISES.E(pk R ,v,r Token_from_S )∧v∈K}

[0046]

[0047] Then generate S's signature:

[0048]

[0049] And generate transaction records for verification. It should be noted that first, the sender S calculates the secret value r of the token certificate of R Token_from_S , use R's public key to encrypt and generate A R And add it to the transaction record. Later, R obtains the transaction record and decrypts it with his own private key to obtain the Token R The specific values ​​behind v and r Token_from_S . Through these two values, the replacement operation can be performed. Secondly, zero-knowledge proof SendToken Composed of three proofs, p1, p2, and p3 can be transformed into the following contents respectively:

[0050]

[0051] Among them, p1 means proving that the hidden balance ciphertext calculation after S sends the token certificate is correct, p2 means proving that the ciphertext value of R's token certificate is calculated correctly, and p3 means proving that the difference between the hidden balance before and after S sends R's token certificate is the plaintext value of R's token certificate.

[0052] Furthermore, in step 5, the receiver R calculates the content of the credential used to replace the new token as follows:

[0053]

[0054] The core content of the R token voucher box is as follows:

[0055]

[0056] label=SHA256(r)

[0057] The core content of generating zero-knowledge proof is as follows:

[0058]

[0059] proof R eplace T oken←NIZK{(r,r*,v)|p4∧p5}

[0060] RGenerate a signature And generate transaction records for verification. It is necessary to explain that the zero-knowledge proof constructed by R needs to prove that R has a token voucher in the voucher box, which is achieved by constructing a new token voucher. To prove that the amount behind the new voucher is equal to that behind the old voucher, the ciphertext of the corresponding plaintext value addition or subtraction can be obtained by calculating the ciphertext operation, which can be simply expressed as follows:

[0061] C1=ISES.E(pk,v1,r1)

[0062] C2=ISES.E(pk,v2,r2)

[0063] C1*C2=C + =ISES.E(pk,v1+v2,r1+r2)

[0064] C1 / C2=C - =ISES.E(pk,v1-v2,r1-r2)

[0065] When the old credential ciphertext and the new credential ciphertext meet When , it means that the amount behind the new and old vouchers is equal. N-1 The encrypted ciphertext proof that one of them is 0 is as follows:

[0066] proof 1-out-of-N ={(α,r)|C0,...,C N-1 ∈β∧α∈[0,N-1]∧C α =g r h 0}

[0067] Where β is the encrypted commitment space. p5 can be transformed into the following and split into.

[0068] and

[0069]

[0070]

[0071] Among them, p5 indicates that the amount behind the new token certificate used for replacement is equal to the amount of the old token certificate to be replaced. For the old token certificate, it is mainly realized by the unique label number of the label, which will be verified in the verification algorithm.

[0072] The positive effects of the present invention are:

[0073] The present invention enhances the privacy of transactions through the designed improved account model, designed token credential data structure and proposed token credential replacement method, combined with the advantages of off-chain computing, on-chain verification and zero-knowledge proof technology, while having lower computing cost and time overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0074] Figure 1 This is the architecture diagram of the on-chain transaction privacy protection solution based on zero-knowledge proof.

[0075] Figure 2 This is a flow chart of the on-chain transaction privacy protection solution based on zero-knowledge proof. DETAILED DESCRIPTION

[0076] The specific implementation modes of the present invention are further described in detail below with reference to the accompanying drawings.

[0077] like Figure 1 As shown in the figure, the present invention divides the transaction into two stages: transaction preparation and transaction formalization. The calculation is placed off-chain, and only verification is done on-chain. The zero-knowledge proof in the preparation stage is implemented based on zkSNARK, and the zero-knowledge proof in the formal stage is constructed based on the non-interactive sigma protocol. The participating entities include management nodes, verification nodes, transaction parties, and the alliance chain network.

[0078] like Figure 2 As shown, the process steps of the present invention are mainly divided into initializing the system, creating accounts for both parties to the transaction, the sender recharging the account to hide the balance, the sender sending the token certificate, the receiver replacing the token certificate, and the receiver depositing the token certificate. The specific process steps are as follows:

[0079] Step 1: Transaction preparation stage: The system initialization operation is performed by the management node to generate a public parameter list, which is mainly divided into two parts, including initializing the zkSNARK protocol and initializing the ISES and sigma protocols. The parameters required for the zkSNARK protocol are initialized through the trusted settings of the management node, and the parameters required for encryption, signature, and zero-knowledge proof protocols are initialized using cryptographic tools;

[0080] Step 2: Create an account in the transaction preparation stage. The system initializes the user's account, which is mainly divided into setting the plain text balance, setting the hidden balance, generating zero-knowledge proof vouchers, and generating signatures;

[0081] Step 3, recharge and withdrawal operations in the transaction preparation stage, where the recharge operation is that the user converts part of his plaintext balance into a hidden balance for the subsequent sending of token certificates or replacement of token certificates or deposit of token certificates. It is mainly divided into calculating a new double balance, generating a zero-knowledge proof certificate of a new hidden balance, and generating a corresponding signature. The withdrawal operation is that the user converts part of his hidden balance into a plaintext balance. The logic is similar to the above-mentioned recharge operation. It is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification. The recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to a plaintext balance. The user converts part of his hidden balance into a plaintext balance. The logic is similar to the above-mentioned recharge operation. It is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification. The recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to a plaintext balance.

[0082] Step 4: Send the token certificate operation in the formal transaction stage. In this scheme, the sender is defined as S and the receiver is defined as R. K represents the range proof, which is used to transfer the amount v that the sender S wants to transfer from its hidden balance to the receiver's token certificate.

[0083] Step 5: The token voucher replacement operation in the formal transaction phase is that the receiver R obtains the token voucher transaction record of the sender S, parses the secret value and transfer ciphertext used by S to encrypt the token voucher, and decrypts the secret value and transfer amount. At this point, for the receiver R, the amount that S wants to transfer to himself is known, but how to hide the relationship of how S sends it to himself through the operation. This solution adopts the form of constructing a token voucher box of size N and constructing a new token voucher of the same value by oneself, and proves that the new token voucher is taken out of the token voucher box through zero-knowledge proof;

[0084] Step 6: In the formal transaction phase, the token voucher deposit operation is that the receiver R deposits the transfer amount of the sender S into his own hidden balance through the token voucher deposit algorithm, using the new token voucher generated by the replacement. One point that needs to be emphasized is that the token voucher replacement operation of this scheme must be performed before the token voucher is deposited. That is to say, for the receiver R, replacement must be performed before deposit. The generated zero-knowledge proof is used to prove that the difference between the receiver R's hidden balance before and after the deposit is the value of the token voucher, and the logic is similar to sending the token voucher.

[0085] Furthermore, the core content of the first part of the initialization operation in step 1 to initialize the zkSNARK protocol is as follows:

[0086] pp Z ←Setup(1λ )

[0087]

[0088]

[0089] First, the parameter pp required by the zkSNARK protocol is generated according to the security parameter λ Z , construct the arithmetic circuit Cir for creating accounts, recharging, and withdrawing cash i , via Cir i and pp Z Generate the corresponding key pair for zero-knowledge proof credential generation and verification, and finally generate the transaction preparation key set PK Z and VK Z In the subsequent transaction preparation phase algorithm, the key for generating zero-knowledge proof credentials is uniformly represented as PK Z , the verification key is uniformly represented as VK Z , where PK Z VK is a secret parameter built into each algorithm. Z It is published in the ledger. If Cir i If it does not change, the algorithm only needs to be executed once, that is, PK Z and VK Z Reusable.

[0090] Furthermore, the core contents of the second part of the initialization operation in step 1, initializing ISES and sigma protocols, are as follows:

[0091]

[0092] pp: =(pp Z ,PK Z ,VK Z ,pp ISES ,pp NIZK )

[0093] Use tools from public cryptographic libraries such as OpenSSL to generate the parameters pp required for the ISES and zero-knowledge proof sigma protocols ISES ,pp NIZK Finally, the public parameter set pp in this scheme is output. It is stored in the system for subsequent transactions, updated on the chain through the alliance chain code, and used for subsequent verification of various types of transactions.

[0094] Furthermore, the core contents of setting the plain text balance PTbal=init_v and setting the hidden balance in step 2 are as follows:

[0095]

[0096] Cv ←ISES.E(pk,init_v ZK ,r)

[0097] ZKbal:=(C v ,pk,sn,init_v ZK ,r),sn∈{0,1} n

[0098] The content of the generated zero-knowledge proof certificate is as follows:

[0099]

[0100] Generate signature σ←ISES.S(sk,{pk,PTbal,sn,C v ,proof Create}) and generate transaction records for verification.

[0101] Furthermore, the core content of calculating the new plaintext balance and hidden balance in step 3 is as follows:

[0102] PTbal*=PTbal-v R echarge

[0103]

[0104]

[0105] The core content of the zero-knowledge proof for generating a new hidden balance is as follows:

[0106]

[0107] Generate signature And generate transaction records for verification. The withdrawal operation is the opposite of the recharge operation.

[0108] Furthermore, in step 4, the sender S constructs the token certificate Token of the receiver R R , first calculate the new hidden balance of S as follows:

[0109]

[0110] The token certificate ciphertext for calculating R is as follows:

[0111] T R ←ISES.E(pk R ,v,r Token_from_S )

[0112]

[0113] A R←ElGamal.Enc(pk R ,{r Token_from_S ,v})

[0114] Token R :=(T R ,pk R ,v,r Token_from_s )

[0115] Generate a zero-knowledge proof to ensure that S's hidden balance value is equal before and after the transfer. The content is as follows:

[0116]

[0117] p2=NIZK{(r Token_from_S ,v)|T R =ISES.E(pk R ,v,r Token_from_S )∧v∈K}

[0118]

[0119] Then generate S's signature:

[0120]

[0121] And generate transaction records for verification. It should be noted that first, the sender S calculates the secret value r of the token certificate of R Token_from_S , use R's public key to encrypt and generate A R And add it to the transaction record. Later, R obtains the transaction record and decrypts it with his own private key to obtain the Token R The specific values ​​behind v and r Token_from_S . Through these two values, the replacement operation can be performed. Secondly, zero-knowledge proof SendToken Composed of three proofs, p1, p2, and p3 can be transformed into the following contents respectively:

[0122]

[0123] Among them, p1 means proving that the hidden balance ciphertext calculation after S sends the token certificate is correct, p2 means proving that the ciphertext value of R's token certificate is calculated correctly, and p3 means proving that the difference between the hidden balance before and after S sends R's token certificate is the plaintext value of R's token certificate.

[0124] Furthermore, in step 5, the receiver R calculates the content of the credential used to replace the new token as follows:

[0125]

[0126] The core content of the R token voucher box is as follows:

[0127]

[0128] label=SHA256(r)

[0129] The core content of generating zero-knowledge proof is as follows:

[0130]

[0131]

[0132] proof R eplace T oken←NIZK{(r,r * ,v)|p4∧p5}

[0133] RGenerate a signature And generate transaction records for verification. It is necessary to explain that the zero-knowledge proof constructed by R needs to prove that R has a token voucher in the voucher box, which is achieved by constructing a new token voucher. To prove that the amount behind the new voucher is equal to that behind the old voucher, the ciphertext of the corresponding plaintext value addition or subtraction can be obtained by calculating the ciphertext operation, which can be simply expressed as follows:

[0134] C1=ISES.E(pk,v1,r1)

[0135] C2=ISES.E(pk,v2,r2)

[0136] C1*C2=C + =ISES.E(pk,v1+v2,r1+r2)

[0137] C1 / C2=C - =ISES.E(pk,v1-v2,r1-r2)

[0138] When the old credential ciphertext and the new credential ciphertext meet When , it means that the amount behind the new and old vouchers is equal. N-1 The encrypted ciphertext proof that one of them is 0 is as follows:

[0139] proof 1-out-of-N ={(α,r)|C0,...,C N-1 ∈β∧α∈[0,N-1]∧C α =g r h 0}

[0140] Where β is the encrypted commitment space. p5 can be transformed into the following and split into. and

[0141]

[0142] Among them, p5 indicates that the amount behind the new token certificate used for replacement is equal to the amount of the old token certificate to be replaced. For the old token certificate, it is mainly realized by the unique label number of the label, which will be verified in the verification algorithm.

Claims

1. A privacy protection scheme for on-chain transactions based on zero-knowledge proof, characterized in that: The method comprises the following steps: Step 1: Transaction preparation stage: The system initialization operation is performed by the management node to generate a public parameter list, which is mainly divided into two parts, including initializing the zkSNARK protocol and initializing the ISES and sigma protocols. The parameters required for the zkSNARK protocol are initialized through the trusted settings of the management node, and the parameters required for encryption, signature, and zero-knowledge proof protocols are initialized using cryptographic tools; Step 2: Create an account in the transaction preparation stage. The system initializes the user's account, which is mainly divided into setting the plain text balance, setting the hidden balance, generating zero-knowledge proof vouchers, and generating signatures; Step 3, recharge and withdrawal operations in the transaction preparation stage, where the recharge operation is that the user converts part of his plaintext balance into a hidden balance for subsequent sending of token certificates or replacing token certificates or depositing token certificates, which is mainly divided into calculating a new double balance, generating a zero-knowledge proof certificate of a new hidden balance, and generating a corresponding signature. The withdrawal operation is that the user converts part of his hidden balance into a plaintext balance, and the logic is similar to the above-mentioned recharge operation, which is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification; the recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to the plaintext balance. The user converts part of his hidden balance into a plaintext balance, and the logic is similar to the above-mentioned recharge operation, which is also divided into calculating a new double balance, generating a zero-knowledge proof of a new hidden balance, and generating a corresponding signature, thereby generating a withdrawal transaction record for verification; the recharge operation is to convert the plaintext balance into a hidden balance, while the withdrawal operation is to convert the hidden balance back to the plaintext balance; Step 4: Send the token certificate operation in the formal transaction stage. In this scheme, the sender is defined as S and the receiver is defined as R. K represents the range proof, which is used to transfer the amount v that the sender S wants to transfer from its hidden balance to the receiver's token certificate. Step 5: The token voucher replacement operation in the formal transaction phase is that the receiver R obtains the token voucher transaction record of the sender S, parses the secret value and transfer ciphertext used by S to encrypt the token voucher, and decrypts the secret value and transfer amount. At this point, for the receiver R, the amount that S wants to transfer to himself is known, but how to hide the relationship of how S sends it to himself through the operation. This solution adopts the form of constructing a token voucher box of size N and constructing a new token voucher of the same value by oneself, and proves that the new token voucher is taken out of the token voucher box through zero-knowledge proof; Step 6: In the formal transaction phase, the token voucher deposit operation is that the receiver R deposits the transfer amount of the sender S into his own hidden balance through the token voucher deposit algorithm, using the new token voucher generated by the replacement. One point that needs to be emphasized is that the token voucher replacement operation of this scheme must be performed before the token voucher is deposited. That is to say, for the receiver R, replacement must be performed before deposit. The generated zero-knowledge proof is used to prove that the difference between the receiver R's hidden balance before and after the deposit is the value of the token voucher, and the logic is similar to sending the token voucher.

2. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: The core content of the first part of the initialization operation in step 1 to initialize the zkSNARK protocol is as follows: pp Z ←Setup(1 λ ) First, the parameter pp required by the zkSNARK protocol is generated according to the security parameter λ Z , construct the arithmetic circuit Cir for creating accounts, recharging, and withdrawing cash i , via Cir i and pp Z Generate the corresponding key pair for zero-knowledge proof credential generation and verification, and finally generate the transaction preparation key set PK Z and VK Z In the subsequent transaction preparation phase algorithm, the key for generating zero-knowledge proof credentials is uniformly represented as PK Z , the verification key is uniformly represented as VK Z , where PK Z VK is a secret parameter built into each algorithm. Z It is published in the ledger. If Cir i If it does not change, the algorithm only needs to be executed once, that is, PK Z and VK Z Reusable.

3. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: The core contents of the second part of the initialization operation in step 1, initializing ISES and sigma protocols, are as follows: pp:=(pp Z ,PK Z ,VK Z ,pp ISES ,pp NIZK ) Use tools from public cryptographic libraries such as OpenSSL to generate the parameters pp required for the ISES and zero-knowledge proof sigma protocols ISES ,pp NIZK ; Finally, all the public parameter sets pp in this scheme are output; stored in the system for subsequent transactions, updated on the chain through the alliance chain chain code, and used for subsequent verification of various types of transactions.

4. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: The core contents of setting the plain text balance PTbal=init_v and setting the hidden balance in step 2 are as follows: C v ←ISES.E(pk,init_v ZK ,r) ZKbal:=(C v ,pk,sn,init_v ZK ,r),sn∈{0,1} n The content of the generated zero-knowledge proof certificate is as follows: Generate signature σ←ISES.S(sk,{pk,PTbal,sn,C v ,proof Create }) and generate transaction records for verification.

5. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: The core content of calculating the new plaintext balance and hidden balance in step 3 is as follows: PTbal*=PTbal-v R echarge The core content of the zero-knowledge proof for generating a new hidden balance is as follows: Generate signature And generate transaction records for verification. The withdrawal operation is the opposite of the recharge operation.

6. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: In step 4, the sender S constructs the token certificate Token of the receiver R R , first calculate the new hidden balance of S as follows: The token certificate ciphertext for calculating R is as follows: T R ←ISES.E(pk R ,v,r T oken_from_ S ) A R ←ElGamal.Enc(pk R ,{r T oken_from_ S ,v}) Token R :=(T R ,pk R ,v,r T oken_from_s) Generate a zero-knowledge proof to ensure that S's hidden balance value is equal before and after the transfer. The content is as follows: p2=NIZK{(r Token_from_S ,v)|T R =ISES.E(pk R ,v,r Token_from _ S )∧v∈K} Then generate S's signature: And generate transaction records for verification. It should be noted that first, the sender S calculates the secret value r of the token certificate of R Token_from_S , use R's public key to encrypt and generate A R And add it to the transaction record. Later, R obtains the transaction record and decrypts it with his own private key to obtain the Token R The specific values ​​behind v and r Token_from_S ; Through these two values, the replacement operation can be performed; secondly, zero-knowledge proof SendToken Composed of three proofs, p1, p2, and p3 can be transformed into the following contents respectively: Among them, p1 means proving that the hidden balance ciphertext calculation after S sends the token certificate is correct, p2 means proving that the ciphertext value of R's token certificate is calculated correctly, and p3 means proving that the difference between the hidden balance before and after S sends R's token certificate is the plaintext value of R's token certificate.

7. According to the on-chain transaction privacy protection scheme based on zero-knowledge proof as described in claim 1, it is characterized in that: In step 5, the receiver R calculates the content of the new token certificate to replace it as follows: The core content of the R token voucher box is as follows: label=SHA256(r) The core content of generating zero-knowledge proof is as follows: proof R eplace T oken←NIZK{(r,r*,v)|p4∧p5} RGenerate a signature And generate transaction records for verification. It should be noted that the zero-knowledge proof constructed by R needs to prove that R has a token voucher in the voucher box, which is achieved by constructing a new token voucher. To prove that the amount behind the new voucher is equal to that behind the old voucher, the ciphertext of the corresponding plaintext value addition or subtraction can be obtained by calculating the ciphertext, which can be simply expressed as follows: C1=ISES.E(pk,v1,r1) C2=ISES.E(pk,v2,r2) C1*C2=C + =ISES.E(pk,v1+v2,r1+r2) C1 / C2=C-=ISES.E(pk,v1-v2,r1-r2) When the old credential ciphertext and the new credential ciphertext meet When the amount behind the new and old vouchers is equal, the sigma protocol is used to construct N ciphertexts {C0,...,C N-1 The encrypted ciphertext proof that one of them is 0 is as follows: proof 1-out-of-N ={(α,r)|C0,...,C N-1 ∈β∧α∈[0,N-1]∧C α =g r h 0 } Where β is the encrypted commitment space; p5 can be converted into the following content and split into; and Among them, p5 indicates that the amount behind the new token certificate used for replacement is equal to the amount of the old token certificate to be replaced. For the old token certificate, it is mainly realized by the unique label number of the label, which will be verified in the verification algorithm.

Images