Scaling and Privacy

with zk-SNARKs and Client-Side Validation

Jonas Nick

Liam Eagen

Robin Linus

shieldedcsv.org 🛡️

  • Shielded CSV is a transaction protocol to create an L1 on top of a blockchain that allows embedding arbitrary data  (e.g., Bitcoin).
  • It inherits double-spend security from the underlying blockchain.
  • The amount of data embedded into the blockchain is 64 bytes per transaction.
  • Coins and coin proofs are sent directly to the receiver through a private one-way communication channel.
  • Coin proofs are succinct.
  • Shielded CSV is fully private.

Summary

Blockchain (PoW, ...)

Transaction Validation

"Layer 0.5"

"Layer 1"

🛡️

Motivation

  1. A more efficient design for private cryptocurrencies
    • ZK proofs are not on the blockchain and are not verified by full nodes. Can be built on existing blockchain.
  2. Improve privacy of Bitcoin.
    • Use Bitcoin as the underlying blockchain. Requires bridge (BitVM, one-way peg, federated peg, ...).

What is CSV really?

petertodd.org, 2013

Insight: Transaction validation does not need to be part of the consensus rules.

... then transactions are only validated "client-side" and simply ignored if they are invalid.

  1. Create CSV transaction
  2. Derive short piece of data ("nullifier") from the transaction.
  3. Post nullifier to blockchain to prevent double-spending.
  4. Send rest of the data to the receiver directly

Shielded CSV recipe

👩‍🚀

Sally the Sender

Shielded CSV: Definitions

  • CSV Transaction: similar to Bitcoin transactions. Consist of inputs and outputs.

👩‍🚀

🧑‍🎤

Sally the Sender

Roy the Receiver

Coin, Coin Proof

Verify:
All txs in the coin proof

are valid.

 Ivy:   3 🐸

 Roy: 7 🐸

  • Coin: Tx output. Consists of amount & public key.
  • CoinID: Tx hash & coin index. Tx inputs contain CoinIDs.
  • Coin Proof: History of transactions connecting to issuance transactions.

Preventing Double Spending

Nullifier := (CoinID, TxHash)

🧑‍🎤

👩‍🚀

Blockchain

CoinID TxHash
<some CoinID> <...>
<other CoinID> <...>

nullifier key-value store

Embed nullifier

Process nullifiers

Process nullifiers:

Ignore nullifiers whose CoinID is already in the KV-store.

(<some CoinID>, <some TxHash>)

IGNORED by Roy

Preventing Double Spending

👩‍🚀

🧑‍🎤

Sally the Sender

Roy the Receiver

Coin, Coin Proof

Verify Coin Proof:

  1. All txs in the coin proof are valid.

  2. Every coin spent in the coin proof must be present in the KV-store and the tx hashes must match.

CoinID TxHash
<some CoinID> <...>
<other CoinID> <...>

nullifier key-value store

Preventing Double Spending

This design does prevent double spending with only a small nullifier!

(what we've seen is not the actual nullifier, because it has a number of problems)

👩‍🚀

🧑‍🎤

Coin, Coin Proof

👷

Tx := (inputs: CoinIDs,
       outputs: NewCoins)

Nullifier

AggNullifier

...

Block i + 1

Block i

Block i + 2

aggregates & publishes

processes

AggNullifier

<...> <...>
<...> <...>

nullifier key-value store

  • Problem: Coin proof includes all ancestor transactions involved in creating the coin (size?, privacy?)
  • Solution: Wrap the protocol in a  "Proof-Carrying Data" (PCD) scheme

Succinct & Private Coin Proofs

  • PCD
    • Makes coin proof size and verification time independent of transaction graph size.
    • Zero-Knowledge
    • can be instantiated with recursive SNARKs or folding schemes.

Post-quantum

non-interactive publishing

prunable wallet state

PCD

Payment Channels

MEVil

TS-Accumulator

Instantiation

Light clients

Timelocks

Sign-to-Contract Schnorr Half-Aggregation

64-byte nullifier

Private and Efficient CSV

Communication Channels

Client-Side Validation Model

Accounts

"mempool"

Reorgs

Scriptable spending policies

Atomic Swaps

t-of-n Shared Accounts

Wallet State

🐙

🦑

🦈

Comparing CSV