CN115131018A

CN115131018A - Block chain based private transaction method and related product

Info

Publication number: CN115131018A
Application number: CN202210493849.1A
Authority: CN
Inventors: 李慧强; 胡成建; 孟宏伟; 唐聪
Original assignee: Hebei Xiong'an Huoshu Technology Co ltd
Current assignee: Hebei Xiong'an Huoshu Technology Co ltd
Priority date: 2022-04-28
Filing date: 2022-04-28
Publication date: 2022-09-30

Abstract

The invention relates to a block chain-based private transaction method and a related product. Wherein the method comprises: creating a private transaction with respect to a digital currency under a chain of the blockchain, wherein the private transaction includes an encrypted ciphertext of the digital currency by a transaction participant and a non-interactive zero-knowledge proof for proving correctness of the private transaction, the encrypted ciphertext of the data currency being encrypted by the transaction participant using a public key of the transaction participant and supporting decryption by a private key thereof; and in response to verifying the private transaction on the chain of blockchains, selectively updating the account of the transaction participant according to the verification of the private transaction. By the technical scheme, the defects of the prior art can be overcome, the privacy transaction of digital currency can be realized safely and efficiently, and the privacy of transaction participants can be effectively protected.

Description

Block chain based private transaction method and related product

Technical Field

The present invention relates generally to the field of blockchain technology. More particularly, the present invention relates to a method of block chain based privacy transaction, and an apparatus and computer readable storage medium for performing the foregoing method.

Background

This section is intended to provide a background or context to the embodiments of the invention that are recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Thus, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.

When a user uses the blockchain to conduct transaction, all data of the user are public and transparent, and any person can obtain any transaction data in a public mode. In practical applications, in order to prevent the transaction data from being tracked and utilized by people, the specific transaction amount data of each transaction needs to be hidden so as to protect the privacy of the user. Currently, the decentralized payment DCP system is mainly built with Pedersen commitment (Pedersen commit) by Maxwell to hide the transaction amount based on Pedersen commitment. However, the prior art mainly has the following disadvantages:

1. the final DCP system using the Pedersen comment technology is incomplete. In particular, due to the lack of decryption capability, the sender needs to transmit additional data (including the random number and the transaction amount) out-of-band to the recipient, adding to the complexity of the system.

2. The user needs to track the random number and amount of each received commit, otherwise, the commit cannot be opened, so that a Non-Interactive Zero-Knowledge proof (NIZK) proof cannot be created or a signature cannot be generated, and the account cannot be used.

3. Since Pedersen commit is based on the binding of discrete logarithm assumptions, serious security issues (e.g., leakage of user privacy by cracking encrypted information) can arise when a sub-computer is available.

It can be seen that the prior art has deficiencies in implementing a hidden transaction amount for which there is currently no effective solution.

Disclosure of Invention

To solve at least the technical problems described in the background section, the present invention proposes a block chain based privacy transaction scheme. By utilizing the scheme of the invention, the defects of the prior art can be overcome, the safe and efficient privacy transaction of the digital currency is realized, and the privacy of the transaction participants is effectively protected.

In view of this, the present invention provides solutions in the following aspects.

A first aspect of the present invention provides a method for block chain based private transaction, including: creating a private transaction relating to digital currency under the chain of blockchains, wherein the private transaction comprises encrypted ciphertext of the digital currency by a transaction participant and a non-interactive zero-knowledge proof for proving correctness of the private transaction, the encrypted ciphertext of the data currency being encrypted by the transaction participant using a public key of the transaction participant and supporting decryption by a private key thereof; and in response to verifying the private transaction on the chain of blockchains, selectively updating the account of the transaction participant according to the verification of the private transaction.

In one embodiment, the transaction participant is configured with a public key and a private key, the transaction participant comprising a sender and a receiver, the creating of the private transaction for digital currency under the chain of blocks comprising: creating an account of the transaction participant, wherein the account of the transaction participant comprises a sender account and a receiver account which take a public key as an address; and generating a private transaction for transacting the digital currency between the account of the sender and the account of the receiver according to the public key and the private key of the sender, the public key of the receiver and the digital currency.

In one embodiment, generating a privacy transaction to transact the digital currency between the sender account and the recipient account comprises: encrypting the digital currency by using the public key of the sender and the public key of the receiver respectively to obtain a first encrypted ciphertext corresponding to the sender and a second encrypted ciphertext corresponding to the receiver; and generating a non-interactive zero-knowledge proof for proving the correctness of the private transaction.

In one embodiment, wherein generating the non-interactive zero-knowledge proof for proving correctness of the private transaction comprises: generating a range certificate for the digital currency; generating a proof of scope regarding a balance after the sender's account transaction; and generating a proof for proving that the encryption amounts in the first encryption ciphertext and the second encryption ciphertext are consistent.

In one embodiment, the format of the first encrypted ciphertext and the second encrypted ciphertext is: c ═ p ^ r, Y ^ g ^ r × h ^ m); wherein C represents an encrypted ciphertext, X and Y represent different parts of the encrypted ciphertext, pk represents a public key, r represents a random number, g represents a private key generator, h represents a message generator, and m represents the digital currency, wherein Y supports direct invocation of a zero knowledge range attestation technique to prove that m is within a predetermined range, and the encrypted ciphertext C supports decryption of the digital currency m by using the private key.

In one embodiment, the method further comprises: in generating the private transaction, the same key is used for digitally signing and encrypting the digital currency.

In one embodiment, selectively updating the account of the transaction participant in accordance with the verification of the private transaction comprises: in response to the private transaction being verified, updating the encrypted amount of the account of the transaction participant and the serial number of the private transaction.

In one embodiment, the method further comprises: clearing the encrypted amount in the accounts of all the transaction participants to return the original digital currency in response to a need to destroy the encrypted amount.

A second aspect of the invention provides an apparatus comprising: a processor; and a memory storing computer instructions for a blockchain based privacy transaction, which when executed by the processor, cause the apparatus to perform the method of the first aspect as described above and in a number of embodiments below.

A third aspect of the invention provides a computer readable storage medium comprising program instructions for a blockchain based privacy transaction, which when executed by a processor, cause the method of the first aspect above and in a number of embodiments below to be carried out.

By using the scheme provided by the invention, the private transaction which contains the encrypted ciphertext of the digital currency encrypted by the public key of the transaction participant and the non-interactive zero-knowledge proof capable of proving the correctness of the private transaction can be created, and the account of the transaction participant is updated based on the verification result of the private transaction. It can be seen that the digital currency related to the scheme of the invention is encrypted by the public key of the transaction participant and is decrypted by the corresponding private key, and the transaction participant does not need to send additional data (such as random numbers and transaction amount) to assist decryption and generate a non-interactive zero knowledge proof, thereby greatly simplifying the implementation process of the whole private transaction and simultaneously avoiding sensitive information leakage to the greatest extent. Therefore, the scheme of the invention can overcome the defects of the prior art, realize safe and efficient privacy transaction of digital currency and effectively protect the privacy of transaction participants.

Drawings

The above and other objects, features and advantages of exemplary embodiments of the present invention will become readily apparent from the following detailed description read in conjunction with the accompanying drawings. Several embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar or corresponding parts and in which:

FIG. 1 is a flow diagram illustrating a method for block chain based privacy transactions according to one embodiment of the present invention;

FIG. 2 is a flow diagram illustrating a method of block chain based privacy transactions according to another embodiment of the invention;

FIG. 3 is a flow diagram illustrating a method for blockchain based privacy transactions according to yet another embodiment of the present invention; and

fig. 4 is a block diagram illustrating an apparatus according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without making creative efforts based on the embodiments of the present invention, belong to the protection scope of the present invention.

It should be understood that the terms "first," "second," "third," and "fourth," etc. in the claims, description, and drawings of the present invention are used for distinguishing between different objects and not for describing a particular order. The terms "comprises" and "comprising," when used in the specification and claims of this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also to be understood that the terminology used in the description of the invention herein is for the purpose of describing particular embodiments only, and is not intended to be limiting of the invention. As used in the specification and claims of this application, the singular form of "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the specification and claims of this specification refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.

As used in this specification and claims, the term "if" may be interpreted contextually as "when", "upon" or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined" or "if a [ described condition or event ] is detected" may be interpreted contextually to mean "upon determining" or "in response to determining" or "upon detecting [ described condition or event ]" or "in response to detecting [ described condition or event ]".

In this application, a blockchain is understood to be a chain data structure formed by connecting data in a blockwise manner in a chronological order. In particular, the data may be guaranteed to be non-tamper-resistant and traceable by a cryptographic means such as a hash algorithm, and the data consistency is guaranteed by a consensus algorithm, which is a decentralized distributed database in nature. In addition, in addition to transfer transactions, blockchain platforms supporting smart contracts may also implement custom business logic through smart contract technology to complete business applications.

The privacy transaction related by the application can be understood as hiding transaction amount in the transaction process, and the robustness, the safety and the like of the transaction are ensured through an encryption technology and a zero-knowledge proving technology.

The zero knowledge proof referred to in this application is to be understood as a two-party protocol, the prover convinces the verifier that some argument is correct without providing the verifier with any useful information. Among them, the zero-knowledge proof system needs to have completeness, reliability and zero-knowledge. Specifically, completeness means that if a proving party really grasps an answer to a certain conclusion, he can find out that the method proves the correctness of data grasped in his hand to the proving party, that is, the proving party cannot really falsify the data. Reliability means that if a proving party does not have a certain answer to the assertion, he cannot prove the correctness of his "so-called answer", i.e. false is true. Zero-knowledge means that the verifier has no knowledge of other information than the result of the proof.

The Integrated Signature Encryption (ISE) referred to in this application is understood to be the Encryption and Signature operations using the same key pair.

The Bulletprofo technique referred to herein is an efficient zero knowledge range proof technique that can prove that a transaction amount is within a certain range but does not reveal other information.

The following detailed description of embodiments of the invention refers to the accompanying drawings.

FIG. 1 is a flow diagram illustrating a method 100 of block chain based privacy transactions according to one embodiment of the invention. As shown in fig. 1, at step S101, a privacy transaction for digital currency may be created under the chain of blockchains. It is understood that the blockchain herein may have the characteristics of the blockchain described above. The privacy transaction can comprise encrypted ciphertext of digital currency by transaction participants and non-interactive zero-knowledge proof for proving correctness of the privacy transaction. Specifically, in the process of creating the private transaction under the link, the public key of the transaction participant can be used for encrypting the digital currency to form the encrypted ciphertext, and the encrypted ciphertext supports the decryption by the transaction participant by using the private key, so that the process does not need the transaction participant to send additional data (such as a random number and a transaction amount) to assist the decryption, and sensitive information leakage can be avoided to the greatest extent. Meanwhile, in the process of creating the privacy transaction, a non-interactive zero-knowledge proof can be generated so as to assist in verifying the correctness of the privacy transaction.

Next, at step S102, in response to verifying the aforementioned privacy transaction on the chain of the blockchain, the account of the transaction participant may be selectively updated according to the verification result of the privacy transaction. In some embodiments, after a privacy transaction is created, it may be published on a blockchain for verification and then a determination may be made as to whether to update the account on which the transaction is participating based on the verification. For example, the account of the transaction participant may be updated after the privacy transaction is validated, and the update of the account of the transaction participant is not performed after the privacy transaction is validated. It can be seen that, in the whole process, extra data (such as random numbers and transaction amount) does not need to be sent by transaction participants to assist decryption and generate a non-interactive zero-knowledge proof, so that the implementation process of the whole private transaction is greatly simplified, and sensitive information leakage can be avoided to the greatest extent. Therefore, the scheme of the invention can overcome the defects of the prior art, realize safe and efficient privacy transaction of digital currency and effectively protect the privacy of transaction participants.

Fig. 2 is a flow diagram illustrating a method 200 of block chain based privacy transactions according to another embodiment of the present invention. It is understood that the blockchain herein may have the characteristics of the blockchain described above. Further, the transaction participants in this embodiment are configured with a public key and a private key, and may include a sender and a receiver. It should be noted that the method 200 of fig. 2 can be understood as a further definition and extension of the method 100 of fig. 1. The same applies, therefore, to fig. 2 as previously described in connection with the details of fig. 1.

As shown in fig. 2, at step S201, an account of a transaction participant may be created. Wherein the accounts of the transaction participants may include a sender account and a receiver account addressed to the public key. In some embodiments, both parties to the transaction (e.g., the sender and the receiver) may separately create accounts with public keys as account addresses under the chain. In addition, the private key of the sender or the receiver may be used to manage the account, and the status of the sender account and the receiver account may include identification information (e.g., a serial number) and an encryption balance, etc. that uniquely identifies the private transaction.

Next, at step S202, a private transaction may be generated that transacts digital money between the sender account and the recipient account based on the public and private keys of the sender, the public key of the recipient, and the digital money. Specifically, in some embodiments, the digital currency may be encrypted using a public key of the sender and a public key of the receiver, respectively, to obtain a first encrypted ciphertext corresponding to the sender and a second encrypted ciphertext corresponding to the receiver. Next, a non-interactive zero-knowledge proof may be generated for proving the correctness of the private transaction. In some implementations, the aforementioned non-interactive zero-knowledge proof may include a scope proof regarding digital currency, a scope proof regarding a balance after a sender account transaction, and a proof to prove that the encrypted amounts in the first encrypted ciphertext and the second encrypted ciphertext are consistent. It should be noted that the detailed description of the generation process of the private transaction is only an exemplary description, and the solution of the present invention is not limited thereto.

In some embodiments, the format of the first encrypted ciphertext and the second encrypted ciphertext may be: c ═ p ^ r, Y ^ g ^ r × h ^ m); wherein C represents the encrypted ciphertext, X and Y represent different parts of the encrypted ciphertext, pk represents a public key, r represents a random number, g represents a private key generator, h represents a message generator, and m represents digital currency, wherein Y supports direct invocation of a zero knowledge range attestation technique to prove that m is within a predetermined range, and the encrypted ciphertext C supports decryption of the digital currency m with the private key. When decrypting the digital currency m, the value of h ^ m can be derived using the known X and Y. Wherein m is within a certain range (e.g. 2^32), and the value of g ^ r can be obtained through pk ^ sk (wherein sk is a private key held by a user), and then h ^ m is decrypted by using a space time-shifting strategy (e.g. Shanks algorithm) so as to realize the decryption of m. Therefore, the decryption process of the encrypted ciphertext does not depend on the random number, the random number does not need to be sent additionally, and the receiver or the sender can decrypt the encrypted money according to the private key, so that the integrity of the DCP is ensured. It should be noted that the detailed description of decrypting the encrypted ciphertext is only an exemplary description, and the solution of the present invention is not limited thereto.

Further, the same key may be used for digital signing and encryption of digital currency in generating the privacy transaction. Therefore, complexity of overall technology implementation can be effectively reduced, and transaction processing efficiency is improved.

Further, in some embodiments, the encrypted amount in the accounts of all transaction participants may also be cleared in response to a need to destroy the encrypted amount to return the original digital currency to meet the user's usage needs.

Further, the invention also provides a safe, efficient and modular general auditable DCP design to construct a block chain based privacy transaction system. In the generic DCP system, an account may be created using an ISE key pair, where the public key is the account address and the private key is used to control the account. The account state comprises a serial number and an encryption balance of the privacy transaction, and the update of the user account state can be triggered after the privacy transaction is verified. In addition, the blockchain may also be responsible for tracking and updating the status of each account. For example, let Cs, Cr be the encrypted balance of Alice and Bob accounts. When Alice wants to trade m digital currencies to Bob, it can encrypt the amount m by using its own public key pks and Bob public key pkr to obtain Cs and Cr. Then, generating a NIZK proof to verify the correctness of the transaction, a specific proof procedure may involve proving that Cs and Cr are the same in encrypted amount, proving that the transaction amount is within a certain range, and proving that Alice's remaining amount after the transaction > is 0.

In some embodiments, the transaction amount m may be encrypted using a homomorphic public key encryption scheme twist elgamal. As described above, the amount m may be encrypted using the public key pk of the user to obtain the ciphertext C ═ pk ^ r, Y ^ g ^ r × h ^ m. Where Y can directly call Bulletproof that the amount m is within the correct range. In addition, the user can decrypt the encrypted money amount through the private key, and the integrity of the DCP is guaranteed.

In some embodiments, the account balance may be encrypted using a standard mode of the ISE encryption component, the transfer amount m may be encrypted using an extended mode of the ISE encryption component, the validity of the private transaction is certified with the NIZK and the validity is guaranteed to be publicly verifiable, and the verifiability of the transaction is guaranteed using a signature component of the ISE. A general DCP system can be designed based on ISE and NIZK, and each function in the general DCP system can be abstracted as a corresponding function interface, which specifically relates to the following function interfaces:

Setup(1 ^λ ): the input security parameter λ is used mainly to measure the algorithm complexity of the encryption scheme, indicating that data up to a certain length is considered computationally infeasible (e.g. the length of the key). The description is mainly for research use, and the actual generation of the common parameters does not require the input of the parameters, but is determined by the elliptic curve used, etc. The system common parameters pp are output, which may be used by trusted authorities to generate all common parameters for use by the entire system (e.g., g, h, u producers, gv, hv producer vectors, etc.). Since the common parameters are common to the whole system, the correctness of the parameters and the generation/verification proof which can be correctly generated need to be ensured, and the generation of the generation element is not carried outThe secret value (in particular, the base point of the curve multiplied by the secret value) is preserved and is therefore typically generated by the recipient (e.g., the system builder).

CreateAccount (m to sn): the balance m-and the serial number sn of the account are input, and the balance C-and the encrypted key pair are output. The user creates an account using the method.

RevealBalance (sk, C-): the input is a decryption key sk and an encryption balance C-, and the output is a plaintext m-. The user can obtain the balance by the method.

CreateCTx (sks, pks, pkr, m): the sender key pair (sks, pks), the receiver pkr and the transfer amount m are input, and the private transaction ctx is output. The user may use this method to transfer m from account pks to account pkr. The key used by the digital signature and the key used by the encryption involved in the process are the same key, so that the complexity of the technical implementation is reduced.

VerifyCTx (ctx): the input is the privacy transaction ctx, the output "0" represents that the verification is passed, and "1" represents that the verification fails. The verifying party verifies the validity of the transaction by using the method, and the balance of the user is updated on the block chain after the verification is passed.

UpdateCTx (ctx): for any ctx on the blockchain, the corresponding sender or receiver updates its corresponding balance. The sender decreases m and the receiver increases m.

JustrifyCTx (pk, sk, { ctx }, f): inputting a key pair (pk, sk) of a user, a privacy transaction ctx and a strategy f (wherein the strategy f mainly comprises an anti-money laundering strategy, an auditing strategy, a tax payment strategy and the like), and outputting a proof pi for proving the correctness of the strategy f (whether the ctx accords with a rule set in the strategy f can be proved according to the proof pi and the strategy f). The user uses this method to generate a proof for verification. Wherein the anti-money laundering policy involves verifying that the sum of the transfer amounts of a series of private transactions is within a certain range (e.g., the sum of 10 consecutive transactions of a certain user is between 10 and 100 ten thousand). The auditing strategy involves proving the transaction amount in a certain private transaction to be a specific value m. Tax return strategies involve proving the transaction amount for two transactions to be a certain proportion. Taking Alice as an example, these two transactions are a transfer received by Alice (amount m1) and a transfer issued by Alice (amount m2), respectively, which prove that m1: m2 is equal to a certain ratio (e.g., tax ratio, corresponding to the case where Alice has received m1, which requires m 2).

AuditCTx (pk, { ctx }, f, [ pi ]): and inputting a user public key pk, a privacy transaction ctx, a strategy f and a certificate pi, outputting '0' to represent that the verification is passed, and outputting '1' to represent that the verification is not passed. The user uses the method to check whether the privacy transaction conforms to the corresponding policy f rule.

Specifically, in one embodiment, the number of bits of the transaction amount involved in the DCP system is 32, the elliptic curve algorithm may use BN128, the Hash algorithm may use Keccak256, and the blockchain platform uses etherhouses. It should be noted that the general DCP can be instantiated by different instantiation methods, for example, an elliptic curve (which needs to satisfy homomorphic encryption), a Hash algorithm, a block chain platform, etc. can be replaced correspondingly, and the corresponding implementation can be adjusted.

In practical application, the whole system is divided into two parts, one part is used for generating the down-chain account, generating the certification and the like, and the other part is used for verifying the on-chain contract, updating the account state record and the like. Fig. 3 is a flow diagram illustrating a method 300 of blockchain based privacy transactions according to yet another embodiment of the present invention. The overall flow of the system is exemplified below with reference to fig. 3 by taking the example of transferring m digital currencies from the system build to the final Alice to Bob.

As shown in fig. 3, at step S301, system parameters (Setup) may be initialized. For example, the previously defined system method Setup (1) can be used ^λ ) Common parameters that need to be used to initialize the entire system. Common parameters such as g, h, u generator and gv, hv generator

Next, at step S302, an initial account (createacount) of Alice and Bob may be created. Wherein the initial amounts in the initial accounts are all 0.

Next, at step S303, a Deposit operation (i.e., a Deposit operation) may be performed on the account of Alice and the account of Bob, respectively. Since all the people do not hold the cryptocurrency in the initial state of the system, the digital currency needs to be converted into the cryptocurrency through deposit operation, and then the circulation of the cryptocurrency is realized through privacy transaction. For example, 1000 Eth each may be sent to the on-chain intelligent contracts to initialize the account. At this time, Alice and Bob both hold 1000 digital currencies. Wherein, steps S302 and S303 both belong to an initialization operation for an account.

Next, at step S304, a privacy transaction may be created through the Alice account with respect to Alice transferring digital currency to Bob. Specifically, the transaction amount m (e.g., 500 digital currencies) may be encrypted using Alice public key pks and Bob public key pkr to obtain ciphertexts Cs and Cr, respectively. Next, a range certificate is generated for the transaction amount m. Then, the previous revealabalance interface may be used to obtain a balance m ' after Alice transaction (for example, a current balance mc (i.e., a balance before transaction) of Alice may be obtained, and a balance m ' after transaction is obtained through mc-m), and a range certificate may be generated for m '. Then, a Sigma certificate is generated to prove that the Cs and Cr encrypted amounts are consistent.

Then, in step S305, after the blockchain contract receives the privacy transaction, the privacy transaction is verified. Specifically, when the verification is passed, the UpdateCTx interface may be invoked to update the account statuses of Alice and Bob, respectively (for example, the update may involve a corresponding change in the encryption amount, an increment in the transaction serial number of the sender Alice, and the like). When the verification fails, no change occurs to the Alice and Bob accounts.

Next, at step S306, after the private transaction is verified, the account of Alice and the account of Bob are updated respectively. For example, after the privacy transaction is verified, Alice has an encryption balance of 500 and Bob has an encryption balance of 1500.

Next, in step S307, a block chain contract destruction method is respectively called to destroy the encrypted assets on the contract (i.e., clear the encrypted assets) to obtain the original digital assets. For example, an equal proof of ownership of Alice, Bob accounts may be generated to prove ownership of the accounts, while proving that the encryption amount on the chain is indeed 500, 1500. Then, Alice and Bob are cleared of their encrypted digital currency assets, respectively, and the original Eth is returned. Therefore, the transaction amount of the digital currency transaction is hidden by the efficient encryption algorithm and the zero knowledge proving system, and the privacy of both parties of the transaction is protected.

Fig. 4 schematically shows a schematic block diagram of an apparatus 400 according to an embodiment of the present invention. As shown in fig. 4, device 400 may include a processor 401 and a memory 402. Wherein the memory 402 stores computer instructions for a blockchain based privacy transaction, which when executed by the processor 401, cause the device 400 to perform the method according to the previous description in connection with fig. 1-3. For example, in some embodiments, device 400 may perform creation and verification of private transactions, updates to accounts of transaction participants, and the like. Based on this, the device 400 can realize safe and efficient private transaction of digital currency and effectively protect the privacy of transaction participants.

From the above description of the modular design of the present invention, it can be seen that the system of the present invention can be flexibly arranged according to application scenarios or requirements without being limited to the architecture shown in the accompanying drawings. Further, it should also be understood that any module, unit, component, server, computer, or device performing operations of examples of the invention may include or otherwise access a computer-readable medium, such as a storage medium, computer storage medium, or data storage device (removable) and/or non-removable) such as a magnetic disk, optical disk, or magnetic tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data. In this regard, the present invention also discloses a computer-readable storage medium having stored thereon computer-readable instructions for a blockchain based privacy transaction, which when executed by one or more processors, perform the methods and operations described above in connection with the figures.

While various embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous modifications, changes, and substitutions will occur to those skilled in the art without departing from the spirit and scope of the present invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is intended that the following claims define the scope of the invention and that the module compositions, equivalents, or alternatives falling within the scope of these claims be covered thereby.

Claims

1. A method for private transaction based on block chain, comprising:

creating a private transaction with respect to a digital currency under a chain of the blockchain, wherein the private transaction includes an encrypted ciphertext of the digital currency by a transaction participant and a non-interactive zero-knowledge proof for proving correctness of the private transaction, the encrypted ciphertext of the data currency being encrypted by the transaction participant using a public key of the transaction participant and supporting decryption by a private key thereof; and

in response to verifying the private transaction on the chain of blockchains, selectively updating the account of the transaction participant according to a result of the verification of the private transaction.

2. The method of claim 1, wherein the transaction participants are configured with public and private keys, wherein the transaction participants include a sender and a receiver, and wherein creating private transactions in respect of digital currency under the chain of blocks comprises:

creating an account of the transaction participant, wherein the account of the transaction participant comprises a sender account and a receiver account which take a public key as an address; and

and generating a private transaction for transacting the digital currency between the account of the sender and the account of the receiver according to the public key and the private key of the sender, the public key of the receiver and the digital currency.

3. The method of claim 2, wherein generating a privacy transaction that transacts the digital currency between the sender account and the recipient account comprises:

encrypting the digital currency by using the public key of the sender and the public key of the receiver respectively to obtain a first encrypted ciphertext corresponding to the sender and a second encrypted ciphertext corresponding to the receiver; and

a non-interactive zero-knowledge proof is generated for proving the correctness of the private transaction.

4. The method of claim 3, wherein generating a non-interactive zero-knowledge proof for proving correctness of the private transaction comprises:

generating a range certificate for the digital currency;

generating a scope proof regarding the balance after the sender account transaction; and

and generating a proof for proving that the encryption amounts in the first encryption ciphertext and the second encryption ciphertext are consistent.

5. The method of claim 3, wherein the first encrypted ciphertext and the second encrypted ciphertext are in the format of:

C＝(X＝pk^r，Y＝g^r×h^m)；

wherein C represents an encrypted ciphertext, X and Y represent different parts of the encrypted ciphertext, pk represents a public key, r represents a random number, g represents a private key generator, h represents a message generator, and m represents the digital currency, wherein Y supports direct invocation of a zero knowledge range attestation technique to prove that m is within a predetermined range, and the encrypted ciphertext C supports decryption of the digital currency m by using the private key.

6. The method of claim 3, further comprising:

in generating the private transaction, the same key is used for digitally signing and encrypting the digital currency.

7. The method of any of claims 1 to 6, wherein selectively updating the account of the transaction participant according to the verification of the private transaction comprises:

in response to the private transaction being verified, updating the encrypted amount of the account of the transaction participant and the serial number of the private transaction.

8. The method of claim 7, further comprising:

clearing the encrypted amount in the accounts of all the transaction participants to return the original digital currency in response to a destruction requirement for the encrypted amount.

9. An apparatus, comprising:

a processor; and

a memory storing computer instructions for a blockchain based privacy transaction, which when executed by the processor, cause the device to perform the method of any of claims 1-8.

10. A computer program product comprising program instructions for a blockchain based privacy transaction, which when executed by a processor, cause the method according to any one of claims 1-8 to be carried out.