Stateful and Stateless Consensus Mechanisms in Blockchain: A Comparative Study

1. Accumulatorsand the Separation of Consensus and State Benedikt Bünz Joint work with Ben Fisch, Dan Boneh Blockchain Conference CMSA, January 2019

2. Stateful Consensus {A} A {A} {A} {A}

3. Stateful Consensus {A, B} {A} B {A} {A, B} {A} {A, B} {A} {A, B}

4. Stateful Consensus {A, B, C} {A, B} C {A, B} {A, B, C} {A, B} {A, B, C} {A, B} {A, B, C}

5. Stateful Consensus {A, B, C} Efficiently compare datasets? h h h {A, B, C} {A, B, C} h h = Hash(A | B | C) Blockchain: ht+1 = Hash(C | ht) {A, B, C}

6. Bitcoin State: A Growing Problem

7. Stateless verification {A, B, C} Verify other nodes agree on same sequence of updates? {A, B, C} {A, B, C}

8. Stateless verification {A, B, C} D X Stateless node can’t participate in consensus with rules… X ? {A, B, C} X {A, B, C}

9. Stateless consensus h3 D X X X h3 h3 X h3

10. Stateless consensus h4 h3 E How can nodes check validity of update? h4 h3 h4 h3 h3 h4

11. Consensus and State State Update + Proof Consensus State storage Checks proof and updates state Provides proofs

12. Stateless consensus h4 h5 How is the proof generated? Does it require state? F, Proof h4 h5 h4 h5 Who generates the proof? h4 h5

13. State design: Accounting Systems Key/value store Accounts[id] = balance Update Vector commitment h = Commit(Accounts) Accounts: id1, id2 Balances: b1, b2 Proof Transaction Proof h = Commit(Accounts) Accounts[id1] = b1 Accounts[id2] = b2

14. Vector Commitments [CF13, LRY16] Short VC=Commit( ) Open(VC,) Verify( Constant size Linear params Merkle trees Catalano-Fiore VCs Examples:

15. Stateless consensus h4 Head contains vector commitment to state Update Accounts Balances h4 h4 Proof Vector commitment opening h4

16. Bitcoin UTXOs Unspent transaction outputs (Coins) UTXOs TXOs Transaction

17. Bitcoin UTXOs Miners agree on UTXO set S Accumulator h = Commit(S) UTXOs TXOs Proof Transaction Proof h = Commit(S) UTXOs S

18. Accumulators [Bd94, CL02] Short Membership Witness Add() InclusionProof Verify( Constant size Merkle trees RSA Accumulators [CL02] Pairing-based accumulators [NG05] Examples:

19. UTXO Commitments [TMA13] prev: H( ) prev: H( ) prev: H( ) trans: H( ) trans: H( ) trans: H( ) utxos: H( ) utxos: H( ) utxos: H( ) Consensus ensures: All UTXO committed here

20. Merkle Trees utxos: H( ) prev: H( ) trans: H( ) Inclusion: O(log(n)) Exclusion: O(log(n))1 Update: O(log(n)) 1 If sorted H( ) H( ) H( ) H( ) H( ) H( ) UTXO UTXO UTXO UTXO

21. Stateless Full Nodes/Mining prev: H( ) prev: H( ) prev: H( ) trans: H( ) trans: H( ) trans: H( ) utxos: H( ) utxos: H( ) utxos: H( ) Looks good TX: Spend UTXO 426 Proof:

22. Membership Witnesses (store 1 witness per utxo) 100M UTXOs 100 GB x100 communication Accumulator Merkle tree witnesses Membership witnesses

23. Membership Witnesses Desiderata • Short membership witness per item • Efficiently updatable (storage + computation) • Efficient verification • Aggregate witnesses? • Batch generate & verify? Membership witnesses

24. RSA Accumulators [CL02, LiLiXue07] • Setup: • Choose N=pq where p, q are secret primes • : Hash function to primes in [0, ] • (initial state) • Add() • Del() State after set S added: u=

25. Accumulator Proofs • InclusionProof(A,x): • Computed using trapdoor(p,q) Or • Verify() • Exclusion() • )=1 • Verify Efficient stateless updates to (non)-membership witnesses: [LiLiXue07]

26. RSA Accumulator State of Art Positives • Constant size inclusion proofs (000 bits) Better than Merkle tree for set size > 4000 • Dynamic stateless adds (can add elements w/o knowing set) • Decentralized storage (no need for full node storage) • Users maintain their own UTXOs and membership proofs Room for improvement?New work • Aggregate/batch inclusion proofs (many at cost of one) • Trapdoor free (no trusted setup) • Stateless deletes • Faster (batch) verification

27. Batching Techniques for Accumulatorswith Applications to IOPs and Blockchains Joint work with: Ben Fisch and Dan Boneh https://eprint.iacr.org/2018/1188

28. Aggregate Membership Witnesses : All membership witnesses per transaction block: ~3000 bits

29. RSA = Trusted Setup? N=p*q, p,q unknown Efficient delete needs trapdoor You can find Ns in the wild (Ron Rivest Assumption)

30. Class Groups [BW88,L12] CL(Δ) - Class group of quadratic number field (a large random prime) • Properties • Element representation: integer pairs • Tasks believed to be hard to compute: • Odd prime roots Group order • 128 bit security No trusted setup

31. Stateless Deletion • Delete with trapdoor(): • Delete with inclusion proof() • ; • BatchDelete() • Compute s.t. Using knowledge of p, q No State, no Trapdoor, asynchronous

32. Verification of Witnesses Too slow? • Java Big Integer Microbenchmark: • 600 exponentiations per second (256 bit exponents) • Verification/Full sync would be problematic (On my laptop) • Class groups: No good benchmarks yet

33. Wesolowski Proof [Wesolowski’18] y Peggy Random bit prime Victor Computes q,rs.t. and log(T) mults mod Computes Checks:

34. Proof of Exponentiation (PoE) y Peggy Random bit prime Victor Computes q,rs.t. and log() mults mod Computes Checks:

35. PoE Efficiency Both linear in bitlength PoE Verify: Direct Verification: Much faster Exponentiation in vs. 128 bit long-division: 5000x difference for 128 bit security

36. PoE Assumption Adaptive Root assumption: For all efficient adversaries Given will produce With only negligible probability can’t have any element of known order other than 1 -> We need to work over Classgroups seemingly satisfies this property

37. Fast Block Verification Header: TXs: Spent S, new N Signatures BatchDelete Verify Verify PoE for BatchDel Verify PoE for BatchAdd BatchAdd

38. Performance Macbook, Java BigInteger, JDK Hash Merkle Tree: 26 x SHA-256: 8.5 s >100,000/s Add: gx mod N, |x|=256 bit |N|=3072: 1535 s >600/s Verify: x mod l, |x|=256 bit |l|=128 bit 0.3 s+50 s for primality checking ~20,000/s Classgroups?

39. Accounting Systems Key/value store Accounts[id] = balance Update Vector commitment h = Commit(Accounts) Accounts: id1, id2 Balances: b1, b2 Proof Transaction Proof h = Commit(Accounts) Accounts[id1] = b1 Accounts[id2] = b2

40. Vector Commitments VC=Commit( ) Classical VCs: Linear CRS Limits #accounts New VCs: Constant CRS, batch openings, Built from PoKE and batch proofs Open(VC,) Verify(

41. Aggregating Non Mem Witnesses • such that • such that Not smaller! • such that is size of

42. Aggregating Non Mem Witnesses • such that • Set Proof of knowledge of such that

43. Proof of Exponentiation (PoE) y Peggy Random bit prime Victor Computes q,rs.t. and V knows x Computes Checks:

44. Knowledge of Exponent (PoKE*) g is encoded in CRS y Peggy Random bit prime Victor Computes q,rs.t. and Checks:

45. Knowledge of Exponent (PoKE) Peggy Random bit prime Victor Computes q,rs.t. and Checks:

46. Vector Commitments V – a bit vector of length N For each i ---> HashPrime(i) is a unique prime Init accumulator A For all i where V[i] = 1 add HashPrime(i) to A Open(i): if i = 1 Give MemWit if i = 0 Give NonMemWit Batch MemWit and NonMemWit

47. Takeaway Points Shifting work from miners to users Distribute the storage (load balanced blockchain) Consensus State storage

48. References • CL02: Camenisch Lysanskaya 2002 Dynamic Accumulators • LiLiXue07: Li, Li, Xue 2007 Universal Accumulators • CF: Catalone Fiore: Vector Commitments • Todd: https://petertodd.org/2016/delayed-txo-commitments#further-work • MMR: https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md • UTXO: https://bitcointalk.org/index.php?topic=101734.0 • BW88: Buchmann and Williams