User A attempts to sell a piece of data D (byte level) to user B at price C through the blockchain. A and B do not trust each other. A worry: After the data D is delivered, B does not complete the transfer; B worry: After completing the transfer, A does not send data D, or sends invalid data D. How to design a reasonable mechanism to protect the interests of both parties?

  • $\begingroup$ Blockchain has nothing to do with the problem and does not help solve it. On the technical level: Fair computation is impossible to guarantee in the 2-party case. In any protocol, one has has to commit to the trade first - and the other party can then abort. To achieve fairness ( and robustness) you need an honest majority, which is strictly more than 50%. $\endgroup$ – tylo Jul 21 at 14:43

Etherium handles this. You need a trusted Escrow, If you don't trust a single third party you can use smart contracts to use the network as a distributed trusted third party. You don't trust any single member of the network or even small conspiring groups you trust the network as whole.

With a smart contract you will provide a commitment on the data you wish to send(possibly a key allowing decrypting other data). You will supply a zero knowledge proof you hold a value matching the commitment as well as other proprerties(matches what you want to send). Notice this assumes the buyer can verify the data he is buying.

The smart contract goes on the blockchain, and enforces the contract when one side provides publicly a value matching the commitment it can be verified by the contract and funds will be "transferred" on the ledger.

The contract is a program executed by multiple parties on the network, you pay them for their services. In etherium this is the cost of fuel.

  • $\begingroup$ I have one question, if user A want to sell data D, then the value ( matching the commitment and provided by user A) should be de-commitment. Others can see this value, and they will know data D. How to solve this? $\endgroup$ – Sober Jul 21 at 5:47
  • 1
    $\begingroup$ The revealed value may itself be encrypted by the buyer's public key. So only the buyer can make use of it. $\endgroup$ – Meir Maor Jul 21 at 6:24
  • $\begingroup$ Thank you for your answer! $\endgroup$ – Sober Jul 21 at 7:42

Here is a tiny protocol, which is adapted from the zkPoD project:

Suppose Alice is the seller, Bob is the buyer, Julia is the smart contract on the blockchain. Alice has a chunk of data $m$ (only a few bytes), $g$ is the generator of an ECC group $\mathbb{G}$. Alice computes the commitment of the data chunk $\sigma=g^m$ (Here we don't consider the perfect hiding. It can be replaced by commitment schemes with perfect hiding)

  • common input: $g$, $\sigma$
  • Alice's private input: $m$
  • Bob has a few crypto-coins (Ethers, assume Julia the smart contract is deployed on Ethereum)

1st step> Alice picks a random number $k$ from $\mathbb{Z}_p$, where $p$ is the order of the group $\mathbb{G}$. The number $k$ will be used as a one-time pad key to encrypt $m$. Alice also picks another randomness $r$ that is used to encrypt $k$.

2nd step> Alice -> Bob: $K=g^k$, $R=g^r$

3rd step> Bob -> Alice: a randomness $e$ from $\mathbb{Z}_p$

4th step> Alice -> Bob: $z = r + e\cdot k$, $m'=m+k$. Bob verifies: $g^{m'} \overset{?}{=} \sigma \cdot K$, and $g^{z} \overset{?}{=} R \cdot K^e$. The verification is done by using homomorphic property of commitments. If they hold, Bob deposits his coins to Julia the smart contract.

We can see that the 2~4 step is an extended Schnorr protocol, which is provably HVZK(zero-knowledge). So Bob gets the encrypted data chunk $m'$, he cannot compute any useful information from it at this moment. Next, Julia will play a central role in exchanging $r$ with Bob's crypto-coins with strong fairness.

5th step> Bob -> Julia (the smart contract): The commitment $R$, which is exactly the one that was sent from Alice at 2nd step.

6th step> Alice -> Julia (the smart contract): The randomness $r$. Here is a subtle thing: Alice needs to check if the commitment(at 5th step) is correct since Bob might be cheating. Why can Alice do the check? Because Julia's internal states and code are publicly readable by any blockchain miners.

7th step> Julia verifies: $R\overset{?}{=} g^r$. If the equation holds, Julia transfers the coins deposited by Bob (at 4th step) to Alice. And Bob can learn $r$ from blockchain at the moment when Alice reveals it. Bob does the decryption: $m = m'-(z-r)/e$ to get the data chunk finally.

Security proofs are not hard for this tiny protocol. But designing a realistic one is challenging.

If $m$ is larger, zkPoD uses vector Pedersen commitments, with batched zero-knowledge proofs. (groth09)

One of the tricky parts is how to reduce the computation of verification on the blockchain. The computation is extremely expensive. In this tiny version, Julia does only one exponentiation, which is acceptable. But if $m$ is large, the gas cost on the blockchain is the most important issue. Also, the security of the blockchain is quite complicated. The protocol has to regard various attacks that happened on Ethereum, like "stuffing attack", "front-running attack", "transaction reentrant attack" etc.

ZKCP, ZKCSP use zkSNARKs mainly in their protocols.

Fairswap is another work showing a different approach, where Bob the buyer has to show a fraud-proof to Julia showing Alice was cheating. This approach is much more efficient than ZKCP/ZKCSP for large data.

zkPoD is a new project to make the protocols practical to deliver large data (many GBs, even TBs). See the repo for more documents.

  • $\begingroup$ Thank you for your answer, but I have one question. In 7th step, how can you be sure that Alice will reveal randomness r after Alice received coins? $\endgroup$ – Sober Jul 21 at 8:55
  • $\begingroup$ Another question, how could Bob know the data m that Alice have is valid? $\endgroup$ – Sober Jul 21 at 9:29
  • $\begingroup$ Alice reveals r, Julia verifies r and then Julia gives coins to Alice if r is correct. Before the protocol, Bob gets the g^m that is the "tag" of the data. Bob's verification at 4th step ensures that Alice has the data m (other than a different x). The protocol can be proved "sound" saying that Alice must have had the correct m. $\endgroup$ – szgy Jul 21 at 9:39
  • $\begingroup$ In your description, that smart contract acts as a trusted third party. I highly doubt it works like that. $\endgroup$ – tylo Jul 21 at 14:55
  • $\begingroup$ @tylo The smart contract indeed works as a trustless third party. It doesn't violate the research result of the impossibility of two-party-fair-exchange. Any ideas? $\endgroup$ – szgy Jul 23 at 6:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.