1 of 35

From Zerocoin to Zcash

(and beyond!)

Matthew Green�Johns Hopkins University

2 of 35

My background

      • Prof. at Johns Hopkins University
      • Mainly work in applied cryptography�(TLS, messaging systems, privacy-preserving protocols)
      • One of the seven scientists (7S) who designed Zerocash

3 of 35

Madars Virza

Alessandro Chiesa

Ian Miers

Eran Tromer

Eli Ben-Sasson

Christina Garman

4 of 35

5 of 35

A (very short, I promise)�history of electronic cash

6 of 35

Before Bitcoin�(1980s - 2007)

7 of 35

8 of 35

e-Cash

      • Devised by Chaum, Chaum/Fiat/Naor, Brands, etc.
        • A “cash” model, with added privacy
        • Individuals carry redeemable tokens
        • Reduces the problem to detecting double spending�and user privacy

9 of 35

Chaum (CRYPTO ’83)

Payer

Bank

Merchant

Redeem/�verify not previously�spent

(Blind) signature

10 of 35

Chaum (CRYPTO ’83)

Payer

Bank

Merchant

Redeem/�verify not previously�spent

(Blind) signature

11 of 35

Why did centralized e-Cash fail?

      • Banks suck

12 of 35

Why did centralized e-Cash fail?

      • Banks suck
        • Required a trusted server with money issuing powers
        • In 1994, EU regulations made this more challenging
        • 9/11 and beyond saw closures of non-anonymous currencies (e-Gold and Liberty �Reserve)

13 of 35

Why did e-Cash fail? (2)

      • Were these technical or policy failures? Maybe both.
      • The e-Cash model was centralized and relied on a vulnerable interface with the banking system
        • Privacy was (eventually) off the table for regulators

14 of 35

Conclusions (1980s-2007)

      • Most cryptographic solutions too complex, or had “undesirable” features (privacy)
      • Commercial solutions (existing credit cards, SET) failed to support the case of person->person transfers
      • Web browsers didn’t support fancy crypto�anyway.
      • We got PayPal

15 of 35

Conclusions (1980s-2007)

      • Most cryptographic solutions were too complex, or had undesirable features (privacy)
      • Commercial solutions (existing credit cards, SET) failed to support the case of person->person transfers
      • Web browsers didn’t support fancy crypto�anyway.
      • We got PayPal

16 of 35

Conclusions (1980s-2007)

      • Most cryptographic solutions were too complex, or had undesirable features (privacy)
      • Commercial solutions (existing credit cards, SET) failed to support the case of person->person transfers
      • Web browsers didn’t support fancy crypto�anyway.
      • We got PayPal

17 of 35

The decentralized era�2008-2018

18 of 35

Nakamoto, 2008

      • Replace the server with a distributed ledger (blockchain)
      • Use a new consensus technique to construct the ledger

​

19 of 35

Nakamoto, 2008

      • Replace the server with a distributed ledger (blockchain)
      • Use a new consensus technique to construct the ledger
      • Use puzzles to handle consensus & generate funds�[Credit to Dai, (B-Cash) Back (HashCash) etc.]

​

​

20 of 35

Limitations of Bitcoin

    • Privacy limitations
    • Functionality limitations
    • Scalability & Sustainability limitations

21 of 35

Bitcoin & Privacy

Source: MPJLMVS13

22 of 35

🐵🚀

23 of 35

Zerocoin

  • Turn “basecoins” into zerocoins & back into base coins
    • Reveal a serial number for the coin &�Prove that it corresponds to some Zerocoin on the chain
    • In exchange you get one bitcoin

1.0,A->B

1.03,S->J

2.5,M->S

...

1.0,J->Z

1.0,

.9B->D

...

Block 1

Block 2

Block 3

Block 4

.23,C->E

1.2,E->J

.2,M->J

...

HASH

HASH

HASH

.23,E->F

.9,M->B

...

1.0->Z

bitcoins

bitcoins

Block 5

HASH

.23,E->F

1.0,Z->B

...

1.0->Z

823848273471012983

24 of 35

Problems with Zerocoin

  • How Zerocoin worked:
    • Used an RSA one-way accumulator
    • Accumulate to produce accumulator
    • Then prove knowledge of a witness s.t.
    • And prove knowledge that opens to the serial number

Required a DDL proof (~25kb)

for each spend. On the blockchain.

25 of 35

What could go wrong?

This wasn’t our fault!

26 of 35

Still, we wrote software…

27 of 35

Summary of Zerocoin

  • Good first approach:
    • Implemented!
    • Proofs were (too?) big
    • Coins all have the same value

28 of 35

Zerocash

29 of 35

Zerocash

  • Better, smaller ‘proofs’ of knowledge:
    • Succinct Non-Interactive ARguments of Knowledge�(zkSNARKs) (Parno et al., Ben-Sasson et al.)
      • 288 byte proof for arbitrary-sized arithmetic circuits
      • And there were C compilers!

30 of 35

How to use SNARKs

  • Start from scratch:
    • Develop an entirely new construction with small circuits
      • Modify Zerocoin to use hash functions for commitments, hash trees for an accumulator�(SHA256 for all hashes)
      • Hand-optimize everything

H(C4)

H(C1)

H(C2)

H(C3)

H(C1,C2)

H(C3,C4)

A

31 of 35

Result: Zerocash

32 of 35

But wait a second...

  • If the proofs are powerful & efficient, let’s make an entire payment system from them
    • Let’s add hidden values to the coin:
    • Create transactions to split/merge coins
    • Allow payments (from Alice to Bob) that don’t reveal value

​

1.0 ZC

.85 ZC

Mint

Split

.15 ZC

1.0 ZC

Merge

1.0 ZC

Transfer

33 of 35

34 of 35

Where could Zcash go next?

​

    • Low hanging fruit: better desktop wallets, tooling. Light wallets! Payment channels�
    • Scalability, payment channels!�
    • New proving techniques
    • Smart contracts? User-defined assets?

35 of 35

Where should Zcash go next?

Well… how did you vote?