Shielded CSV 🛡️

Private and Efficient

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.
  • 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, ...).

Toy CSV: 🐸 Issuance

👩‍🌾

Ivy: 2 sat

Transaction 1

Ivy

the Issuer

On-Chain

Off-Chain

Ivy: 10 🐸

Transaction 1

Sign("I issue 10 🐸-coins in transaction 1, output 1. Redeemable for physical frogs.")

Toy CSV: Transaction

👩‍🌾

Ivy: 2 sat

Transaction 1

Ivy

the Issuer

On-Chain

Off-Chain

 Ivy:  1 sat

 Roy: 1 sat

Transaction 2

Roy

the Receiver

🧑‍🎤

Ivy: 10 🐸

Transaction 1

 Ivy:   3 🐸

 Roy: 7 🐸

Transaction 2

"Coin Proof":

Transaction graph connecting Roy's output to an issuance transaction

Comparing CSV

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. Derive short piece of data ("nullifier") from the CSV transaction.
  2. Post nullifier to blockchain to prevent double-spending.

Taking CSV seriously

  • Toy CSV: nullifier is Bitcoin tx
  • Shielded CSV: nullifier is 64-byte blob

Post-quantum

non-interactive publishing

prunable wallet state

PCD

Payment Channels

MEVil

TS-Accumulator

Instantiation

Light clients

Reorgs

Sign-to-Contract Schnorr Half-Aggregation

<REDACTED>

█ █ █ █ █ █ █ █

ᗰᗩᗪᑎᕮᔕᔕ ᗯᗩITᔕ

64-byte nullifier

Private and Efficient CSV

Communication Channels

Client-Side Validation Model

Accounts

mempool

🚢

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!

  • Problem: Insecure! Anyone can nullify any coin.
    • Solution: Add signature to nullifier.
  • Inefficiency: One nullifier per spent coin.
    • Solution: Introduce "accounts", a special type of TXO.
    • Result: one nullifier per account state update that can spend an arbitrary number of coins.

  • Problem: Posting nullifiers requires a dedicated on-chain tx.

    • Solution: Publishers collect nullifiers and post them all at once with a single on-chain tx. Anyone can become a publisher.

Towards 64-bytes Nullifiers

AggNullifier := (Nullifier_PubKeys, AggSig)
Nullifier := (Nullifier_PubKey, Signature)
Nullifier := (Nullifier_PubKey, TxHash, Signature) 
Nullifier := (Nullifier_PubKey, TxHash)
Nullifier := (CoinID, TxHash)

(insecure, one nullifier per coin)

(insecure, one nullifier per tx)

128 bytes

96 bytes

64 bytes

Accounts

Signature

Sign-To-Contract

Signature Half-Aggregation

👩‍🚀

🧑‍🎤

Coin, Coin Proof

👷

Tx := (AcctState, Coins,
       NewAcctState, NewCoins)

Nullifier

AggNullifier

...

Block i + 1

Block i

Block i + 2

aggregates & publishes

reads & verifies aggregate sig

<...> <...>
<...> <...>
  • 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

Proof-Carrying Data (PCD) [2010]

  • πᵢ: proof that the entire preceding computation graph is correct.
    • Size and Verification time independent of graph size.
    • Zero-Knowledge for incoming inputs and and outputs.
  • PCD can be instantiated with recursive SNARKs or Folding schemes.

🖥️

🖥️

🖥️

Local Input

Local Input

Local Input

Output

Output

Output

Output

, π₁

, π₂

, π₃

, π₄

Proof-Carrying Data (PCD) [2010]

🖥️

🖥️

🖥️

Local Input

Local Input

Local Input

Output

Output

Output

Output

, π₁

, π₂

, π₃

, π₄

  • 🖥️: Shielded CSV transaction
  • Output: Account state or coin
  • Local Input: Account update proofs, etc
  • πᵢ: Coin proof

Shielded CSV Coin Proofs

👩‍🚀

Local Input

AcctState

Coin

AcctState

Coin

, π₁

, π₂

, π₃

, π₄

🧑‍🎤

  • Coin proof π₄ proves to Roy that all transactions are correct and have been nullified
    • succinct and ZK
  • Why PCD? Framework abstracts away some of the complexity.

Shielded CSV is ...

  • an instantiation of PCD,
  • the definition of correct computation in PCD,
    • we specify this in Rust,
  • a spec for how the nullifier key-value store is updated.

This was just a tiny glimpse of the paper

  • Blockchain reorganizations
  • "Trustless" Publishing & Fees
  • Security definitions of the primitives (accumulators, etc.)
  • t-of-n Shared Accounts
  • Atomic Swaps
  • Wallet State
  • Nullifier Accumulator based on Merkle Tree of Merkle Trees
  • ...

Future Work

  • More complete specification & test vectors
  • Instantiation of primitives
  • BitVM (?) Bridging
  • Communication channels / UX
  • Other drawbacks of CSV paradigm?
  • "mempool"
  • Efficient timelocks
  • Payment channels
  • Light clients
  • Scriptable spending policies
  • ...

shieldedcsv.org