The document discusses the use of zero-knowledge proofs (ZKPs), particularly zk-SNARKs and zk-STARKs, for scaling Ethereum through Layer 2 solutions. It explains how zk-SNARKs allow efficient, verifiable off-chain computations and outlines various Layer 2 scaling techniques that can achieve high transaction speeds while maintaining security. The document also highlights ongoing research and future directions in the field of ZKPs, including potential enhancements and the integration of zk-STARKs for improved performance and transparency.

1. Scaling Ethereum on Layer 2
using Zero-Knowledge Proofs
Hyojun Kim
Core Developer

2. About the Speaker
Airbloc Core Developer / Research Lead
Blockchain Engineering
Cryptoeconomics Research
Project Management
Hyojun Kim

3. Table of Contents
1. What is Zero-Knowledge Proof?
2. zk-SNARKs
3. Layer 2 Scaling using zk-SNARKs
4. Using SNARK on Ethereum
5. Going Future: zk-STARKs

4. What is Zero-Knowledge Proof?
Have you heard about…

5. Prover System
Prover
Computes some task
and conviences a verifier
Verifier
Verifies that the prover
done his job correctly
Proof
Knowledge

6. What If Verifier Steals a Knowledge?
Prover
I've finished my job!
Here is proof data.
Verifier
Leaks Knowledge
(e.g. Input Data)
Proof
Knowledge

7. Zero-Knowledge Proof System
Prover
I've finished my job!
Here is proof data.
Verifier
Only able to know
that the proof is true
Proof
Knowledge

8. Famous Use Case In Blockchain?

9. Zcash
Powered by zk-SNARKs

10. Zero-Knowledge
Succinct
Non-interactive
ARgument of
Knowledge
zk-SNARKs

11. Y = C(x, w)
How zk-SNARK works?
zk-SNARK How it works · Example · Succinctness

12. Y = C(x, w)
Public
Output
How zk-SNARK works?
Public
Function
Public
Input
Secret
Input
zk-SNARK How it works · Example · Succinctness

13. C is for Circuit
• We need to code public function C using only Arithmetic Circuit
• This circuit representation is called
R1CS (Rank-1 Constraint System)
• We cannot apply zkSNARK to
every general computation problems.
zk-SNARK How it works · Example · Succinctness
Y = C(x, w)

14. Setup: (C, ) → (pk, vk)
Prove: (pk, x, w) → Proof
Verify: (vk, Proof, x, y) → Bool
How zk-SNARK works?
zk-SNARK How it works · Example · Succinctness

15. zk-SNARK How it works · Example · Succinctness
Prove: (x, w) → Proof
Verify: (Proof, x, y) → Bool
How zk-SNARK works?
There is no w on verify!
= Zero-Knowledge

16. zk-SNARK How it works · Example · Succinctness
Example: Anonymous Transaction
// C is R1CS circuit.
function C(private txData, public txHash) {
return checkTx(txData)
&& txHash == sha3(txData);
}
// x = public txHash, w = private txData

17. Succinctness
VerificationTime < RunningTime
zk-SNARK How it works · Example · Succinctness
Characteristics of zk-SNARK

18. Succinctness
• Verify much more quickly than re-computing C again.
• SNARK is so succinct that proof is verifiable on Smart Contracts
• Run heavy computations in off-chain
• Verify it on-chain
• You can even hide the inputs (Remember x, w?)
zk-SNARK How it works · Example · Succinctness

19. Succinctness: Meaning
Layer-2 Scalability
Verifiable Off-chain Computation on-chain
Proof Aggregation
Aggregate N proofs into 1, then verify only 1 proof!
Succinctness can be used to scale blockchains
zk-SNARK How it works · Example · Succinctness

20. Layer 2
Scalability Solutions
Using zk-SNARKs

21. Vitalik's Mass Tx Validation (~500TPS)
• Construct two merkle tree: Address Book, Account Tree
[ address ] [ balance, nonce ]
accountRootaddressRoot

22. • Relayer aggregates transaction from users.
• Relayer submits new accountRoot with aggregated SNARK proofs.
• Contract verifies it and update the accountRoot.
[ balance, nonce ]
accountRoot
[ balance, nonce ]
accountRoot
zk-SNARK Proof
nonce check
balance check
signature check

23. roll_up / roll_back Sidechain (~17,000 TPS)
• Leverage Data Availability problem by Priority Exit Queue
• If the operator fails to serve exit queue in the time limit,
it is assumed that the data is unavailable.
• SLASH and find another operator in Operator Auction
• Automatically roll back the chain to the previous state
• Subjective Data Availability → Saving GAS 😎

24. roll_up / roll_back Sidechain (~17,000 TPS)
• Use Perdesen Commitments (Sha256 is expensive 🤢)
• Using Wu et al. 2018 (Distributed Zero-Knowledge Proof System),
We can aggregate 16,666 transaction into one SNARK
• Verify cost: 500,000 GAS
• Therefore, 8,000,000 GAS LIMIT / 500,000 GAS / 15 sec
• = About 17,777 TPS

25. Plasma Snapp: Fully Verified Plasma
• No UTXO, No Exit Game, No Confirmation Signatures
• Less attack vector for fraud operators.
• Uses Account Model
• However, There are weak data availability assumptions
• To exit, the account should have no Txns for last 7 days.

26. Is it possible to use SNARK on ?

27. Using SNARK on Ethereum
• Byzantium Fork added support ECC Math on alt_bn256!
• We can do ECC Arithmetic by CALLing Precompiled Contracts:
• 0×06 : ECADD
• 0×07 : ECMUL
• 0×08: ECPAIRING
• Allows feasible SNARK Verification on Ethereum

28. Easy SNARK Library: ZoKrates
• Compiles R1CS Circuit
• Generates Verifier Contract
• Computes Witness (Private Input)
• Generates Proof
• Verify with Smart Contracts
• 1 LINE!

29. ZoKrates Example:
Adding Numbers
• Prove number addition task
without leaking any data
• Prover computes number
and generates proof
• It will be verified on-chain
through generated
Verifier.sol
$ cat add
def main(field sum,
private field a,
private field b) -> (field):
a + b == sum
return 1
$ ./zokrates compile -I add.code
$ ./zokrates setup
$ ./zokrates compute-witness -a 3 1 2
$ ./zokrates generate-proof
$ ./zokrates export-verifier

30. However,
SNARK on

31. Current Limitations 😞
• Proving Cost is INSANE
• Verifying Cost is still not very cheap
From github.com/barryWhiteHat/roll_up

32. Solutions 1. Better Proving System
• Groth16 (On the Size of Pairing-based Non-Interactive Arguments)
• Smaller Proofs — only 40% of the previous one
• Faster Proving and Verification Time

33. Solutions 2. Better Signature
• EdDSA with Jubjub Curve
• Twisted Edwards Curve allows cheaper ECC in SNARK Circuits.
• Let's Use EdDSA instead of ECDSA.
• Safe from side-channel attacks, cheap
• After Ethereum supports BLS12-381 Curve,
Jubjub will be much cheaper.

34. Solutions 3. Better Hash Functions
• SHA256 is cheap on Ethereum, But expensive for R1CS Circuits
• Since Keccak is based on Boolean-Circuit,
There are too many constraints
• ~ 25000 Constraints per SHA256!!
• How about using polynomial hash,
optimized for R1CS (and SNARKs)?

35. Solutions 3. Better Hash Functions
• Pedersen Commitment
• 3000 constraints per hash — 88% Cheaper than SHA256
• Used in Zcash Sapling
• MiMC (Albrecht et al. 2016)
• 800 constraints per hash— 97% Cheaper than SHA256 👀
• Security Audit is on progress.

36. Ethsnarks: Combining Altogether
• Reduced cost (500,000 gas for 1 input)
• Prove zkSNARK in browser using WebAssembly
• Various Gadgets support
• Jubjub, EdDSA, Pedersen Hash, MiMC, Keccak256…
• Solidity, Python, C++ Support
• Supported by Ethereum Foundation

37. Going Future: STARK
• Problem of the zk-SNARK:
• Trusted Setup : Information used on Parameter generation on
setup phase should be destroyed.
• Heavy Proving Cost
• Complicated ECC Cryptography
• No Quantum Resistency

38. Going Future: STARK
• Scalable Transparent ARguments of Knowledge
• No Trusted Setup : More safe and transparent!
• Scalable Proving Time : Quasi-Linear Proving Time!
• No ECC, Only Polynomial : Simple, Post-Quantum Security
• For more explaination, please read Vitalik's Article

39. Ethereum 💜 STARK
• Currently researching at STARKware
• Founded by authors of the zk-STARK paper
• Shasper v2.1 Spec : Hash function will be chosen by STARKware
which will be STARK-friendly function.
• Funded by Ethereum Foundation, Zcash, Bitmain and Vitalik.

40. Ethereum 💜 STARK
• Eventually, Ethereum 2.0 is going to use STARK
to prove the state transition proofs in shards.
• Other usages:
• VDF (Verifiable Delay Function) in MiMC + STARK
• Signature Aggregation on Casper using STARK

41. P.S. Airbloc 🔥 ZKP
• We use ZKP for protecting user's data privacy,
using Anonymous ID (ANID) System
• For us, being tracked by Identifier can be also privacy threat.
• We research SNARKs for Plasma
• We're also hiring Blockchain Engineers! abr.ge/ueaerh 💼

42. Thank you!