Scaling and Privacy
with zk-SNARKs and Client-Side Validation
Jonas Nick
Liam Eagen
Robin Linus
- 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
- 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.
- Improve privacy of Bitcoin.
- Use Bitcoin as the underlying blockchain. Requires bridge (BitVM, one-way peg, federated peg, ...).
What is CSV really?
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.
- Create CSV transaction
- Derive short piece of data ("nullifier") from the transaction.
- Post nullifier to blockchain to prevent double-spending.
- 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:
- All txs in the coin proof are valid.
-
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
Shielded CSV (BRD)
By iamjon
