How Zcash Can Fill Ethereum’s Privacy Gap

PegaSys’ R&D discusses how Ethereum can use Zcash’s breakthrough Sapling release.

Crypto enthusiasts want to tokenize everything, but that’s tricky with Ethereum’s current privacy model. “Privacy” for blockchains is a catch-all and earlier this year, I wrote a primer about the variety of privacy approaches for the decentralized web. While Ethereum 2.0 focuses on scalability and proof of stake, there is a growing demand for privacy on private networks. Many projects can’t realistically take off if transactions are visible to all participants.

The privacy problem is two-fold:

1. How do we privately transfer a “token” between parties? That is, how do we keep the sender, recipient, denomination, and value of the token hidden, yet guarantee mass conservation (no double-spend) and transaction graph confidentiality (unlinkability and untraceability of transactions)?
2. If this transfer is private, how can validators (i.e the blockchain) publicly enforce business logic on it?

Ethereum is a great platform on which to implement many use cases. Voting, supply chains, compliance checks, financial products, and so much more can all be codified into smart contracts. Simple logic is straightforward: you can write rules like “if amount is bigger than constant, provision 20% taxes”. Now, if “amount” is hidden by a privacy-preserving scheme, implementing such a rule is much less intuitive, and there is no framework to do that, yet.

We need such a framework to enable accountable privacy. In other words, one wants both the goodness of the blockchain (decentralized consensus, cryptographic authenticity) and strong privacy-preserving techniques to allow confidential business deals while permitting audit and compliance checks.

I believe marrying the Zcash protocol with Ethereum is a great way to BUIDL that. Quorum ZSL (zero knowledge security layer) is a fork of Quorum (Oct 2017) which is implementing a simplified version of Zcash. The PegaSys team extracted this privacy layer in a standalone module to make it easier to integrate into Ethereum clients. In private networks, the module can be called from an EVM pre-compile contract. Here’s a demo I made using geth.

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.

Disclaimer: The views expressed by the author above do not necessarily represent the views of Consensys AG. ConsenSys is a decentralized community with ConsenSys Media being a platform for members to freely express their diverse ideas and perspectives. To learn more about ConsenSys and Ethereum, please visit our website.