ETHWaterloo Vitalik Speech about privacy in Ethereum

What it does

Confidential transactions governed by a smart contract with minimal available proofs.

How we built it

Hard work of the BANKEX core team for 2 days. Use reference Java implementation of Bulletproofs by Stanford and implement a set of verifying smart contracts.

Challenges we ran into

An effective more common language port of prover is required for wider adoption. Although lack of strong typization in java script makes porting of an algorithm a pain. In some cases, you don't want to enclose yourself during blockchain operations.

Let's show an example on one of the base smart contract implementation: the voting process. Sometimes during making your election choice you don’t want to disclose yourself.

Accomplishments that we're proud of

In all the primary smart contracts lack of anonymity and we didn’t find a typical example, how to do that. So we decided to challenge ourselves and solve this task. We implemented in smart contract concept, that was proposed by Benedikt B¨unz from Standford. It based on Bulletproofs concept: provide short zero-knowledge proofs.


Reference algorithm and motivation can be found here

As described by authors of this paper, confidential transactions protocols require proof that transaction amounts under Peddersen commitments are strictly non-negative, otherwise creation of the coins out of the thin air is possible.

Bulletproofs are logarithmic in size, although require linear number of scalar multiplications on a curve for verification. So a proof that some set of size M of committed and blinded values Xs that are in range [0, 2^N - 1] has size of 2(log2(N) + log2(M) + 4) field elements and 5 scalar elements and number of verification operations in linear in N and M. Scalar multiplication operations are the most expensive part of verification in Ethereum smart contract as the precompiled scalar multiplication contract consumes 40000 gas per operation ( This price is the main limitation for extending confidential transactions to full precision of 256 bits. We hope that next forks of Ethereum will decrease the cost of cryptographic operations on BN256 curve and many solution will be limited by it, including zkSNARKs.

What we learned

What's next for Bulletproof Confidential Transactions

What should be improved

  • Right now withdraw reveals another output of the mixing transfer 1) On deposit C = value_in * G + 0 * H. 2) On transfer C = value_in * G + 0 * H = v_out1*G + blinding_1 * H + v_out2 * G + blinding_2 * H. This implies blinding_2 = q - blinding_1, where q is BN256 group order. 3) Withdraw reveals v_out1 and blinding_1, so value v_out2 is releaved as value_in is public and blinding_2 is revealed. For test contract this issue is mitigated by requirement of sending transactions from corresponding beneficiary addresses, but better solution should be found (similar to Mimblewimble). 4) Additional blinding of input should be used C' = value_in * G + secret * H.
  • Some form of stealth addresses. Right now users have to communicate off-chain to send secret values to each other (related to the issue above).
  • Add merge functionality, that is trivial and doesn't require range proofs (up to the extent that user should take care of not overflowing by himself, otherwise he looses a lot).
  • Batch validation of range proofs (as suggested in original paper). Separate validation of M proofs (as done right now) as a size of 2M(log2(N) + 4) field elements and 5*M scalars, while batched verification will reduce is to 2(log2(N) + log2(M) + 4) field elements and 5 scalars.
  • Find an optimum for range/gas price. Usage of such mixed can be economically efficient only for high transaction values (let's say > 100 ETH), so making it in range of [0, 65635] with denominator of 0.1 ETH should be efficient.
  • Porting an algorithm to JS to allow generation of proofs on wide range of devices.
  • An inclusion of "account abstractions" in next releases of Ethereum will allow to make process even more convenient without revealing a sender.
Share this project: