CN115564434A - A zero-knowledge proof-based privacy protection method for blockchain supervision - Google Patents

Abstract

The invention discloses a block chain supervision privacy protection method based on zero knowledge certification, which comprises the steps of initializing the key generation of a supervisor by a system and establishing a user transaction address; a user applies for a resource access authorization certificate to a supervision authority by using own identity information; transaction sending and transaction receiving; the miners verify whether the transaction is legal or not, and if not, the transaction is directly discarded and ended; the supervisor judges whether the identity of the user needs to be tracked or not, and if not, the process is finished directly; and the supervisor decrypts the tracing data by using the own encrypted private key, cancels the anonymity of the transaction and realizes identity tracing by combining the identity tracing list IDList. The invention takes zkSNARK technology as a construction foundation, utilizes a cryptology commitment mechanism to hide account balance and transaction amount, realizes dynamic increase and cancellation of user identity by uniformly maintaining identity authorization Mercury tree by a supervisor, and realizes anonymous authentication and transaction supervision of user identity by fusing zkSNARK technology.

Description

A zero-knowledge proof-based method for blockchain regulated privacy protection

technical field

The invention relates to the technical field of block chains, in particular to a zero-knowledge proof-based block chain supervision privacy protection method.

Background technique

Blockchain technology is considered to be the fifth subversive computing paradigm after mainframe computers, personal computers, the Internet, and mobile social networking, and the fourth milestone in the history of human credit evolution after blood relative credit, precious metal credit, and central bank banknote credit. Therefore, governments of various countries have successively issued relevant policy documents, increased the strategic layout of the blockchain industry, and actively embraced blockchain technology in order to seize the dominance of the new generation of information technology. According to statistics, from 2019 to 2020, 24 countries around the world have issued special policies or laws and regulations specifically aimed at the development of the blockchain industry and industry supervision.

Regulatory privacy protection on the blockchain is of great significance for blockchain transactions. Existing blockchain-based transaction solutions generally have the following problems: they mainly focus on the fairness of transactions and the realization of data privacy, without considering the data market regulability. Supervisability is critical to a decentralized, anonymous transaction system, and the lack of it may inadvertently provide a natural barrier to criminals. If there is no effective access control mechanism and regulatory traceability mechanism, coupled with the anonymous nature of privacy protection applications, it will make it difficult to obtain evidence of crimes and identity tracking, resulting in frequent occurrence of various security incidents. Therefore, if the privacy of the original blockchain is not improved, data leakage in certain fields may not only limit the development of blockchain technology, but may even cause irreparable losses. At present, the solution based on the account model that takes into account both privacy and supervision is still in its infancy, and the existing methods are immature and incomplete. Currently, there are the following related research programs:

1) Using the integrated encrypted signature scheme and zero-knowledge proof technology to provide audit services for private transactions, but lack of consideration for the revocation of anonymous identity of suspicious private transactions, resulting in difficulty in traceability of the scheme.

2) By introducing two entities, Identity Providers and Anonymity Revokers, the transaction process can be supervised, but the privacy service provided by this scheme still has defects, that is, in this scheme, if the user uses If the same account conducts multiple transactions, then the link relationship between the two parties can be mined.

To sum up, the current account model that considers both privacy and regulatory solutions is still in its infancy, and none of them can perfectly solve the above problems. While monitoring, its privacy is flawed.

Contents of the invention

Aiming at the above-mentioned deficiencies in the prior art, the present invention provides a zero-knowledge proof-based blockchain-supervisable privacy protection method.

In order to achieve the above-mentioned purpose of the invention, the technical scheme adopted in the present invention is:

A zero-knowledge proof-based privacy protection method for blockchain supervision, comprising the following steps:

S1. Initialize the blockchain system and obtain the public parameters of the blockchain system, wherein the blockchain system includes a transaction party and a supervisor;

S2. The supervisor generates the supervisor key and creates the user address of the transaction party, and the transaction party applies to the supervisor for a resource access authorization certificate based on its own identity information and initiates a transaction;

S3. The miners verify the legitimacy of the initiated transaction. If it is not legal, discard the transaction and end it. If it is legal, go to step S4;

S4. The regulator determines whether to track the user identities of both parties to the transaction. If not, the process ends, and if the process is tracked, enter step S5;

S5. The regulator uses the encrypted private key to decrypt the traceability number and revoke the anonymity of the transaction, and completes the identity tracking of both parties according to the transaction party identity traceability list.

Further, the generation system parameters in S1 include the proof key and verification key used to generate the zkSNARK proof, as well as the public parameters of the encryption and signature algorithms, and the specific calculation process is:

Input algorithm security parameter λ, transaction sending constraint circuit C _send and transaction receiving constraint circuit C _rcv to generate system parameter pp:=(pp _enc , pp _sig , pk _send , pk _rcv , vk _send , vk _rcv ), where (pk _send , vk _send ) generates/verifies the key pair for the zero-knowledge proof of the transaction sending circuit, (pk _rcv , vk _rcv ) generates/verifies the key pair for the zero-knowledge proof of the transaction receiving circuit, pp _enc is the public parameter of the encryption algorithm, and pp _sig is Signature algorithm public parameters.

Further, in the S2, the specific method for generating the key of the supervisor and creating the user address of the transaction party at the supervisor is as follows:

S201. Calculate the encryption key and signature key of the supervisor, and the calculation method is:

(pk _{enc, s} , sk _{enc, s} ):=K _enc (pp _enc )

(pk _{sig, s} , sk _{sig, s} ): = K _sig (pp _sig )

Among them, (pk _{enc, s} , sk _{enc, s} ) is an encryption key pair, (pk _{sig, s} , sk _{sig, s} ) is a signature key pair

S202. Calculate the communication key pair according to the encryption key and signature key calculated in S201, and the calculation method is:

(pk _enc , sk _enc ):=K _enc (pp _enc )

Among them, K _enc (pp _enc ) is a communication key pair;

S203. Select a random number as the address private key and select a random number, and calculate the address public key according to the address private key and the random number. The calculation method is:

a _pk := PRF( _ask , r)

Among them, _{ask is the private key of the address, r is a random number, and a pk is} the public key of the address;

S204. Calculate the user's transaction address according to the address public key, and the calculation method is:

addr:=CRH(a _pk )

Among them, CRH( ) is a collision-resistant hash function.

Further, the specific method for the transaction party in S2 to apply for a resource access authorization certificate from the supervisory party according to its own identity information is as follows:

S211, the user side sends the address public key, zero-knowledge proof and its own identity information to the regulator

S212. The regulator verifies the validity of the user's identity, and if valid, stores the address public key and the user's identity information in the identity traceability list;

S213. For users whose identity verification is valid, the regulator calculates the supervisory auxiliary information and user authorization certificate, and the calculation method is:

C _aux :=ε _enc (pk _{enc, s} , a _pk )

Item _auth :＝CRH(a _pk ||C _aux )

Among them, C _aux is the regulatory auxiliary information, CRH( ) is the anti-collision hash function, and Item _aut is the user authorization certificate;

S214. The regulatory party reorganizes the identity authorization Merkle tree, updates the user authorization certificate to the identity authorization Merkle tree, and broadcasts the new identity authorization Merkle tree to the blockchain network.

Further, the transaction initiation in S2 includes transaction sending and transaction receiving, wherein,

The specific method of transaction sending is: the user side generates zkSNARK zero-knowledge proof during the execution of the transaction sending process, and uses the transaction sending constraint circuit to constrain the transaction process;

The specific method of transaction reception is: after the transaction is completed, the transaction commitment is added to the transaction commitment Merkle tree of the latest block. When the transaction receiver receives the transaction, it proves that the transaction receiver knows the trapdoor of the transaction commitment in the block and proves that the transaction The existence of promises.

Further, verifying the legitimacy of the transaction initiated in S3 includes verifying the legitimacy of transaction sending and transaction receiving, wherein, if the transaction type is transaction sending, the verification method is:

S301, record tx _send :=(addr _A , C _{s are} , π _send , x, σ _{m, A} , pk _{sig, A} ),

Among them: addr _A is the transaction address of the transaction sender, C _{s are} is the asset receiving trapdoor shared by the transaction sender and the transaction receiver, π _send is a zero-knowledge proof for transaction sending, and the message m _A : =(x, π _send , pk _{sig, A} , C _{s are} )σ _{m, A} is the signature for message m _A , pk _{sig, A} is the signature key of the transaction sender;

为交易前交易发送方的账户余额承诺、

为交易后交易发送方的账户余额承诺、Item_aut，A为交易发送方用户授权证书、a_pk，A为交易发送方公钥地址，

交易发送方交易序列号、C_aux，A为监管方对交易发送方的地址公钥的加密结果、h_sig，A为交易发送方签名秘钥的哈希、h_A为h_sig，A和交易发送方地址私钥a_sk，A的伪随机计算结果、；rt _aut is the root node of the identity authorization Merkle tree, cm _tx is the transaction commitment,

is the account balance commitment of the transaction sender before the transaction,

is the account balance commitment of the transaction sender after the transaction, Item _{aut, A} is the user authorization certificate of the transaction sender, a _{pk, A} is the public key address of the transaction sender,

The transaction sequence number of the transaction sender, C _{aux, A} is the encryption result of the address public key of the transaction sender by the regulator, h _{sig, A} is the hash of the signature key of the transaction sender, h _A is h _{sig, A} and the transaction The sender address private key a _{sk, the pseudo-random calculation result of A} ;

若不是则验证失败，输出验证结果res＝0；S302. According to the user address of the transaction sender, verify whether the balance commitment of the account is

If not, the verification fails, and the verification result res=0 is output;

S303. Verify whether the transaction serial number of the transaction sender appears in the public serial number set, if so, the verification fails, and the verification result res=0 is output;

S304. Verify whether rt _auth is the root of the latest identity authorization Merkle tree, if not, the verification fails, and the output verification result res=0 is output.

Further, if the transaction type is transaction received, the verification method is:

S311, record tx _send :=(addr _B , x, π _rcv , σ _{m, B} , pk _{sig, B} ),

Among them: addr _B is the transaction address of the transaction recipient, π _rcv is the zero-knowledge proof of the transaction recipient, record message m _B : = (x, π _rcv , pk _{sig, B} )σ _{m, B} is the key to the message m _B Signature, pk _{sig, B} is the signature key of the transaction recipient;

为交易前交易接收方的账户余额承诺、

为交易后交易接收方的账户余额承诺、sn_v为交易序列号、C_aux，B为监管方对交易接收方的地址公钥的加密结果、h_sig，B为交易接收方签名秘钥的哈希、h_B为h_sig，B和交易接收方地址私钥a_sk，B的伪随机计算结果、Item_aut，B为交易接收方用户授权证书、a_pk，B为交易接收方公钥地址，

交易接收方交易序列号；rt _tx is the transaction commitment Merkle root, rt _aut identity authorized Merkle root,

It is the account balance commitment of the transaction receiver before the transaction,

is the account balance commitment of the transaction receiver after the transaction, sn _v is the transaction sequence number, C _{aux, B} is the encryption result of the address public key of the transaction receiver by the regulator, h _{sig, and B} is the hash of the signature key of the transaction receiver H, h _B is h _{sig, B} and the private key of the transaction recipient address a _sk, the pseudo-random calculation result of B, Item _{aut, B} is the user authorization certificate of the transaction recipient, a _{pk, B} is the public key address of the transaction recipient,

The transaction serial number of the transaction recipient;

若不是则验证失败，输出验证结果res＝0；S312. According to the user address of the transaction sender, verify whether the balance commitment of the account is

If not, the verification fails, and the verification result res=0 is output;

S313. Verify whether rt _aut is the root of the latest identity authorization Merkle tree, if not, the verification fails, and the verification result res=0 is output;

S314. Verify whether rt _tx appears in the account book, if not, the verification fails, and the verification result res=0 is output;

S315. After the transaction verification is passed, the miner needs to add the published serial number to the public serial number set, and update the balance commitment of the corresponding account address to a new balance commitment according to the information published during the transaction sending and transaction receiving process .

Further, in the above S4, it is verified through zero-knowledge proof whether the supervisory auxiliary information is generated as required. If not, the supervisor uses its own encryption to trace the real identity corresponding to the account address with the identity tracing list.

The present invention has the following beneficial effects:

1. The present invention satisfies the non-leakage of the ledger, stores the account balance and transaction amount in the block chain through the form of commitment, and realizes the hiding of the account balance and transaction amount.

2. This method also provides unlinkability of the transaction, by splitting the transaction process into two steps: first, the transaction sender generates a transaction commitment, and then the transaction receiver provides proof to receive the asset. Realize the hiding of transaction link relationship.

3. The present invention also provides supervisorability by requiring each transaction to be attached with supervisory traceability information. Only transactions initiated by users authorized by the supervisor can pass verification, and only the supervisor can trace back to the identity of the transaction participants. At the same time, malicious users cannot initiate a transaction that cannot be traced by the supervisor and pass the verification. The entire process above uses zkSNARK technology to constrain the behavior of both parties to the transaction and ensure the correctness of the transaction execution process.

Description of drawings

Fig. 1 is a schematic flow diagram of the method for privacy protection based on zero-knowledge proof of blockchain in the present invention.

detailed description

The specific embodiments of the present invention are described below so that those skilled in the art can understand the present invention, but it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes Within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious, and all inventions and creations using the concept of the present invention are included in the protection list.

A zero-knowledge proof-based blockchain regulatory privacy protection method, as shown in Figure 1, includes the following steps:

S1. Initialize the blockchain system and obtain the public parameters of the blockchain system, wherein the blockchain system includes a transaction party and a supervisor;

In this embodiment, the generation of system parameters in S1 includes the proof key and verification key used to generate the zkSNARK certificate, as well as the public parameters of encryption and signature algorithms. The specific calculation process is:

Input algorithm security parameter λ, transaction sending constraint circuit C _send and transaction receiving constraint circuit C _rcv to generate system parameter pp:=(pp _enc , pp _sig , pk _send , pk _rcv , vk _send , vk _rcv ), where (pk _send , vk _send ) generates/verifies the key pair for the zero-knowledge proof of the transaction sending circuit, (pk _rcv , vk _rcv ) generates/verifies the key pair for the zero-knowledge proof of the transaction receiving circuit, pp _enc is the public parameter of the encryption algorithm, and pp _sig is Signature algorithm public parameters, the specific calculation method is:

S1-1. For the circuit C _send , according to the formula:

(pk _send , vk _send ):=KeyGen(1 ^λ , C _send )

Calculate the transaction sending circuit zero-knowledge proof to generate/verify the key pair, where λ is the security parameter of the input algorithm. S1-2. For the circuit C _rcv , according to the formula:

(pk _rcv , vk _rcv ):=KeyGen(1 ^λ , C _rcv )

Calculate the transaction receiving circuit zero-knowledge proof to generate/verify the key pair.

S1-3. According to the formula:

Calculate the public parameter pp _enc of the encryption algorithm and the public parameter pp _sig of the signature algorithm.

S2. The supervisor generates the supervisor key and creates the user address of the transaction party, and the transaction party applies to the supervisor for a resource access authorization certificate based on its own identity information and initiates a transaction;

Specifically, in this embodiment, the specific way for the supervisor to generate the supervisor key and create the user address of the transaction party is as follows:

S201. Calculate the encryption key and signature key of the supervisor, and the calculation method is:

(pk _{enc, s} , sk _{enc, s} ):=K _enc (pp _enc )

(pk _{sig, s} , sk _{sig, s} ): = K _sig (pp _sig )

Among them, (pk _{enc, s} , sk _{enc, s} ) is an encryption key pair, (pk _{sig, s} , sk _{sig, s} ) is a signature key pair

S202. Calculate the communication key pair according to the encryption key and signature key calculated in S201, and the calculation method is:

(pk _enc , sk _enc ):=K _enc (pp _enc )

Among them, K _enc (pp _enc ) is a communication key pair;

S203. Select a random number as the address private key and select a random number, and calculate the address public key according to the address public key and the random number. The calculation method is:

a _pk := PRF( _ask , r)

Among them, _{ask is the private key of the address, r is a random number, and a pk is} the public key of the address;

S204. Calculate the user's transaction address according to the address public key, and the calculation method is:

addr:=CRH(a _pk )

Among them, CRH( ) is a collision-resistant hash function.

After the address public key a _pk is hashed, it is disclosed as the user's account address; the address private key a _sk is used to confirm the account right, and only those who know the account address private key have the right to use the account.

The specific method for the transaction party to apply for a resource access authorization certificate from the regulator based on its own identity information is as follows:

S211. The user side sends the address public key, zero-knowledge proof and its own identity information to the regulator;

The user sends (a _pk , π _id , ID) to the supervisor, where a _pk is the user address public key, and π _id is a zero-knowledge proof to ensure that the user who sent the message does have the address private key corresponding to a _{pk ask} . Here, offline technical channels or other systems (such as face recognition systems) can be combined to prevent malicious users from falsely using other people's identity information ID.

S212. The regulator verifies the validity of the user identity, and if valid, stores the address public key a _pk and the user's identity information ID in the identity traceability list IDList;

S213. For users whose identity verification is valid, the regulator calculates the supervisory auxiliary information and user authorization certificate, and the calculation method is:

C _aux :=ε _enc (pk _{enc, s} , a _pk )

Item _aut :＝CRH(a _pk ||C _aux )

Among them, C _aux is the regulatory auxiliary information, CRH( ) is the anti-collision hash function, and Item _aut is the user authorization certificate;

S214. The regulatory party reorganizes the identity authorization Merkle tree, updates the user authorization certificate to the identity authorization Merkle tree, and broadcasts the new identity authorization Merkle tree to the blockchain network. All nodes in the network verify the legitimacy of user identity based on the latest identity authorization Merkle tree.

Since the specific transaction process involves the participation of two parties, the description of the transaction sending algorithm and transaction receiving algorithm is based on the scenario: Alice (the sender) initiates a transfer to Bob (the receiver), and the transfer amount is v _t .

The specific method for sending a transaction:

Deposit Alice account

Note that the private key of Alice's address is _{ask, A} , the public key of the address is a _{pk, A} :=PRF( _{ask, A} , r _A ), r _A is a random number.

Constrained by C _send : v _t must be greater than zero; v _t must be less than or equal to

Select a random number ρ _v , and calculate the transaction sequence number sn _v :=PRF( _{ask, A} , ρ _v ).

Create transaction commitment

计算交易序列号

choose a random number

Calculate transaction sequence number

update account

Generate (pk _{sig, A} , sk _{sig, A} ): = K _sig (pp _sig ).

Calculate h _sig,A :=CRH(pk _sig,A ) and h _A :=PRF( _ask,A ,h _sig,A ).

Encrypt the transaction sequence number C _share with the public key pk _{enc, B} of the transaction recipient: =ε _enc (pk _{enc, B} , sn _v ).

Encrypt the address public key a _{pk, A} with the encrypted public key of the supervisor, and calculate C _{aux, A} : =ε _enc (pk _{enc, s} , a _{pk, A} )

Calculate Item _{auth, A} := CRH(a _{pk, A} ||C _{aux, A} ).

Calculate path _{auth, A} :=Path(Item _{auth, A} ), prove that Item _{auth, A} exists in the leaf node of the identity authorization Merkle tree with rt _auth as the root node.

remember

remember

Compute transaction send zero-knowledge proof π _send := Prove(pk _send , x, W).

Record m _A :=(x, pk _{sig, A} , π _send , C _{s are} ), calculate the signature for message m _A

Record tx _send :=(addr _A , C _share , π _send , x, σ _{m, A} , pk _{sig, A} ), output tx _send .

The present invention uses zkSNARK zero-knowledge proof to ensure the correctness of transactions. During the execution of the transaction sending algorithm, the user will generate a zkSNARK zero-knowledge proof π _send , and the C _send transaction sending constraint circuit mainly constrains the following:

的秘密值

账户余额

地址私钥a_sk，A。To prove that the user has the right to use the account, that is, to prove that the user knows to open the account

the secret value of

Account Balance

Address private key a _{sk, A} .

sn_v，

h_A是按既定规则生成的。prove

sn _v ,

h _A is generated according to established rules.

Prove that the transaction amount v _t is greater than zero; prove that the transaction amount v _t is less than or equal to the account balance

Changes in the balance of the trading account are legal.

The role of path _{auth, A} : to prove that the user is indeed a legitimate user authorized by the regulator; to prove that C _{aux, A} is indeed encrypted with the regulator's encrypted public key to encrypt the transaction sender's address public key a _{pk, A} ; to prove that the user It is true that a _{pk, A} corresponds to the private key a _{sk, A} , which proves that a _{pk, A} := PRF( _{ask, A} , r _A ).

的作用是避免双花攻击。由于矿工维护了已公开的序列号sn的集合SNList，Alice在重放这笔交易的时候，就会很容易被矿工所检测到。算法采用一次性签名方案，保证零知识证明的不可延展性，即为不同交易生成一个唯一标签，保证不同交易中的零知识证明副本不能相同。系统将交易金额及交易接收方的公钥隐藏在承诺cm_tx当中，虽然tx_send对外公开了发起这笔交易的账户地址，但由于承诺的绑定性和隐藏性，任何人都不能从中分析出具体的交易金额及交易对象。Announced in tx _send

The role is to avoid double flower attacks. Since the miners maintain the set SNList of the public sequence numbers sn, Alice will be easily detected by the miners when replaying the transaction. The algorithm uses a one-time signature scheme to ensure the inextensibility of zero-knowledge proofs, that is, to generate a unique label for different transactions, and to ensure that the copies of zero-knowledge proofs in different transactions cannot be the same. The system hides the transaction amount and the public key of the transaction receiver in the commitment cm _tx . Although tx _send discloses the address of the account that initiated the transaction, due to the binding and hidden nature of the commitment, no one can analyze it. The specific transaction amount and transaction object.

If it is a transaction receiving specific method:

After the tx _send transaction is completed, the transaction commitment cm _tx will be added to the transaction commitment Merkle tree of the latest block. When receiving the transaction, the transaction receiver needs to prove that he knows the block (it can be the latest block, or It can be a trapdoor of a transaction commitment in a block in the past, and prove the existence of the commitment.

Debit Bob's account

Write Bob's address private key as _{ask, B} , address public key as a _{pk, B} :=PRF( _{ask, B} , r _B ), r _B is a random number.

如果

解密的输出结果为真：Scan the transaction tx _send initiated by the account address addr _A , calculate

if

The decrypted output is true:

并判断其结果是否与交易tx_send中的cm_tx值一致。calculate

And judge whether the result is consistent with the cm _tx value in the transaction tx _send .

是否存在于交易承诺默克尔树上。judge

Whether to exist on the transaction commitment merkle tree.

Determine whether the transaction sequence number sn _v has appeared in the SNList.

If the above verification results are all passed, continue to execute downward, otherwise, terminate.

Calculate path _tx :=Path(cm _tx ). Give a Merkle tree proof path, proving that cm _tx is on the leaf node of the transaction commitment Merkle tree with rt _tx as the root node.

计算

choose a random number

calculate

update account

generate

Calculate h _sig,B :=CRH(pk _sig,B ) and h _B :=PRF( _ask,B ,h _sig,B ).

Encrypt the address public key a _{pk and B} with the public key of the supervisor, and calculate

Calculate Item _{auth, B} := CRH(a _{pk, B} ||C _{aux, B} ).

Compute path _{auth, B} :=Path(Item _{auth, B} ). A Merkle tree certification path is given to prove Item _{auth, and B} is on the leaf node of the Merkle tree authorized with rt _auth as the root node.

remember

remember

Computational transaction receives zero-knowledge proof π _rcv := Prove(pk _rcv , x, w).

Record m _B :=(x, π _rcv , pk _{sig, B} ), calculate the signature for message m _B

Record tx _rcv :=(addr _B , x, π _rcv , σ _{m, B} , pk _{sig, B} ), output tx _rcv .

The present invention adopts zkSNARK zero-knowledge proof to ensure that transactions can be received correctly. During the execution of the transaction receiving algorithm, the user will generate a zkSNARK zero-knowledge proof π _rcv , and the corresponding transaction receiving circuit C _rcv mainly constrains the following:

的秘密值

账户余额

地址私钥a_sk，B。To prove that the user has the right to use the account, that is, to prove that the user knows to open the account

the secret value of

Account Balance

Address private key a _{sk, B} .

h_B是按既定规则生成的。Changes in the balance of the trading account are legitimate; proof

h _B is generated according to established rules.

Proof that the recipient of the transaction knows the secret value that opens the commitment cm _tx .

The public key of the account address constrained to receive assets is the public key of the address specified in cm _tx .

The role of path _tx : In order to ensure that the link between the transaction initiator and the transaction receiver is broken, in tx _rcv , it is not announced which transaction commitment in the transaction commitment pool the transaction receiver receives, but in order to avoid attacks The attacker forges a non-existent transaction commitment, so the transaction receiver needs to provide a Merkle proof path to prove that the received transaction commitment cm _tx does exist in the transaction commitment pool.

The role of path _{auth, B} : to prove that the user is indeed a legitimate user authorized by the regulator; to prove that C _{aux, B} is indeed encrypted with the regulator's encrypted public key to encrypt the transaction sender's address public key a _{pk, B} ; to prove that the user It is true that a _{pk, B} corresponds to the private key a _{sk, B} , which proves that a _{pk, B} := PRF( _{ask, B} , r _B ).

The algorithm still uses a one-time signature scheme to ensure the inextensibility of zero-knowledge proofs. Since each transaction will be bound with a unique transaction serial number sn _v , after the transaction is received, the used transaction serial number will be published in tx _rcv , and because the system maintains the public serial number set SNList, so if After the attacker replays the tx _rcv after the transaction is received, it will be easily identified by the miners.

S3. The miners verify the legitimacy of the initiated transaction. If it is not legal, discard the transaction and end it. If it is legal, go to step S4;

Verifying the legitimacy of the transaction initiated in S3 includes verifying the legitimacy of transaction sending and transaction receiving, wherein, if the transaction type is transaction sending, the verification method is:

S301, record tx _send :=(addr _A , C _{s are} , π _send , x, σ _{m, A} , pk _{sig, A} ),

Among them: addr _A is the transaction address of the transaction sender, C _{s are} is the asset receiving trapdoor shared by the transaction sender and the transaction receiver, π _send is a zero-knowledge proof for transaction sending, and the message m _A : =(x, π _send , pk _{sig, A} , C _{s are} ), σ _{m, A} is the signature for message m _A , pk _{sig, A} is the signature key of the transaction sender;

为交易前交易发送方的账户余额承诺、

为交易后交易发送方的账户余额承诺、Item_aut，A为交易发送方用户授权证书、a_pk，A为交易发送方公钥地址，

交易发送方交易序列号、C_aux，A为监管方对交易发送方的地址公钥的加密结果、h_sig，A为交易发送方签名秘钥的哈希、h_A为h_sig，A和交易发送方地址私钥a_sk，A的伪随机计算结果、；rt _auth is the root node of the identity authorization Merkle tree, cm _tx is the transaction commitment,

is the account balance commitment of the transaction sender before the transaction,

is the account balance commitment of the transaction sender after the transaction, Item _{aut, A} is the user authorization certificate of the transaction sender, a _{pk, A} is the public key address of the transaction sender,

The transaction sequence number of the transaction sender, C _{aux, A} is the encryption result of the address public key of the transaction sender by the regulator, h _{sig, A} is the hash of the signature key of the transaction sender, h _A is h _{sig, A} and the transaction The sender address private key a _{sk, the pseudo-random calculation result of A} ;

若不是则验证失败，输出验证结果res＝0；S302. According to the user address of the transaction sender, verify whether the balance commitment of the account is

If not, the verification fails, and the verification result res=0 is output;

S303. Verify whether the transaction serial number of the transaction sender appears in the public serial number set, if so, the verification fails, and the verification result res=0 is output;

S304, verify whether rt _aut is the root of the latest identity authorization Merkle tree, if not, the verification fails, and the output verification result res=0;

After the above steps,

remember

Note m _A :=(x, π _send , C _share , pk _{sig , A} ).

Compute res: = V _sig (pk _{sig, A} m _A , σ _{m, A} ).

Wherein: record message m _A :=(x, π _rcv , pk _{sig, B} )σ _{m, A} is the signature for message m _A.

Calculate res':=Verify(vk _send , x, π _send ), output res∧res'.

Among them: vk _send is the zero-knowledge proof verification key of the transaction sending circuit.

If the transaction type is transaction received, the verification method is:

S311, record tx _send :=(addr _B , x, π _rcv , σ _{m, B} , pk _{sig, B} ),

Among them: addr _B is the transaction address of the transaction recipient, π _rcv is the zero-knowledge proof of the transaction recipient, record message m _B : = (x, π _rcv , pk _{sig, B} )σ _{m, B} is the key to the message m _B Signature, pk _{sig, B} is the signature key of the transaction receiver;

为交易前交易接收方的账户余额承诺、

为交易后交易接收方的账户余额承诺、sn_v为交易序列号、C_aux，B为监管方对交易接收方的地址公钥的加密结果、h_sig，B为交易接收方签名秘钥的哈希、h_B为h_sig，B和交易接收方地址私钥a_sk，B的伪随机计算结果、Item_aut，B为交易接收方用户授权证书、a_pk，B为交易接收方公钥地址，

交易接收方交易序列号；rt _tx is the transaction commitment Merkle root, rt _aut identity authorized Merkle root,

It is the account balance commitment of the transaction receiver before the transaction,

is the account balance commitment of the transaction receiver after the transaction, sn _v is the transaction sequence number, C _{aux, B} is the encryption result of the address public key of the transaction receiver by the regulator, h _{sig, and B} is the hash of the signature key of the transaction receiver H, h _B is h _{sig, B} and the private key of the transaction recipient address a _sk, the pseudo-random calculation result of B, Item _{aut, B} is the user authorization certificate of the transaction recipient, a _{pk, B} is the public key address of the transaction recipient,

The transaction serial number of the transaction receiver;

若不是则验证失败，输出验证结果res＝0；S312. According to the user address of the transaction sender, verify whether the balance commitment of the account is

If not, the verification fails, and the verification result res=0 is output;

S313. Verify whether rt _auth is the root of the latest identity authorization Merkle tree, if not, the verification fails, and the verification result res=0 is output;

S314. Verify whether rt _tx appears in the account book, if not, the verification fails, and the verification result res=0 is output;

After the above steps, remember

Note m _B :=(x, π _send , pk _{sig, B} ).

Compute res: = V _sig (pk _{sig, B} m _B , σ _{m, B} ).

Compute res': =Verify(vk _rcv , x, π _rcv ). Output res∧res′.

Among them: vk _rcv is the zero-knowledge proof verification key of the transaction receiving circuit

S315. After the transaction verification is passed, the miner needs to add the published serial number to the public serial number set, and update the balance commitment of the corresponding account address to a new balance commitment according to the information published during the transaction sending and transaction receiving process .

S4. The regulator determines whether to track the user identities of both parties to the transaction. If not, the process ends, and if the process is tracked, enter step S5;

S5. The regulator uses the encrypted private key to decrypt the traceability number and revoke the anonymity of the transaction, and completes the identity tracking of both parties according to the transaction party identity traceability list.

In this embodiment, the specific method includes the following sub-steps

Record tx _send/rcv ·C _aux :=ε _enc (pk _enc,s ,a _pk ), calculate a _pk :=D _enc (sk _enc,s ,a _pk ). Whether it is receiving transaction tx _rcv or sending transaction tx _send , it contains regulatory auxiliary information C _aux , and through zero-knowledge proof, it is guaranteed that C _aux is generated as required. Therefore, for suspicious account addresses, the regulator uses its own encrypted private key And IDList, which can easily trace the real identity corresponding to the account address.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow diagram procedure or procedures and/or block diagram procedures or blocks.

In the present invention, specific examples have been applied to explain the principles and implementation methods of the present invention, and the descriptions of the above examples are only used to help understand the method of the present invention and its core idea; meanwhile, for those of ordinary skill in the art, according to this The idea of the invention will have changes in the specific implementation and scope of application. To sum up, the contents of this specification should not be construed as limiting the present invention.

Those skilled in the art will appreciate that the embodiments described here are to help readers understand the principles of the present invention, and it should be understood that the protection scope of the present invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical revelations disclosed in the present invention without departing from the essence of the present invention, and these modifications and combinations are still within the protection scope of the present invention.

Claims (8)

1. A block chain supervision privacy protection method based on zero knowledge proof is characterized by comprising the following steps:

s1, initializing a block chain system and acquiring common parameters of the block chain system, wherein the block chain system comprises a trading party and a monitoring party;

s2, generating a supervisor key and creating a transaction party user address in the supervisor, and applying a resource access authorization certificate to the supervisor by the transaction party according to the identity information of the transaction party and initiating a transaction;

s3, the miners verify the validity of the initiated transaction, if the initiated transaction is not legal, the transaction is discarded and ended, and if the initiated transaction is legal, the operation goes to the step S4;

s4, judging whether the user identities of the two transaction parties are tracked or not by the monitoring party, if not, ending the process, and if so, entering the step S5;

and S5, the supervisor decrypts the traceback number by using the encrypted private key, cancels the anonymity of the transaction and finishes the identity tracking of both parties of the transaction according to the transaction party identity traceback list.

2. The method of claim 1, wherein the system parameters generated in S1 include a certification key and a verification key for generating zkSNARK certification and common parameters of encryption and signature algorithms, and the specific calculation process is as follows:

inputting algorithm safety parameter lambda, transaction transmission constraint circuit C _send And a transaction reception constraint circuit C _rcv And generating a system parameter pp: = (pp) _enc ，pp _sig ，pk _send ，pk _rcv ，vk _send ，vk _rcv ) Wherein (pk) _send ，vk _send ) Zero knowledge proof generation/verification key pair (pk) for transaction transmitting circuit _rcv ，vk _rcv ) Zero knowledge proof generation/verification key pairs, pp, for transaction receiving circuits _enc For cryptographic algorithm common parameters, pp _sig Are parameters common to the signature algorithm.

3. The method of claim 1, wherein the specific way of generating the supervisor key and creating the transaction party user address in the supervisor in S2 is as follows:

s201, calculating an encryption key and a signature key of a monitoring party, wherein the calculation mode is as follows:

(pk _enc，s ，sk _enc，s )：＝K _enc (pp _enc )

(pk _sig，s ，sk _sig，s )：＝K _sig (pp _sig )

wherein, (pk) _enc，s ，sk _enc，s ) To encrypt the key pair, (pk) _sig，s ，sk _sig，s ) As a signed key pair

S202, calculating a communication key pair according to the encryption key and the signature key calculated in the S201, wherein the calculation mode is as follows:

(pk _enc ，sk _enc )：＝K _enc (pp _enc )

wherein, K _enc (pp _enc ) Is a communication key pair;

s203, selecting a random number as an address private key and selecting a random number, and calculating an address public key according to the address private key and the random number in the following calculation mode:

a _pk ：＝PRF(a _sk ，r)

wherein, a _sk Is an address private key, r is a random number, a _pk Is an address public key;

s204, calculating the user transaction address according to the address public key, wherein the calculation mode is as follows:

addr：＝CRH(a _pk )

wherein CRH (-) is an anti-collision hash function.

4. The method for privacy protection with supervision based on blockchain of zero knowledge certification according to claim 1, wherein the specific manner of the transaction party applying for the resource access authorization certificate to the supervision party according to the identity information of the transaction party in S2 is as follows:

s211, the user side sends the address public key, the zero knowledge proof and the identity information of the user side to the monitoring side

S212, the supervisor verifies the validity of the user identity, and if the validity is verified, the address public key and the identity information of the user party are stored in an identity tracing list;

s213, for the user with valid identity authentication, the supervisor calculates the supervision auxiliary information and the user authorization certificate in the following calculation mode:

C _aux ：＝ε _enc (pk _enc，s ，at _pk )

Item _auth ：＝CRH(a _pk ||C _aux )

wherein, C _aux For the supervision of auxiliary information, CRH (. Circle.) is a collision-resistant hash function, item _auth Authorizing a certificate for the user;

s214, the supervisor reorganizes the identity authorized Merck tree, updates the user authorization certificate to the identity authorized Merck tree, and broadcasts the new identity authorized Merck tree to the blockchain network.

5. The method of claim 1, wherein initiating a transaction in S2 comprises transaction sending and transaction receiving, wherein,

the specific mode of transaction sending is as follows: a user side generates zkSNARK zero knowledge proof in the process of executing transaction transmission, and utilizes a transaction transmission constraint circuit to constrain the transaction process;

the specific mode of transaction reception is as follows: and after the transaction is completed, adding the transaction promise into the Mercker tree of the transaction promise of the latest block, and when the transaction receiver receives the transaction, proving that the transaction receiver knows the trapdoor of the transaction promise in the block and proving the existence of the transaction promise.

6. The method according to claim 1, wherein the verifying the validity of the initiated transaction in S3 comprises a validity verification of the transaction transmission and the transaction reception, wherein if the transaction type is the transaction transmission, the verification method is as follows:

s301, let tx _send ：＝(addr _A ，C _{s are} ，π _send ，x，σ _m，A ，pk _sig，A )，

Wherein: addr _A Transaction address, C, for the sender of the transaction _{s are} Receiving trapdoors, pi for assets shared by a transaction sender and a transaction receiver _send Zero-knowledge proof, memory message m for transaction transmission _A ：＝(x，π _send ，pk _sig，A ，C _{s are} )σ _m，A To the message m _A Signature, pk _sig，A Signing the key for the transaction sender;

rt _auth authorizing a root node, cm, of a Merck tree for identity _tx In order to commit to the transaction,

an account balance commitment for a sender of the transaction before the transaction,

Account balance commitment Item for transaction sender after transaction _auth，A Authorizing a certificate for a transaction sender user, a _pk，A To be the public key address of the sender of the transaction,

transaction sender transaction Serial number, C _aux，A Encryption result of address public key of transaction sender for supervisor, h _sig，A Hash of a signature Key for a sender of a transaction _A Is h _sig，A And a private key a of the address of the sender of the transaction _sk，A The pseudo-random calculation of (a);

s302, verifying whether balance commitment of account before transaction is as

If not, the verification fails, and a verification result res =0 is output;

s303, verifying whether the transaction serial number of the transaction sender appears in the public serial number set, if so, failing to verify, and outputting a verification result res =0;

s304, verifying rt _auth And whether the root of the Merck tree is authorized for the latest identity, if not, the verification fails, and a verification result res =0 is output.

7. The method of claim 6, wherein if the transaction type is transaction receipt, the verification method comprises:

s311, note tx _send ：＝(addr _B ，x，π _rcv ，σ _m，B ，pk _sig，B )，

Wherein: addr _B As transaction address, pi, of the transaction receiver _rcv Zero knowledge proof, memory message m for transaction receiver _B ：＝(x，π _rcv ，pk _sig，B )σ _m，B To the message m _B Signature, pk _sig，B Signing a secret for a transaction recipientA key;

rt _tx committing Merck Tree root, rt to transaction _auth The identity of the root of the Merck tree,

An account balance commitment for a pre-transaction recipient,

Account balance commitment sn for transaction receiver after transaction _v As transaction sequence number, C _aux，B Encryption result of address public key of transaction receiver for supervisor, h _sig，B Hash of the signature Key for the transaction recipient, h _B Is h _sig，B And a private transaction receiver address key a _sk，B Pseudo-random computation result of (3), item _aut，B Authorizing a certificate for a transaction recipient user, a _pk，B In order to be the public key address of the transaction recipient,

a transaction serial number of the transaction receiver;

s312, verifying whether the balance commitment before the account transaction is as

If not, the verification fails, and a verification result res =0 is output;

s313, verifying rt _aut Whether the identity is the root of the latest identity authorization Mercker tree or not, if not, the authentication fails, and an authentication result res =0 is output;

s314, verifying rt _tx Whether the data appears in the account book or not is judged, if not, the verification fails, and a verification result res =0 is output;

s315, after the transaction verification is passed, miners need to add the published serial numbers into the public serial number set, and update the balance commitments of the corresponding account addresses into new balance commitments according to the information published in the transaction sending and transaction receiving processes.

8. The block chain supervision privacy protection method based on zero knowledge certification as claimed in claim 1, wherein in S5, it is verified whether the supervision assistance information is generated as required through zero knowledge certification, and if not, the supervisor uses its own encryption priority to determine whether the identity corresponding to the identity tracing list tracing account address is true.

Images