You’ll notice that I’m not addressing arbitrary computation, but only a subset of what the EVM can implement; any use case that can be expressed as a “token” ownership problem fits what I’m going to cover. There are interesting projects in the space targeting arbitrary computation but for now, they are either making strong hardware assumptions (Enigma), compromising on privacy (TrueBit) or breaking key blockchain properties (Quorum — no consensus on the private state).

Zcash

The Zcash protocol offers a very elegant solution to the challenge of private token transfer by using zkSNARKS to enforce the guarantees. The forthcoming network upgrade (Sapling, Oct 2018) makes the protocol computationally affordable and gives us the tools to implement accountable privacy.

In Sapling, the zkSNARK circuits are simplified and the new protocol uses Pedersen commitments, like Mimblewimble or Bulletproof, to ensure legality of a transaction. Cryptographic keys that allow their owner to sign proofs and view incoming and/or outgoing transactions can now be derived from a spending key. In other words, we can set up a powerful machine to (pre*)compute zkSNARKs that will have no access to the cryptographic key needed to sign and authorize a spending transaction.

For a deep dive, the very well-written Zcash protocol specification is a must-read.

Zcash on Top of Ethereum

Baby ZoE and Quorum ZSL are previous efforts to marry Zcash to Ethereum by verifying zkSNARKs with a precompiled smart contract.

Walking the Mainnet-path is, I think, challenging at the moment. Not only is the gas cost prohibitive (1.5M gas to call the altbn128 precompile is $3 per transaction in fees), but Mainnet upgrades are slow. For example, Zcash 2.0 uses a new elliptic curve, making the existing precompile virtually useless for us. Writing a safe and complex cryptographic scheme in Solidity is also bumpy; battle-tested crypto-libraries are still works in progress and I think the development environment is just not mature enough yet.

Zcash has its own addressing system which its privacy properties depend on: a note with a paying (public) key is spendable by whoever holds the spending (private) key, and spending a note does not reveal in which transaction the note was created.

Here is the thing: the Ethereum protocol does not guarantee unlinkability of transactions and will therefore break this privacy property. Ethereum forces us to disclose information about the sender as they need to cryptographically sign a transaction and pay for gas. An adversary can trace the origin of the account funds (needed to pay the gas) and group accounts, transactions, and identities, ultimately defeating a key purpose of the privacy scheme, which is to provide anonymity.

That holds true for any layer 2 privacy scheme we could implement on top of the Ethereum protocol, so we first need to address the gas issue.

How to Make Ethereum “Neutral” Privacy-Wise

We seek indistinguishability between transactions, so that the Ethereum protocol remains “neutral” privacy-wise on our layer 2 scheme. To achieve that, I see two categories of solutions: the ones that don’t modify the protocol and the ones that do.

Option 1: Don’t Modify the Protocol

For solutions that don’t touch the protocol (what we can implement today without forking Ethereum) the general intuition is that we’re going to use Ethereum accounts exactly once. That is, we’re never going to sign multiple transactions with the same key-pair.

On a private network we can achieve that through:

setting the gas price to 0

an “indirection oracle”: participants would trust a party to sign transactions on their behalf.

or a faucet: participants would send an off-chain request to fund their one-time accounts.

Setting the gas price to 0 would have a nasty side-effect: we would lose our built-in permissioning/spam-prevention system. Any party with access to the network can locally create a key-pair, transact “for free,” and spam the network.

I would favor the faucet over the indirection oracle. The oracle can hurt performance and fairness; it’s a bottleneck-prone architecture and an adversary in control could delay some transactions and prioritize their own.

The faucet and the indirection oracle are both centralized pieces. I think that it is “ok” to use a centralized service, as long as we don’t need to trust it and that it does not enable a party to collect identifying information about accounts. We can overcome these issues through ring signatures, a technique used by Monero and various coin mixers.

Option 2: Modify the Protocol

By modifying the Ethereum protocol, we can develop more satisfying solutions, like “account abstraction,” an upgrade that will enable smart contracts to pay for gas.

It is important to note, however, that if the transport layer is not obfuscated (onion routing a la Tor), a powerful adversary could map timestamps, IPs, and account funding transactions on the blockchain.

The PegaSys Privacy R&D Team

Accountable privacy remains a challenge for the Ethereum ecosystem. The PegaSys Privacy R&D Team is leveraging smart contracts to extend the Zcash protocol and build a secure framework on Ethereum that enables users to define rules and reason about “private” data.

If you’d like to know more or join this effort, please reach out through our contact form. Also follow us on Twitter at @PegaSysEng to stay tuned for updates on our protocol engineering team’s progress.