A privacy token transaction method based on zero-knowledge proof in consortium chain account model

Abstract

The present invention discloses a privacy token transaction method based on a consortium chain account model with zero-knowledge proof. In the process of various token transactions in the consortium chain, the participants use an encryption algorithm to encrypt the account balance and transaction amount data, and use zero-knowledge proof to construct the voucher of each privacy data relationship in the token transaction, so that each endorsement node can verify the public data and vouchers to be written into the account book in each transaction before ensuring that the transaction can be paid, thereby ensuring the legality and validity of the privacy token transaction. This method can effectively protect sensitive data such as the transaction party's own account balance and transfer amount, and uses the endorsement node to verify the zero-knowledge proof voucher before payment, ensuring the consistency and non-negativity of the transfer amount and the non-negativity of the account balance, while still ensuring the efficiency of the transaction.

Description

Technical Field

[0001] The present invention belongs to the field of privacy protection verifiable technology of alliance chain, and relates to a privacy token transaction method of alliance chain account model based on zero-knowledge proof. Background Art

[0002] In recent years, blockchain technology has become one of the fastest-growing fields in computer science. It is a new technology that may cause disruptive changes in all walks of life after Internet technology. Based on the organizational structure and the mode of implementation, blockchain can be divided into three types: public chain, private chain and alliance chain. The transaction performance of the public chain is relatively low and the resource consumption is very large; the private chain has exclusive write permissions for a certain organization, which violates the original intention of blockchain decentralization; and the alliance chain, which operates in a governance model where there is indeed a trust relationship between the participants, has a pluggable consensus protocol, which makes it have the characteristics of efficient transaction performance and low transaction costs. Therefore, it is increasingly becoming the first choice for business applications of various corporate institutions such as banking, finance, and supply chain.

[0003] Since transactions in business applications involve the flow of money between various traders, people have a desire to protect the privacy of transaction information in the blockchain. In order to protect the privacy of money between traders and further leverage the advantages of the alliance chain, various privacy transaction applications will use the privacy tokens in the chain to hide the transaction amount and account balance, and at the same time ensure the legitimacy of changes in the account balances of each transaction party (such as the change in the account balances of both parties to the transfer is consistent). In other words, the privacy transaction information on the blockchain allows a third party to verify the content of some business transaction information, and the technologies that can verify the content under the background of privacy protection mainly include zero-knowledge proof technology and homomorphic encryption technology. Among them, zero-knowledge proof technology is increasingly valued by researchers. It can complete the verification of this secret information without leaking any secret information, which is very consistent with the needs of privacy protection and data verifiability in the blockchain.

[0004] Most of the current privacy currency (token) transaction models are designed based on public chains, and most of them are UTXO models. Compared with the account model, it is difficult to expand using smart contracts, and it also brings a heavy burden in terms of storage and computing. In addition, the unique transaction process of the alliance chain naturally prevents attacks such as double spending. Therefore, in the alliance chain, while protecting the privacy of transaction information, it is necessary to be able to directly use the privacy tokens in the chain to trade under the background of privacy information, and to ensure the legitimacy of changes in the account balances of each transaction party, that is, to verify the legitimacy before ensuring payment, and to protect the privacy of the account balances and transfer amounts of each transaction party. The goal is still in urgent need of research by relevant personnel. Summary of the invention

[0005] Purpose of the invention: The present invention provides a privacy token transaction method based on a consortium chain account model based on zero-knowledge proof, which can effectively protect sensitive data such as the transaction party's own account balance, transfer amount, etc., and use the endorsement node to verify the zero-knowledge proof certificate before payment, thereby ensuring the consistency and non-negativity of the transfer amount and the non-negativity of the account balance, while still ensuring the high efficiency of the transaction.

[0006] Technical solution: The present invention provides a privacy token transaction method based on a zero-knowledge proof alliance chain account model, and the specific steps include:

[0007] (1) During the various token transactions on the alliance chain, participants use encryption algorithms to encrypt account balances and transaction amount data, and use zero-knowledge proofs to construct credentials for the relationships between private data in token transactions;

[0008] (2) Before ensuring that the transaction can be paid, each endorsing node verifies the public data and credentials to be written into the ledger in each transaction to ensure the legality and validity of the privacy token transaction.

[0009] Furthermore, the various token transaction processes described in step (1) include three types of transactions: account recharge, token transfer out, and token transfer in.

[0010] Furthermore, the participants mentioned in step (1) refer to operators who conduct various token transactions. They have the need to keep the account balance and transfer amount information confidential, and at the same time want other non-participants to believe that the changes in the account balances of each transaction party are indeed legal and valid and comply with established rules without knowing the private information of the account balances and transfer amounts and protecting their privacy.

[0011] Furthermore, the use of zero-knowledge proof in step (1) refers to constructing a relational equation to form an operational circuit based on the data relationship in the token transaction, so that the subsequent proof algorithm can generate credentials and the verification algorithm can verify the credentials.

[0012] Furthermore, the use of zero-knowledge proof in step (1) to construct the credentials of each private data relationship in the token transaction specifically includes the following depending on the transaction:

[0013] (11) The transaction type is account recharge, and the private data is the account token value and the recharge amount before and after the recharge. The proof algorithm is used to generate a certificate to prove that the data in the account recharge does meet a certain relationship;

[0014] (12) The transaction type is token transfer, and the private data is the token value of the transfer account before and after the token transfer, the transfer amount, and the symmetric key used to encrypt the transfer amount. The proof algorithm is used to generate a certificate to prove that the data in the token transfer does meet a certain relationship.

[0015] (13) The transaction type is token transfer, and the private data is the token value of the transfer account before and after the token transfer, the transfer amount, and the symmetric key used to encrypt the transfer amount. The proof algorithm is used to generate a certificate to prove that the data in the token transfer does meet a certain relationship.

[0016] Furthermore, in step (11), the voucher used to prove that the data in the account recharge does satisfy a certain relationship includes:

[0017] (111) The account token value after recharging is equal to the sum of the account token value before recharging and the recharge amount;

[0018] (112) The recharge amount is a positive number;

[0019] (113) using the account public key to encrypt the account token value before recharging to be equal to the encrypted account token value before recharging;

[0020] (114) Using the account public key to encrypt the account token value after recharging is equal to the encrypted account token value after recharging.

[0021] Furthermore, the credentials described in step (12) are used to prove that the data in the token transfer does satisfy a certain relationship, including:

[0022] (121) The token value of the transfer account after the token transfer is equal to the token value of the transfer account before the token transfer minus the transfer amount;

[0023] (122) The token value of the transfer account after the token is transferred out is non-negative;

[0024] (123) The transfer amount is a positive number;

[0025] (124) using the public key of the transfer-out account to encrypt the token value of the transfer-out account before the token is transferred out to be equal to the encrypted token value of the transfer-out account before the token is transferred out;

[0026] (125) using the public key of the transfer-out account to encrypt the token value of the transfer-out account after the token is transferred out, so as to equal the encrypted token value of the transfer-out account after the token is transferred out;

[0027] (126) Use the generated symmetric key to encrypt the transfer amount value to equal the public encrypted transfer amount value.

[0028] Furthermore, in step (13), the certificate is used to prove that the data in the token transfer does satisfy a certain relationship, including

[0029] (131) The token value of the receiving account after the token transfer is equal to the sum of the token value of the receiving account before the token transfer and the transfer amount;

[0030] (132) using the public key of the receiving account to encrypt the receiving account token value before the token is transferred to be equal to the encrypted receiving account token value before the token is transferred;

[0031] (133) using the public key of the receiving account to encrypt the token value of the receiving account after the token is transferred to be equal to the encrypted token value of the receiving account after the token is transferred;

[0032] (134) Use the generated symmetric key to encrypt the transfer amount value to equal the public encrypted transfer amount value.

[0033] Furthermore, in step (2), the endorsement nodes are nodes in the consortium chain network that verify and sign transactions. Without knowing sensitive information about token transactions, they can verify the legality of changes in account balances before ensuring payment, thereby ensuring that changes in account balances of all transaction parties are legal and valid.

[0034] Furthermore, in step (2), the verification of the public data and credentials to be written into the ledger in each transaction refers to the endorsement node using the publicly available data and the verification algorithm to verify the credentials before the public data and credentials are written into the ledger.

[0035] Furthermore, in step (2), the said ensuring the legality and validity of the privacy token transaction means that if the endorsement node fails to verify the certificate, it means that the privacy token transaction is illegal, and thus the transaction data is refused to be written into the ledger.

[0036] Beneficial effects: Compared with the prior art, the beneficial effects of the present invention are as follows: 1. The scheme uses an account model instead of a UTXO model, and represents the account balance in a more intuitive mode, supports smart contracts, and has the characteristics of Turing completeness; 2. In the scheme, the account balance and the transaction amount are encrypted, which can effectively protect the transaction privacy of each participant; 3. The scheme is based on zk-SNARK technology. Each endorsement node only needs to verify the generated zero-knowledge proof certificate instead of the sensitive data of the original transaction before the transaction is uploaded to the chain. It can verify the legality before payment while protecting the transaction privacy of each participant, and ensure the legality and validity of various token transactions; 4. The scheme is based on the Hyperledger Fabric consortium chain framework and is specially designed for the characteristics of the consortium chain. It can ensure the efficiency of privacy token transactions while reducing the time expenditure of the participants. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 This is a flow chart of the privacy token transaction method of the alliance chain account model based on zero-knowledge proof according to the present invention;

[0038] Figure 2 This is a schematic diagram of a model for privacy token transactions in a consortium chain account model based on zero-knowledge proof as described in Example 2 of the present invention;

[0039] Figure 3 The structure of the zero-knowledge proof circuit for the account recharge operation described in Example 2 of the present invention;

[0040] Figure 4 The structure of the zero-knowledge proof circuit for the token transfer operation described in Example 2 of the present invention;

[0041] Figure 5 This is the structure of the zero-knowledge proof circuit for the token transfer operation described in Example 2 of the present invention. DETAILED DESCRIPTION

[0042] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0043] Example 1: Figure 1 As shown, a privacy token transaction method of a consortium chain account model based on zero-knowledge proof, the method specifically includes:

[0044] Step (1) During the various token transactions in the alliance chain, the participants use encryption algorithms to encrypt account balances and transaction amount data, and use zero-knowledge proofs to construct the credentials of the private data relationships in the token transactions;

[0045] Step (2) Before ensuring that the transaction is payable, each endorsing node verifies the public data and credentials to be written into the ledger in each transaction to ensure the legality and validity of the privacy token transaction.

[0046] In step (1), various token trading processes include three types of transactions: account recharge, token transfer out, and token transfer in. Participants refer to operators who conduct various token transactions. They have the need to keep the account balance and transfer amount information confidential, and at the same time, they want other non-participants to believe that the changes in the account balances of each trading party are legal and valid and comply with established rules without knowing the private information of the account balance and transfer amount and protecting privacy.

[0047] Using zero-knowledge proof means constructing a relational equation to form an operational circuit based on the data relationship in the token transaction, so that the subsequent proof algorithm can generate credentials and the verification algorithm can verify the credentials. Use zero-knowledge proof to construct the certificate of the relationship between each private data in the token transaction, which is specifically divided into the following types according to the different transactions: 1. The transaction type is account recharge, and the private data is the account token value and the recharge amount before and after the recharge. The certificate is generated by the proof algorithm to prove that the data in the account recharge does indeed satisfy the following relationship: the account token value after recharge is equal to the sum of the account token value and the recharge amount before recharge, the recharge amount is a positive number, the account token value before recharge is encrypted using the account public key, which is equal to the encrypted account token value before recharge, and the account token value after recharge is encrypted using the account public key, which is equal to the encrypted account token value after recharge; 2. The transaction type is token transfer, and the private data is the transfer account token value before and after the token transfer, the transfer amount value, and the symmetric key used to encrypt the transfer amount value. The certificate is generated by the proof algorithm to prove that the data in the token transfer does indeed satisfy the following relationship: the transfer account token value after the token transfer is equal to the transfer account token value before the token transfer minus the transfer amount value, the transfer account token value after the token transfer is a non-negative number, the transfer amount value is a positive number, and the transfer is used to encrypt the account token value. The public key of the outgoing account is used to encrypt the token value of the outgoing account before the token is transferred out, which is equal to the encrypted token value of the outgoing account before the token is transferred out; the public key of the outgoing account is used to encrypt the token value of the outgoing account after the token is transferred out, which is equal to the encrypted token value of the outgoing account after the token is transferred out; the generated symmetric key is used to encrypt the transfer amount value, which is equal to the public encrypted transfer amount value; 3. The transaction type is token transfer, and the privacy data is the token value of the incoming account before and after the token transfer, the transfer amount value, and the symmetric key used to encrypt the transfer amount value. The proof algorithm is used to generate a certificate to prove that the data in the token transfer does satisfy the following relationship: the token value of the incoming account after the token transfer is equal to the sum of the token value of the incoming account before the token transfer and the transfer amount value; the public key of the incoming account is used to encrypt the token value of the incoming account before the token transfer, which is equal to the encrypted token value of the incoming account before the token transfer; the public key of the incoming account is used to encrypt the token value of the incoming account after the token transfer, which is equal to the encrypted token value of the incoming account after the token transfer; the generated symmetric key is used to encrypt the transfer amount value, which is equal to the public encrypted transfer amount value.

[0048] In step (2), each endorsement node refers to a node in the consortium chain network that verifies transactions and signs transactions. Without knowing the sensitive information of token transactions, it can verify the legality of account balance changes before ensuring payment, and ensure that the changes in account balances of each transaction party are indeed legal and valid. Verifying the public data and credentials to be written into the ledger in each transaction means that the endorsement node uses the public data and verification algorithm to verify the credentials before writing the public data and credentials into the ledger. Ensuring the legality and validity of privacy token transactions means that if the endorsement node fails to verify the credentials, it means that the privacy token transaction is illegal, and the transaction data is rejected from being written into the ledger.

[0049] Embodiment 2: A privacy token transaction method based on a consortium chain account model with zero-knowledge proof, the method comprising the following steps:

[0050] The model design of the present invention is as follows Figure 2 shown.

[0051] According to the application scenario requirements, determine the contents of account transaction data, recharge transaction data and transfer transaction data information. The account transaction information is shown in Table 1, the recharge transaction information is shown in Table 2, and the transfer transaction information is shown in Table 3:

[0052] Table 1 Part of the information contained in account transaction data

[0053] Account Name N Account public key pubk Crypto token value <![CDATA[EA t ]]>

[0054] Where N is the account name, pubk is the public key of the account, and EA t Indicates the encryption result of the current real token balance t of the account encrypted using the public key.

[0055] Table 2 Part of the information contained in the recharge transaction data

[0056]

[0057]

[0058] Where N represents the account name for recharge, pubk represents the public key of the recharge account, and EA t0 With EA t1 They represent the encryption results of the real token balance t0 before recharge and the real token balance t1 after recharge respectively. If the account recharge amount is m, then t1 = t0 + m. In addition, the data also includes the zero-knowledge proof π generated for the correctness verification of the recharge.

[0059] Table 3 Partial information contained in transfer transaction data

[0060] Transferring Account Name <![CDATA[N a ]]> Transfer account name <![CDATA[N b ]]> Transferring out the public key of the account <![CDATA[pubk a ]]> Transfer account public key <![CDATA[pubk b ]]> Encrypted symmetric key <![CDATA[EA k ]]> Crypto transaction amount <![CDATA[Ek m ]]> Zero-knowledge proof of token transfer <![CDATA[π out ]]> Token transfer to zero-knowledge proof certificate <![CDATA[π in ]]> The encrypted token value of the transfer account before the token is transferred out <![CDATA[EA ta0 ]]> After the token is transferred out, the encrypted token value of the transfer account <![CDATA[EA ta1 ]]> The encrypted token value transferred to the account before the token is transferred <![CDATA[EA tb0 ]]> After the token is transferred, the encrypted token value is transferred to the account <![CDATA[EA tb1 ]]>

[0061] Where N a Indicates the account name of the transfer, which has the public key pubk a , current account token balance t a0 , encrypted account token balance EA ta0 ; N b Indicates the account name waiting for token transfer, with public key pubk b , current account balance t b0 , encrypted account token balance EA tb0 . Let the amount to be transferred be m, then account N a The balance after transfer is t a1 =t a0 -m, encrypted account token balance EA ta1 , account N b The balance after token transfer is t b1 =t b0 +m, encrypted account token balance EA tb1 In actual situations, account N a Unable to calculate account N b The balance after token transfer t b1 , so we need to let account N b After knowing the transfer amount m, we can calculate it again. If we directly upload the transfer amount m to the chain, the transaction privacy will be leaked. Therefore, we need to use the symmetric key k to encrypt it and get the encrypted result Ek m , and because account N b The symmetric key k is also unknown, so N is also needed. b The public key pubk b Encrypt k to get EA k . Note that pubk is not used directly here. b Encryption m allows both parties to use Ek later m =E(m,k) commitment to generate zero-knowledge proof certificate, that is, the zero-knowledge proof certificate π generated for the correctness verification of token transfer out and token transfer in out and π in In addition, m, k and t in the transfer information a0 ,t a1 ,t b0 ,t b1 They are all secret original sensitive data and will not be directly disclosed to the public on the chain.

[0062] According to the data relationship in the token transaction, a relational expression is constructed to form an operation circuit, so that the subsequent proof algorithm can generate a certificate and the verification algorithm can verify the certificate. In this embodiment, the relationship between the data designed for account recharge is shown in Table 4, the relationship between the data designed for token transfer is shown in Table 5, and the relationship between the data designed for token transfer is shown in Table 6. Here, EA (info, pubk) means using the public key pubk to encrypt the information info, and E (m, k) means using the symmetric key k to encrypt the data m. The construction of their zero-knowledge proof circuits is shown in Table 4. Figure 3 , Figure 4 and Figure 5 As shown:

[0063] Table 4 Representation of the relationship between data in account recharge operation

[0064] <![CDATA[-t1=t0+m]]> -m>0 <![CDATA[-EA t0 =EA(t0,pubk)]]> <![CDATA[-EA t1 =EA(t1,pubk)]]>

[0065] Table 5 Representation of the relationship between data in token transfer operation

[0066] <![CDATA[-t a1 =t a0 -m]]> <![CDATA[-t a1 ≥0]]> -m>0 <![CDATA[-EA ta0 =EA(t a0 ,pubk a )]]> <![CDATA[-EA ta1 =EA(t a1 ,pubk a )]]> <![CDATA[-Ek m =E(m,k)]]>

[0067] Table 6 Representation of the relationship between data in the token transfer operation

[0068] <![CDATA[-t b1 =t b0 +m]]> <![CDATA[-EA tb0 =EA(t b0 ,pubk b )]]> <![CDATA[-EA tb1 =EA(t b1 ,pubk b )]]> <![CDATA[-Ek m =E(m,k)]]>

[0069] Then, by running a non-interactive zero-knowledge proof algorithm, a relational expression is constructed for the data relationship in the determined token transaction to form an operation circuit. Specifically, a system that can run non-interactive zero-knowledge proofs such as Libsnark is used, but is not limited to it. Therefore, the proof algorithm can be used to generate credentials and the verification algorithm can be used to verify the credentials.

[0070] For account recharge transactions, suppose that a participant user A has an account: account name N = {A}, account public key pubk = {MIG...QYe...}, encrypted token value EA using the public key to encrypt the current real token balance t = {0} t ={LoR7ON…}. When this participant needs to recharge the account, it can initiate an account recharge transaction. At this time, the public key is used to encrypt the real token balance before recharge t0 = t = {0}, and the encrypted result of the public key encryption of the real token balance before recharge t0 EA t0 =EA t ={LoR7ON…}. Determine the account recharge amount m = {800}, then the real token balance after recharge is t1 = t0 + m = {800}, and use the public key to encrypt the encryption result of the real token balance t1 after recharge EA t1={gw5+ih…}, and use the proof algorithm of the zero-knowledge proof system to generate the account recharge certificate π={MAUYLj…}, which is used to prove that the recharge amount is greater than 0 (800>0), the balance after recharge is equal to the sum of the balance before recharge and the recharge amount (800=0+800), and the encrypted value of the account balance before and after recharge itself ({LoR7ON…}=EA(0,{MIG…QYe…}), {gw5+ih…}=EA(800,{MIG…QYe…})) is indeed as shown in the transaction.

[0071] Before the account recharge transaction is written into the ledger, the endorsement node in the alliance chain network will verify the generated account recharge certificate to confirm the validity of the recharge transaction. For the account recharge operation, the endorsement node uses the public recharge transaction data (N = {A}, pubk = {MIG...QYe...}, EA t0 ={LoR7ON…},EA t1 ={gw5+ih…}), and the account recharge certificate π={MAUYLj…} is verified using a verification algorithm to determine the correctness of the relationship between the data.

[0072] If the account recharge voucher π={MAUYLj…} is verified, the alliance chain network believes that the privacy data in the account recharge is real. During the account recharge process, the account recharge amount of the participating user is greater than 0 (800>0), the balance after recharge is equal to the sum of the balance before recharge and the recharge amount (800=0+800), and the encrypted value of the account balance before and after recharge ({LoR7ON…}=EA(0,{MIG…QYe…}), {gw5+ih…}=EA(800,{MIG…QYe…})) is indeed the argument shown in the transaction, confirming the correctness of the relationship between the data and ensuring the legality and validity of the account recharge transaction. Finally, the constructed voucher π and the changed account information and the recharge transaction information are written into the account book. However, if the voucher verification fails, it means that this account recharge transaction is illegal, and the transaction data is rejected from being written into the account book.

[0073] For a token transfer transaction, suppose there are two participants, user A and user B, who are about to conduct a transfer transaction. The two account information are: Account Name N a ={A}, account public key pubk a ={MIG…QYe…}, use the public key to encrypt the current real token balance t a0 = {800} encrypted token value EA ta0 ={gw5+ih…};Account Name N b ={B}, account public key pubk b ={MIG…9ic…}, use the public key to encrypt the current real token balance tb0 = {0} encrypted token value EA tb0 ={UT3yMy…}. Note that the participants cannot know the real token balance of other users. When participant user A needs to transfer part of the token amount to participant user B, he can initiate a token transfer transaction and determine the transfer amount value m = {300}, then account N a The balance after transfer is t a1 =t a0 -m={500}, encrypted account token balance EA ta1 ={ndS4P / …}. Because account N a Unable to calculate account N b The balance after token transfer t b1 , you need to let account N b After knowing the transfer amount m, we calculate again and determine the symmetric key k = {0x2b7e15…}, and encrypt it using the symmetric key k to get the encryption result Ek m ={dcfd72…}. Use the proof algorithm of the zero-knowledge proof system to generate the token transfer certificate π out ={MFs / / v…}, used to prove that the balance of one’s account is not less than the transfer amount (800≥300), the transfer amount is greater than 0 (300>0), the balance after the transfer is equal to the balance before the transfer minus the transfer amount (500=800-300), and the encrypted value of the account balance before and after the transfer ({gw5+ih…}=EA(800,{MIG…QYe…}), {ndS4P / …}=EA(500,{MIG…QYe…})), and the encrypted value of the transfer amount ({dcfd72…}=E(300,{0x2b7e15…})) are indeed as shown in the transaction. Then use the public key pubk b Encryption of the symmetric key gives EA k =EA({0x2b7e15…}{MIG…9ic…})={c4gBRc…}, so that user B can decrypt the real transfer amount later.

[0074] Before the token transfer transaction is written into the ledger, the endorsement node in the consortium chain network will verify the generated token transfer certificate to confirm the validity of the token transfer. a ={A},N b ={B},pubk a ={MIG…QYe…},EA ta0 ={gw5+ih…},EA ta1 ={ndS4P / …}, Ek m ={dcfd72…}), the token transfer certificate πout ={MFs / / v…} is verified using a verification algorithm to determine the correctness of the relationship between the data.

[0075] If the token is transferred out of the zero-knowledge proof certificate π out ={MFs / / v…} If the verification is passed, the alliance chain network believes that the privacy data in the token transfer is real. During the token transfer process, the account balance of the participating user is not less than the transfer amount (800≥300), the transfer amount is greater than 0 (300>0), and the balance after the transfer is equal to the balance before the transfer minus the transfer amount (500=800-300) and the encrypted value of the account balance before and after the transfer ({gw5+ih…}=EA(800,{MIG…QYe…}), {ndS4P / …}=EA(500,{MIG…QYe…})) and the encrypted value of the transfer amount ({dcfd72…}=E(300,{0x2b7e15…})) are indeed the arguments shown in the transaction, confirming the correctness of the relationship between the data and ensuring the legality and validity of the token transfer transaction. Finally, the constructed certificate π out The changed account information and the transaction information of the transfer are written into the ledger. However, if the credential verification fails, it means that the token transfer transaction is illegal, and the transaction data is rejected from being written into the ledger.

[0076] For a token transfer transaction, suppose that a participant user B is about to transfer an account, and the account information is: Account Name N b ={B}, account public key pubk b ={MIG…9ic…}, use the public key to encrypt the current real token balance t b0 = {0} encrypted token value EA tb0 ={UT3yMy…}. When user B needs to receive a transfer on the chain, he can initiate a token transfer transaction. First, he needs to obtain the transfer transaction information to be transferred from the alliance chain account book (N a ={A},N b ={B},pubk a ={MIG…QYe…},pubk b ={MIG…9ic…},EA k ={c4gBRc…},Ek m ={dcfd72…},π out ={MFs / / v…},EA ta0 ={gw5+ih…},EA ta1 ={ndS4P / …}), using its own private key prik b ={MII…xSz…}Decrypted EA kGet the symmetric key k = {0x2b7e15...}, and then use the symmetric key k to decrypt Ek m The transfer amount m = {300}, then account N b The balance after transfer is t b1 =t b0 +m={300}, encrypted account token balance EA tb1 ={CYZn8u…}. Then use the proof algorithm of the zero-knowledge proof system to generate the token transfer certificate π in ={MJLmlB…}, which is used to prove that the balance after the transfer is equal to the sum of the balance before the transfer and the transfer amount (300=0+300). The encrypted values ​​of the account balance before and after the transfer ({UT3yMy…}=EA(0,{MIG…9ic…}), {CYZn8u…}=EA(300,{MIG…9ic…})) and the encrypted value of the transfer amount ({dcfd72…}=E(300,{0x2b7e15…})) are indeed as shown in the transaction.

[0077] Before the token transfer transaction is written into the ledger, the endorsement node in the consortium chain network will verify the generated token transfer certificate to confirm the validity of the token transfer. a ={A},N b ={B},pubk b ={MIG…9ic…},EA tb0 ={UT3yMy…},EA tb1 ={CYZn8u…},Ek m ={dcfd72…}), transfer the token into the certificate π in ={MJLmlB…} ​​Use the verification algorithm to verify to determine the correctness of the relationship between the data.

[0078] If the token is transferred to the zero-knowledge proof certificate π in ={MJLmlB…} ​​If the verification is passed, the alliance chain network believes that the privacy data in the token transfer is real. In the token transfer process, the account balance after the transfer of the participating user is equal to the sum of the balance before the transfer and the transfer amount (300=0+300). The encrypted value of the account balance before and after the transfer ({UT3yMy…}=EA(0,{MIG…9ic…}), {CYZn8u…}=EA(300,{MIG…9ic…})) and the encrypted value of the transfer amount ({dcfd72…}=E(300,{0x2b7e15…})) are indeed the arguments shown in the transaction, which confirms the correctness of the relationship between the data and ensures the legality and validity of the token transfer transaction. Finally, the constructed certificate π inThe changed account information and the transaction information of the transfer are written into the ledger. However, if the credential verification fails, it means that the token transfer transaction is illegal, and the transaction data is rejected from being written into the ledger.

[0079] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A privacy token transaction method based on a consortium chain account model with zero-knowledge proof, characterized in that: The method comprises the following steps: (1) During the various token transactions on the alliance chain, participants use encryption algorithms to encrypt account balances and transaction amount data, and use zero-knowledge proofs to construct credentials for the relationships between private data in token transactions; (2) Before ensuring that the transaction is payable, each endorsing node verifies the public data and credentials to be written into the ledger in each transaction to ensure the legality and validity of the privacy token transaction; The use of zero-knowledge proof in step (1) to construct the credentials of each private data relationship in the token transaction specifically refers to: (11) The transaction type is account recharge, and the private data is the account token value and the recharge amount before and after the recharge. The proof algorithm is used to generate a certificate to prove that the data in the account recharge does meet a certain relationship. (12) The transaction type is token transfer. The private data includes the token value of the transfer account before and after the token transfer, the transfer amount, and the symmetric key used to encrypt the transfer amount. The proof algorithm is used to generate a certificate to prove that the data in the token transfer does satisfy a certain relationship. (13) The transaction type is token transfer, and the private data is the token value of the transfer account before and after the token transfer, the transfer amount, and the symmetric key used to encrypt the transfer amount. The proof algorithm is used to generate a certificate to prove that the data in the token transfer does satisfy a certain relationship. The credentials described in step (11) are used to prove that the data in the account recharge does satisfy certain relationships, including the following relationships: (111) The token value of the account after recharge is equal to the sum of the token value of the account before recharge and the recharge amount; (112) The recharge amount is a positive number; (113) Use the account public key to encrypt the account token value before recharge to equal the encrypted account token value before recharge; (114) Use the account public key to encrypt the account token value after recharging to be equal to the encrypted account token value after recharging; The certificate described in step (12) is used to prove that the data in the token transfer does satisfy certain relationships, including the following relationships: (121) The token value of the transfer account after the token transfer is equal to the token value of the transfer account before the token transfer minus the transfer amount; (122) The token value of the transfer account after the token is transferred out is non-negative; (123) The transfer amount is a positive number; (124) Use the public key of the transfer account to encrypt the token value of the transfer account before the token is transferred out to be equal to the encrypted token value of the transfer account before the token is transferred out; (125) Use the public key of the transfer-out account to encrypt the token value of the transfer-out account after the token is transferred out, which is equal to the encrypted token value of the transfer-out account after the token is transferred out; (126) using the generated symmetric key to encrypt the transfer amount value to be equal to the public encrypted transfer amount value; The credentials described in step (13) are used to prove that the data in the token transfer does satisfy certain relationships, including the following relationships: (131) The token value of the receiving account after the token transfer is equal to the sum of the token value of the receiving account before the token transfer and the transfer amount; (132) Using the public key of the receiving account to encrypt the token value of the receiving account before the token transfer is equal to the encrypted token value of the receiving account before the token transfer; (133) Use the public key of the receiving account to encrypt the token value of the receiving account after the token is transferred to be equal to the encrypted token value of the receiving account after the token is transferred; (134) Using the generated symmetric key, the transfer amount value is encrypted to be equal to the public encrypted transfer amount value.

2. According to claim 1, a privacy token transaction method based on a consortium chain account model with zero-knowledge proof, characterized in that: The participants mentioned in step (1) refer to operators who conduct various token transactions. They have the need to keep the account balance and transfer amount information confidential, and at the same time want other non-participants to believe that the changes in the account balances of each transaction party are indeed legal and valid and comply with the established rules without knowing the private information of the account balances and transfer amounts and protecting their privacy.

3. According to a zero-knowledge proof-based alliance chain account model privacy token transaction method according to claim 1, it is characterized in that: The endorsement nodes mentioned in step (2) refer to the nodes in the consortium chain network that verify and sign transactions. Without knowing the sensitive information of token transactions, they can verify the legality of account balance changes before ensuring payment, thereby ensuring that the changes in the account balances of all transaction parties are indeed legal and valid.

4. According to a zero-knowledge proof-based alliance chain account model privacy token transaction method according to claim 1, it is characterized in that: The verification of the public data and credentials to be written into the ledger in each transaction described in step (2) means that the endorsement node uses the publicly available data and the verification algorithm to verify the credentials before the public data and credentials are written into the ledger.

5. According to a zero-knowledge proof-based alliance chain account model privacy token transaction method according to claim 1, it is characterized in that: Ensuring the validity of the privacy token transaction as described in step (2) means that if the endorsement node fails to verify the certificate, it means that the privacy token transaction is illegal, and the transaction data will be refused to be written into the ledger.

Images