CN110728576A

CN110728576A - Decentralized anonymous data transaction method based on zero knowledge proof

Info

Publication number: CN110728576A
Application number: CN201910766253.2A
Authority: CN
Inventors: 欧嵬; 罗恩韬; 邓铭巍
Original assignee: Hunan University of Science and Engineering
Current assignee: Hunan University of Science and Engineering
Priority date: 2019-08-19
Filing date: 2019-08-19
Publication date: 2020-01-24

Abstract

The invention discloses a decentralized anonymous data transaction method based on zero knowledge proof, which ensures the authenticity of data by erecting super nodes and then establishes the anonymity of transaction based on zero knowledge verification technology (ZK-SNARKs) and a DAP scheme of Zerocash. And intelligent contracts are deployed to ensure the benefits of both the buyer and the seller. The technical effect of the present invention is that, by implementing the present invention, decentralized and anonymous transactions can be brought to data sellers and data buyers. Specifically, the invention can complete data transaction by the seller sending information and the buyer deploying intelligent contract, which is simple and convenient for both parties. Furthermore, the present invention utilizes the DAP scheme to provide anonymity of the transaction, and experiments show that this scheme has almost the same performance as Zerocash, which means that it is a practical scheme in data transaction.

Description

Decentralized anonymous data transaction method based on zero knowledge proof

Technical Field

The invention relates to a block chain technology, in particular to a decentralized anonymous data transaction method based on zero knowledge certification.

Background

Blockchains are a new technology first proposed by bitcoin. It describes a distributed ledger without third party involvement. In such a distributed ledger, once data is confirmed, it is not easily tampered with. This is achieved by a novel consensus mechanism called proof of work (PoW). PoW describes a secure accounting system that solves the byzantine problem by introducing computational competition of distributed nodes to ensure data consistency and ledger consistency. In short, a single node that wins the competition will obtain the net-wide accounting rights, and after the "blocks" it collects will be accepted by the net-wide nodes and joined to the "chain" of each node, containing all the transactions it collects and the timestamps of the transactions in case of double payment.

There are many items that currently incorporate IoV and Blockchain, such as smartcarachain and unblock. These items look at blockchains and their distribution, whereby it is desirable to give ownership of data back to the data provider, which typically means that the data owner is free to dominate the collected data. As more data is collected by the user, the more valuable the data becomes, which in turn provides the user with the incentive to collect more data, creating a virtuous circle. Many industries currently require user-provided usage data to support subsequent product development, service provisioning, etc., and vendors and service providers are interested in this data because they can analyze it to build better and more targeted products and services to gain more profits. This need for data makes data transactions very important. Carblock proposes a data transaction mode through an intelligent contract, thereby eliminating the participation of a third party. However, this approach requires the buyer to deploy two intelligent contracts to validate the data and the transaction. This may be inconvenient for the buyer.

In addition to this, anonymity is a function of great interest to the user. In 2014, based on bitcoin, Zcash proposed a new scheme for anonymous payments in blockchain systems with zero knowledge proof. This scheme achieves extremely strong payment anonymity. However, no research has emerged to date regarding anonymous transactions at IoV.

Disclosure of Invention

In order to overcome the technical problems that the conventional data transaction is inconvenient and information can not be provided anonymously, the invention provides a decentralized anonymous data transaction method based on zero knowledge proof, which can realize convenient data transaction and anonymous information provision.

In order to achieve the technical purpose, the technical scheme of the invention is as follows:

a decentralization anonymous data transaction method based on zero knowledge certification comprises the following steps:

step 1, information sending: the buyer of the data is a node in the block chain system to buy the data of the seller which is also the node in the block chain system, wherein the data is encrypted by a data encryption public key, when the buyer needs to buy the data, the buyer firstly receives verification information which is sent by the seller and used for verifying the authenticity of the data and an encrypted data encryption private key, then the buyer checks the verification information by the block chain system, if the verification is true, the next step is executed, otherwise, the transaction is stopped;

step 2, anonymous payment: the buyer casts a new digital coin A by storing a corresponding amount of digital currency in the hosting party, and when casting the digital coin, a secret value for using the digital coin is generated, then another digital coin B bound with the address public key of the seller is cast, the value of the digital coin A is transferred to the digital coin B, and finally the conversion of the currency value is broadcasted;

step 3, intelligent contract: the buyer first encrypts the secret value of the digital coin B using the seller's seller encryption public key to obtain a ciphertext of the secret value, and then the buyer uses the encrypted data decryption private key obtained in step 1 to create the following intelligent contract: that is, if the seller provides the original text of the data encryption private key, the seller will obtain the ciphertext of the secret value;

and step 4, completing the transaction: and after obtaining the data encryption private key, the buyer decrypts the data of the seller through the data encryption private key and sends the ciphertext of the secret value of the digital coin B to the seller, so that the seller uses the digital coin B through the seller address private key and the coin encryption private key of the seller.

In the step 1, the data is uploaded to a super node in a block chain system for storage, and when the super node receives the data, the authenticity of the data is verified, and the data is stored only after the authenticity is verified.

In the step 1, after the super nodes store the data, the data ids of the data are generated to serve as verification information for verifying the authenticity of the data, and each super node in the block chain generates the data ids in the same way, so that each super node generates the same data id when receiving the same data, and broadcasts the data id to the whole block chain system after the super nodes complete the generation, so as to add the data id to a public account book.

In the method for de-centralizing anonymous data transaction based on zero knowledge proof, in step 1, the dataID is a hash of corresponding data.

In the step 1, the buyer checks the verification information through the blockchain system and checks whether corresponding dataID exists in the public ledger book.

The technical effect of the present invention is that, by implementing the present invention, decentralization and anonymity can be brought to data sellers and data buyers. Specifically, the invention can complete data transaction by the seller sending information and the buyer deploying intelligent contract, which is simple and convenient for both parties. In addition, the present invention utilizes the DAP scheme to provide anonymity of transactions, and experiments show that the present scheme has almost the same performance as zerocase, which means that it is a practical scheme in data transactions.

The invention will be further explained with reference to the drawings.

Drawings

FIG. 1 is a schematic diagram of a super node;

FIG. 2 is a schematic diagram of a data transaction process;

FIG. 3 is a schematic diagram of an intelligent contract;

figure 4 is a graph of the performance of the GenerateID algorithm.

Detailed Description

The embodiment provides a decentralized anonymous data transaction scheme on the basis of a block chain. In the following, a specific example of the car networking is described, in which the data buyers are generally car companies and insurance companies, the sellers are car users, and the specific data is various data collected during the operation of the car. When applied to the Internet of vehicles, the system allows data buyers (e.g., insurance companies) to purchase data collected by the seller's vehicle sensors in a decentralized and anonymous manner. In particular, it achieves three goals: (1) the seller sends a piece of information, and the buyer deploys a section of intelligent contract to complete a reliable transaction; (2) no third party mechanism participates in the transaction process; (3) the transaction participants and information (including the transfer amount) are not visible except for the transaction party.

The scheme of the embodiment is based on an extension of zerocas, which is a blockchain system supporting anonymous payment. It describes such a system: each node in the system may deposit their base currency (e.g., bitcoins) into a host to cast a new currency in zerocase's distributed ledger that will bind to the node's address public key. The casting process will produce some secret values that can only be used by those who know the private key of the corresponding address and all of the secret values; to use a new currency, a node that possesses the address private key and knows the secret value will broadcast a transaction: i 'destroy' my old currency to cast two new currencies, wherein one (or two) of the two new currencies is bound to a target address public key and bound with a receiver, and the total value of the two new currencies is equal to the value of the original old currency; in addition, to avoid adding extra channels and assumptions of information, a cryptogram containing the secret value of the new coin is transacted, which cryptogram will be encrypted by the recipient's encryption public key; finally, the coin recipient scans his local ledger and decrypts the ciphertext using his encryption private key until he finds his transaction. He can then use the currency he receives using his private address key and the decrypted secret value. The system achieves anonymity by introducing zk-SNARKs, which is a cryptographic scheme that allows anyone to check the correctness of statement statements in a short time.

The system can be applied to data transaction of the Internet of vehicles. Each buyer and seller can join such a system by depositing any digital currency into an escrow to achieve the goal of an anonymous transaction. However, this transaction is a money transfer that only satisfies the seller's requirements and not the interests of both parties to the transaction. I.e. the system does not guarantee that the buyer obtains the data he wants. To solve this problem, the present embodiment constructs a concept of a super node.

Super nodes are nodes operated by trusted third parties that have all the functions of normal nodes, such as transaction broadcasting, transaction checking and consensus, while they also have some special functions.

And (6) data checking and storing. The owner of the vehicle can upload data to the supernode through the network protocol interface from the corresponding vehicle sensor, and the data is encrypted by the encryption public key generated by the hardware, so that the supernode cannot see the data. When the super nodes receive the data, they verify their authenticity by checking whether the data came from the vehicle sensors, and store and compress them when the verification is successful. This functionality makes the super nodes distributed servers and the data in these servers trusted.

And generating the dataID. After the data inspection and storage process, each supernode will generate a ciphertext of the dataID of the data and the address public key of the data uploader (encrypted by the encryption public key). The dataID is a hash of the corresponding data and is encrypted by the uploader's public encryption key (note that this is a different key pair than the key used for data encryption), since the process is the same for each super node, different super nodes will generate the same dataID if they receive the same metadata. Therefore, they can reach consensus among all super nodes using the practical Byzantine Fault tolerance mechanism [3 ]. Thereafter, the super node broadcasts the dataID after consensus is completed to the entire blockchain system to achieve consensus that adds it to the common ledger. In this way, each buyer can verify the dataID by simply checking the public ledger to confirm the authenticity of the data.

And (6) data retrieval. Anyone in the system can obtain the encrypted data through the corresponding dataID in the supernode. However, only the person possessing the data encryption private key can obtain the original data. It is noted that during the data transaction process, the present embodiment does not construct a private communication channel, for example, the seller sends data to the buyer alone, so it is not necessary to add additional infrastructure or worry about eavesdropping by third parties.

Through the super node (the main functions are shown in fig. 1), the seller can upload his data, and the buyer can confirm his authenticity and obtain the data. However, this is still insufficient for anonymous data transactions because the data is encrypted by the seller's data encryption public key, and the buyer must know the data encryption private key to obtain the data.

So far, the present embodiment has converted the currency to data problem into the currency to private key problem. Then how does the present embodiment make a currency to private key transaction in the blockchain? The present embodiment finds a solution-Hashed-TimeLock Contract (HLTC) [4 ]. HLTC is a technology for cross-chain payments. It requires the payer to set up an intelligent contract for a cryptographic puzzle (typically a hash value of the sha256 function) and anyone triggering the contract and solving the puzzle (i.e. providing an original image of the hash value) can obtain the amount of money the payer deposits into the escrow. The key point of HLTC is to ensure that only the recipient knows the answer to the puzzle.

Through the super node and the HLTC, the embodiment may finally extend the Zerocash system to perform anonymous data transaction. The main steps of data transaction are given below.

Step 1: and (5) sending information. If the buyer wants to purchase the seller's data, the seller first needs to send some information to the buyer. It is necessary to include (1) dataID; (2) a hash of the data decryption private key. The buyer checks the data ID in the public ledger. If it exists in the ledger, the buyer confirms the authenticity of the data. But he cannot get the data immediately because the data is encrypted and he does not know the decryption key. The hash value is the information necessary for deploying the intelligent contract after the new and old coins are transferred.

Step two: and (4) making anonymous payment. The purchaser now needs to deposit a corresponding amount of digital currency in escrow to cast coin a. He then casts another coin B bound to the recipient address public key and transfers the value of coin a to coin B. Next, the present embodiment modifies the original scheme of zerocas: this embodiment broadcasts A, B a conversion of monetary value, but this embodiment does not broadcast the cryptogram of the coin B secret value.

And 3, step 3: and (4) intelligent contracts. Up to now, the seller still does not get the coin B because he does not know the secret value, and the buyer does not get the data because he does not know the data encryption private key. Therefore, the purchaser first encrypts the secret value of the coin B using the encrypted public key of the receiver. The buyer then uses the hash he obtained in step 1 to create such a hash-lock intelligent contract: if someone can provide the original image of the hash value, i.e. the data encryption private key, he will get a ciphertext of the secret value.

This is an overview of the construction of the present embodiment, which is shown briefly in fig. 2. If the smart contract is triggered and completed, the buyer obtains the encrypted private key to decrypt the data and the seller obtains the secret value to use the coin. In this way, the data transaction is completed.

The following presents a detailed technical background for the present embodiment, which uses zero knowledge proof (zk-SNARK) as the main encryption technique for anonymous data transaction in the present embodiment. The following are three components of zk-SNARK:

arithmetic circuit

The arithmetic circuit consists of a line with a specific value and a bilinear gate with only addition and multiplication utility. Given finite field

One is

The arithmetic circuit can only receive

The input of an element in the domain, and its gate output element is also

Taking into account the input

And auxiliary inputThe satisfiability of the present embodiment with the boolean-like operation is defined as follows:

circuit satisfaction problem defining 2.1 circuit C:

bilinear gates are defined by relationships

Its language is

Note that a is what this embodiment is intended to obtain in zk-SNARKs, which this embodiment is referred to as witness.

Secondary operation program

zk-SNARKs use Quadratic Arithmetic Programs (QAPs) [7] to convert any arithmetic circuit into a corresponding set of polynomials. The main idea of QAPs is to convert the circuit into three sets of basic polynomials and a target polynomial, which must satisfy the fact that: there is a product of three sets of basic polynomials and the target polynomial can be divided exactly using some coefficients. This embodiment gives a formal definition of QAPs below.

Definition 2.2 size m and in the Domain

The quadratic arithmetic procedure with degree d is a quadrupleWherein

Are three vectors, each of which is m +1 in-domain

A polynomial ofIs exactly d.

As mentioned above in this embodiment, QAPs pose a satisfaction problem:

definition 2.3A size m

The satisfaction problem of (a), (x, s) to

Of (2), which satisfies (1)

And n is less than or equal to m; (2) x is the number of_i＝s_iWhere i ∈ [ n ]](x is a stretch of s); (3) the target polynomial z (z) can be adjusted by dividing the following polynomial:

for the present embodiment

Refers to

The language of (1).

The present embodiment has so far defined operational circuits and QAPs. Since the QAP is the result of the encoding arithmetic circuit, this embodiment can combine definitions 2.1, 2.2, and 2.3 to obtain a complete definition of QAPs.

Definition of 2.4 one in the Domain

QAP above is composed of three sets of m +1 polynomials

Where k ∈ {0.. m }, and a target polynomial t (x). Assuming F is a function, domain

The upper N functions are used as the input of the function, the N 'functions are used as the output of the function, and the sum of the input element and the output element is N + N'. This example considers that if Q calculation F satisfies:

is an effective distribution of F inputs and outputs if and only if there is a coefficient(s)_N+1,…,s_m) Satisfies t (x) divided by p (x):

in other words, some polynomial h (x) must exist such that h (x) · t (x) · p (x). The magnitude of Q is m, and the degree of Q is that of t (x).

Verifiable Computing (VC)

ForVerifiable Computation (VC) [8 ] for Domain arithmetic Circuit C]：

Allowing provers to speak using common parameters generated by a VC

Non-interactive proofs are generated, and anyone can verify the proofs using another generated public parameter. Moreover, the verification process requires only a short time. Specifically, VC contains three sets of polynomial time algorithms: KeyGen (), computer (), and Verify (). The following embodiment defines three algorithms:

·(EK_F,VK_F)←KeyGen(F,1^λ) Public key generation algorithm obtaining function F (

Domain arithmetic circuit C) and a security parameter λ as inputs; it then outputs the public calculation key EK_FAnd a public verification key VK_F。

·(y,π)←Compute(EK_FX) proving calculation algorithm to obtain the calculation key EK_FAnd x is used to output y ← F (x) and a non-interactive proof of correctness of y.

·b←Verify(VK_FX, pi, y) proof of verification algorithm to obtain verification key VK_FX and proof pi will be the inputs. And if y ← f (x), outputting b ═ 1.

The three algorithms defined above are the main parts of the VC scheme. It is noted that the system as defined by the present embodiment is not in fact publicly verifiable, the verification key VK_FShould be hidden in some designated verifier, otherwise the scheme is vulnerable. To avoid this problem, the present embodiment introduces the concept of zero-knowledge verifiable computations, which requires that the verifier only knows the output of the computation and not the prover's input. Specifically, the present embodiment changes the proof calculation algorithm computer () and the proof verification algorithm Verify ().

·(π)←Compute(EK_FX, a) prove that the calculation algorithm will calculate the key EK_FAnd

(see definition 2.1) as input to output the statement

Non-interactive proofs of pi.

·1←Verify(VK_FX, pi) proof that the verification algorithm will verify the key VK_FX and prove pi as inputs if certain

The output b is 1.

By this change, the key EK is calculated_FAnd a verification key VK_FCan be published in the system, allowing anyone to check for a proof of pi. This is a very suitable solution for blockchain systems, as it allows each node in the system to check the transaction, thereby reaching consensus in the chain. This scheme is also referred to as non-interactive zero-knowledge proof. According to these definitions, the present embodiment gives the properties that the zk-VC scheme should satisfy.

Correctness for any function F, and for any input to F, an honest prover can always convince the verifier that he knows proof a. That is, if the present embodiment is operated (EK)_F， (EK_F,VK_F)←KeyGen(F,1^λ) And (pi) ← computer (EK)_FX, a), this example will always get 1 ← Verify (VK)_F,x,π)

Security for any function F and any probabilistic polynomial time opponents

Efficiency KeyGen () is assumed to be a one-time operation, which costs up evenly across many calculations, but this embodiment still requires a more economical Verify () than calculation F.

DAP

The primary payment scheme used herein is the Decentralized Anonymous Payment (DAP) scheme proposed by zerocas. As described earlier in this embodiment, this is an anonymous solution in payment. The DAP scheme consists of a polynomial time algorithm tuple: setup, CreateAddress, Mint, Pour, Receive.

Setup the algorithm is executed by a trusted third party. It needs to input a security parameter and then output a common parameter pp, which includes the common parameters of zk-SNARKs.

Createdaddress the algorithm is executed by a user in the system. Each user can generate at least one pair (a)_pk,a_sk) Wherein a is_pk＝(addr_pk,pk_enc) And a_sk＝(addr_sk,sk_enc). Specifically, addr_skIs a random number, and

where PRF () is a pseudo-random function, which is a pair of address keys bound to a user; encryption key pair (pk)_enc,sk_enc) Is based on key-private encryption scheme [9 ]]Generated, it is used for encryption. Note that the user may generate any number of key pairs.

Mint the algorithm is executed by the payer. It needs to input the common parameters pp, the monetary value v and the destination address public key addr_pkThen it will output the coins c and TX_mint. Here, the present embodiment shows a specific step (i) of casting a coin in which the algorithm generates three random values ρ, r, s; (ii) algorithmic computationk:＝COMM_r(addr_pk||ρ)，cm:＝COMM_s(v | | k). COMM () is a static hidden non-interactive submission scheme that satisfies verifiability: given c: ═ COMM_r(s) anyone knowing r and s can verify the COMM_r(s) equals c.

(iii) Outputting a coinage result by an algorithm: coin c ═ addr_pkV, p, r, s, cm) and coinage transaction TX_{min t}(v, k, s, cm). Note that anyone can check cm:COMM_s(v | | k) to verify whether cm is a coin commitment (coin commitment) with value v. And nobody can distinguish the coin owner or serial number sn because they do not know the address key addr_pkAnd a secret value ρ. As previously mentioned, TX_{min t}(v, k, s, cm) can only be added to the public ledger if the payer deposits the correct number of funding coins into the escrow.

Pour the algorithm is executed by the payer who spent the old currency. This is an operation of transferring the value of the input old coin set to the output new coin set, and the sum of the values of the old coin set is equal to the sum of the values of the new coin set. Suppose a public and private key pair with an address

The payer wants to pay the moneyPaid to the receiver, the payer will produce and cast two new coinsAndbinding to two address public keys respectivelyAnd

and their value

(Note that to hide a particular transaction amount, one of the pens is bound to the recipient's public address key, while the value of another currency may be 0); inputting a common parameter pp, a plum root tree root rt and an old coin c^oldAn address private key

One from cm^oldEffective authentication path to tree root rt_oldTwo denominations

And

two new address public keys

And

there are also some transaction information strings. For each i e {1,2}, the algorithm performs the following steps: (1) the algorithm generates three random values

(2) Algorithmic computation

The algorithm calculates a zk-SNARKs proof for the following NP statement:

giving a root rt of a plum tree, a serial number sn^oldAnd a monetary commitmentI know note c^old，And a secret private key

The following conditions are met:

a. this currency satisfies: c. C^oldIs/are as follows

And is

And

the same is true;

b. this address private key matches the address public key:

c. this sequence number can be correctly calculated:

d. this monetary commitment exists as a leaf on the tree root of the plum, which is rt in root;

e. these denominations satisfy:

after all these operations are performed, the algorithm will output a transactionWherein C is₁Is a plain text

From pk_encEncrypted ciphertext (C)₂The same thing); two new coins

Still, if the sequence number sn^oldPresent in the previous TX_pourThen this TX at this time_pourWill be rejected by the ledger, thus avoiding double flowers. Note that one coin c is to be used_iThe payer must know the following values: monetary value v_iThree random numbers ρ_i,r_i,s_iAnd a corresponding address private key addr_sk。

Receive the algorithm is executed by the recipient. Obtaining a common parameter pp, a pair of recipient keys (a)_pk,a_sk) And current public ledger, Algorithm scanning transaction TX in ledger_pourTo find and resolveCipher text C_i(use his sk_enc) Thereby obtaining the required secret value to use the coin.

The anonymity of the DAP is primarily reflected in the chur transaction because zk-SNARKs, the payer does not have to disclose the identity of both parties, the transaction amount and the account balance in the open field. Furthermore, the purchaser cannot track the orientation of the coins he casts in the monetary value transaction because he does not know the serial number of the coin.

The following describes how to construct decentralized and anonymous data transaction scenarios using DAPs and smart contracts.

The nouns to be mentioned are first explained as follows:

the payer: the payer is a node in the blockchain. The present embodiment uses the payer to represent the data buyer. I.e. the party paying. In the arrangement, for convenience, the present embodiment sometimes uses him to designate a payer.

The payee: the payee is a node in the block chain. The present embodiment uses the recipient to represent the data seller. I.e. the party receiving the payment. In the scenario configuration, the present embodiment will sometimes refer to her as the payee for convenience.

dataID: the dataID is generated by the supernode. Specifically, the data ID is obtained by hash-hashing the data and encrypting the hashed result using the encryption public key of the uploader.

ID: it contains the ciphertext of the dataID and the public key of the uploader address.

Address: the user can generate the address key pair (addr)_pk,addr_sk) Time-joining the system and issuing the public key addr in the system_pk. Private key addr_skReserved by the user to receive the coins sent to him. It is noted that any number of address key pairs may be generated by the user.

Coin: the coin c comprises a coin acceptance cm, a currency value v, a serial number sn and a coin address addr_pk. cm is a string generated by some cryptographic function (see section 3.2), which would be appended to the ledger if coin c were cast; v is the denomination of c, i.e., the amount of the base coin (e.g., bitcoin);s is a unique string bound to c to avoid double cost; addr_pkIs the address public key of the coin owner, representing who owns c.

General ledger: the solution of the present embodiment is based on a digital currency system, such as bitcoin. Here, the present embodiment refers to basecoin as a basic coin. The distributed ledger L of the present embodiment is a transaction sequence that can only be added and cannot be deleted or modified. In addition, it contains transactions of basic coins and two types of new transactions.

λ: it represents an adjustable security parameter for generating a set of global common parameters pp.

Data encryption key: it comprises (E)_pk,E_sk) In which E_pkIs a data encryption public key for encrypting data, E_skIt is the data encryption private key used to decrypt the data.

Vendor encryption key: it is a key pair generated by key-private encryption scheme. It consists of encrypted public key pk_encAnd an encryption private key sk_encAnd (4) forming.

hash: the embodiment uses Hash to represent the Hash function Hash 256.

Novel transaction

Mint: mint transaction TX_{min t}Is a statement: one coinage with a coinage commitment of cm and a value of v was successfully cast. It contains the coin commitment cm, the coin value v and two values k and s. That is, TX_{min t}＝:(cm,v,k,s)

Pour: pour transaction TX_pourIs a statement: the old coin is "destroyed", two new coins are cast, and the value of the old coin is transferred to the two new coins. It includes a Merkle tree root rt, old currency sn^oldSerial number of (1), two new monetary commitments

And

and a proof of the transaction initiator's possession of the old currency, a public value. It is noted that,

andat least one of which is bound to the address public key of the payee, and the total value of the two new currencies should be equal to the old currency. That is to say that the position of the first electrode,

list: for a given time T, there are three lists in addition to the ledger as public knowledge:

·IDList_Tthis is a list of all IDs generated by the supernode.

·cmList_TThis is the ledger L_TThe list of all monetary commitments that occurred in Mint and Pour transactions.

·snList_TThis is the ledger L_TA list of all currency serial numbers that appear in the Pour transaction.

Note that IDList_TThe IDs included in (a) need to be agreed upon not only in the super node but also in the entire block chain system.

Merkle tree containing currency commitment and data ID: for a given time T, in cmList_TPresence of Tree_TAnd rt is_TIs its root. In addition, this embodiment uses Path_iTo denote with respect to rt_TLeaf of_iThe valid authentication path.

The scheme of this embodiment is a tuple of a polynomial time algorithm (GenerateID, GetID, VerifyID, Setup, createdaddress, Mint, Pour, VerifyTransaction, Recieve) and an intelligent contract, which are summarized here.

·(dataID,C_pk)←GenerateID(data,addr_pk,pk_enc) At the input data set, addr_pkAnd pk_encThen, the algorithm calculates the result of hash on the data set, and then outputs dataID, which is obtained by pk_encCipher text for encrypting the result of the data hash, C_pkIs addr_pkUsing pk_encAnd (4) encrypted ciphertext.

·(dataID)←GetID(IDList_T,addr_pk,sk_enc) Inputting an IDList_TAn addr_pkAnd one sk_encThen the algorithm will use sk_encDecrypting IDList_TEach C in_pkTo output addr with him_pkThe corresponding dataID.

·(b1)←VerifyID(dataID,IDList_T) Enter a dataID and an IDList_TThen, the algorithm will scan IDList_TIf dataID is present in IDList_TIn this case, the output b1 is 1.

H. (pp) ← Setup (λ). when the security parameter λ is input, the algorithm outputs a common parameter pp, which contains the common parameter of zk-SNARKs and some pseudo-random values.

·(addr_pk,addr_sk) And (3) when the common parameter pp is input, the algorithm outputs the address key pair addr_pkAnd addr_sk。

·(c,TX_{min t})←Mint(pp,v,addr_pk) Inputting the public parameter pp, the monetary value v and the target address public key addr_pkThereafter, the algorithm outputs a new coin c and a new mint transaction TX_{min t}。

·

Inputting a common parameter pp, a plum root tree root rt and an old coin c^oldAn address private key

One from cm^oldEffective authentication path to tree root rt_oldTwo dollar value

And

two new address public keysAnd

there are also some trade information character strings, the algorithm outputs two new coinsAnd a pourer transaction TX_pour。

·(b2)←VerifyTransaction(pp,TX_{min t}/TX_pourL) inputting a common parameter pp, a TX_{min t}Or TX_pourAnd book L_TIf the transaction is valid, the algorithm output b2 is 1.

(coinsSet)←Recieve(pp,addr_pk,addr_sk,L_T) Input the common parameter pp, address key pair (addr)_pk,addr_sk) And book L_TThe algorithm outputs a set of coins, coisset.

The construction of intelligent contracts is described below:

the intelligent contract of this embodiment is a HILT, in the pourr stage, for generating a new coin

Four random values are generated

The four random values are the values necessary to use the new coin (another desired value is addr_skSee algorithm Pour). However, in the algorithm of the present embodiment, the present embodiment does not disclose them to the payee or the public. This means that even if one payer broadcasts TX_pourAnd verified by other nodes, the payee still cannot get the coins she casts for the payer because the payer does not get the data. Thus, in broadcast TX_pourThen, the payer needs to be in the blockIntelligent contracts are deployed in the chain to obtain data. Here, the present embodiment gives a detailed step of deploying the smart contract.

1. The payer enters two initial values: hash (E)_sk)，C_v，addr_pk. Wherein hash (E)_sk) Data encryption private key E that is data_skThe hash value of (1), which the payer obtained before payment (see section 2); c_vPk which the payer generates in the pour and is the payee_encFour random values for encryption

The ciphertext of (1).

2. The payer deploys a contract that: if someone can provide a hash (E)_sk) The provider will return to C_v(ii) a But the original image (i.e. E)_sk) Pk to be paid by payer_encEncrypted and sent to the payer.

When someone inputs hash (E)_sk) Is (i.e. E)_sk) This intelligent contract is triggered. Obviously, due to the nature of the hash function, only the payee can give the pre-image, which means that only the payee can obtain C_vOnly the recipient can decrypt C_vBecause she is the only one with the decryption key sk_encThe person of (1). At the same time, E_skAfter encryption is sent to the payer. Up to now, the payer has obtained the data-encryption private key E_skHe can download encrypted data from the supernode and use E_skDecrypting it, thereby obtaining metadata; for the payee, she can use C_vAnd use sk_encDecryption C_vThe secret value is obtained so that the payee eventually obtains the note that the payer cast for her, since she has all the necessary values: four secret random values and addr_skThe present embodiment illustrates the flow of the smart contract in fig. 3.

The present embodiment uses asymmetric encryption in the smart contract to ensure security. As described above, all returned and sent messages are encrypted by the payee's public encryption key, which means that even if a message is eavesdropped by an adversary of probabilistic polynomial time, the probability of successful eavesdropping Pr [ successful decryption ] ≦ negl.

To test the effectiveness of the protocol of this example, several experiments were designed. First, this embodiment tests basic algorithms of the scheme of this embodiment, including createdaddress, Mint, power, smart contract, and GenerateID. Second, this example presents three different sizes of data to test the performance of the GenerateID algorithm, as the performance of such an algorithm is related to the size of the data. The code of this example was written in java, and all experiments were performed in the same machine (Intercore i5-6300@2.30GHz with 12GB of RAM).

TABLE 1 Algorithm Performance

Table 1 shows the performance of a particular algorithm in the scheme. Similar to zerocase, the Merkle tree was not maintained in the experiment in this example because this is not very relevant to the performance of the algorithm in this example. It is worth noting that the present embodiment produces a large result (e.g., a public and private key with a high number of bits) in each basic algorithm of zerocas, and thus this causes a large delay. In practical applications, these time consumptions may be lower. In addition, the smart contract of this embodiment is triggered spontaneously, and specifically, the hash primitive of the data encryption key is automatically input in this embodiment.

Figure 4 shows the performance of the GenerateID algorithm for entering data of different sizes. As shown, the latency of the algorithm of the present embodiment increases as the data size increases. The nature of the hash function leads to such a result that if the present embodiment changes the way dataID is generated, the latency is reduced.

Claims

1. A decentralization anonymous data transaction method based on zero knowledge certification is characterized by comprising the following steps:

step 1, information sending: the method comprises the steps that a buyer of data is a node in a blockchain system to buy the data of a seller which is also the node in the blockchain system, wherein the data is encrypted through a data encryption public key, when the buyer needs to buy the data, verification information used for verifying the authenticity of the data and an encrypted data encryption private key which are sent by the seller are received firstly, then the buyer checks the verification information through the blockchain system, if the verification is true, the next step is executed, and otherwise, the transaction is stopped;

2. The method for de-centralizing anonymous data transaction based on zero knowledge identification as claimed in claim 1, wherein in step 1, the data is uploaded to super nodes in the blockchain system for storage, and the super nodes verify the authenticity of the data when receiving the data, and store the data after verifying the authenticity.

3. The method as claimed in claim 2, wherein in step 1, the super nodes generate data ids of the data as verification information for verifying authenticity of the data after storing the data, and each super node in the blockchain generates data ids of the data in the same manner, so that each super node generates the same data id when receiving the same data, and broadcasts the data id to the whole blockchain system after completing the generation, so as to add the data id to the public ledger.

4. The method of claim 3, wherein in step 1, the dataID is a hash of the corresponding data.

5. The method as claimed in claim 3, wherein the step 1, the buyer checks the verification information through the blockchain system by checking whether the corresponding dataID exists in the public ledger.