Ben Fisch and Dan Boneh 1 Batching Techniques for Accumulators with Applications to IOPs and Blockchains Stanford Blockchain Conference Formerly BPASE Conference Jan 30 Feb 1 2019 three days ID: 752434
Download Presentation The PPT/PDF document "Benedikt Bünz Joint work with:" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Benedikt BünzJoint work with: Ben Fisch and Dan Boneh
1
Batching Techniques for Accumulators
with Applications to IOPs and BlockchainsSlide2
Stanford Blockchain Conference(Formerly BPASE)Conference: Jan. 30 - Feb 1, 2019. (three days)Only technical submissionsSubmission: October 16th, 2018
https://cyber.stanford.edu/sbc19Videos: https://tinyurl.com/bpasevideos
Part of the Stanford Center for Blockchain Research (@
CBRStanford
) Slide3
UTXO Set: A Growing Problem3Slide4
UTXOs4
trans: H( )
prev
: H( )
trans: H( )
prev: H( )
trans: H( )
prev: H( )
UTXO
Look up TXO from head:
O(n) block headers (O(log(n) with
Flyclient
)
Look up UTXO:
All transactionsSlide5
UTXO Commitments [Miller,Todd,Dryja,…]5
trans: H( )
prev
: H( )
trans: H( )
prev: H( )
trans: H( )
prev: H( )
utxos
: H( )
utxos
: H( )
utxos
: H( )
Consensus ensures:
All UTXO committed hereSlide6
Merkle Trees6
trans: H( )
prev
: H( )
utxos
: H( )
H( ) H( )
H( ) H( )
H( ) H( )
UTXO
UTXO
UTXO
UTXO
Inclusion: O(log(n))
Exclusion: O(log(n))
1
Update: O(log(n))
1
If sortedSlide7
Stateless Full Nodes/Mining7
trans: H( )
prev
: H( )
trans: H( )
prev: H( )
trans: H( )
prev: H( )
utxos
: H( )
utxos
: H( )
utxos
: H( )
TX:
Spend UTXO 426
Proof:
Looks goodSlide8
Problems with Merkle TreesLog(n) inclusion proof per transactionInclusion proofs can hardly be aggregated 600 GB naïvely160 GB with many optimizationsVerification not that cheapFull node sync too slow Proposed for only old transactions
8Slide9
RSA Accumulators [CL02 …]9
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
=
Slide10
Accumulator Proofs10
InclusionProof(A,x):
Computed using trapdoor(
p,q
) Or
Verify
(
)
Exclusion
(
)
)=1 See [LiLiXue07]
Efficient stateless updates:
[LiLiXue07]Slide11
RSA = Trusted Setup?11
N=p*q, p,q unknown
Efficient delete needs trapdoor
You can find Ns in the wild (Ron
Rivest
Assumption)Slide12
Class Groups [BW88,L12]12
No trusted setup
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
Slide13
RSA Accumulator State of ArtPositivesConstant 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?
This work
Aggregate/batch inclusion proofs (many at cost of one)
Stateless deletes
Faster (batch) verification
13Slide14
Aggregate Inclusion Proofs14
:
All inclusion proofs per block: 1.5kb
All inclusion proofs ever: 160GB -> 1.5kbSlide15
Delete with trapdoor():
Delete with inclusion proof
(
)
;
BatchDelete
(
)
Compute
s.t.
Stateless Deletion
15
No State,
no Trapdoor,
asynchronous
Using knowledge of p, q
Slide16
Too slow?Openssl 2048 bit RSA:219 updates per secondVerification/Full sync would be problematicClass groups: No good benchmarks yet
16Slide17
Peggy
Victor
y
Random
bit prime
Computes
q,r
s.t.
and
Computes
Checks:
Wesolowski
Proof
[Wesolowski’18]Slide18
Peggy
Victor
y
Random
bit prime
Computes
q,r
s.t.
and
Computes
Checks:
Proof of Exponentiation (
PoE
)Slide19
PoE Efficiency19
Direct Verification:
PoE
Verify:
Exponentiation in
vs. 128 bit long-division:
5000x difference for 128 bit security
Slide20
Fast Block Verification20
Header:
TXs: Spent s, new N
BLS
Remove s
Add N
Verify
Verify
PoE
(
)
PoE(
)
Slide21
Performance21Macbook, Java
BigInteger, JDK Hash
Merkle Tree: 26 x SHA-256:
8.5
s
Add:
g
x
mod N, |x|=256 bit |N|=3072:
1535
s
Verify: x
mod l, |x|=256 bit |l|=128 bit
0.3 s
Classgroups?Slide22
Peggy
Victor
y
Random
bit prime
Computes
q,r
s.t.
and
Computes
Checks:
Proof of Exponentiation (
PoE
)
V knows xSlide23
Peggy
Victor
y
Random
bit prime
Computes
q,r
s.t.
and
Checks:
Knowledge of Exponent (
PoKE
*
)
g is encoded in CRS
rational ->
Slide24
Peggy
Victor
Random
bit prime
Computes
q,r
s.t.
and
Checks:
Knowledge of Exponent (
PoKE
)Slide25
Vector Commitments25VC=Commit( )
Open(VC,
)
Verify(
Classical VCs:
Linear CRS
New VCs:
Constant CRS, batch openings
Built from
PoKE
and batch proofs
Merkle trees are VCs not just
accums
!Slide26
Short IOPs (STARKs etc.)26
MT=Commit( )
Long Proof
and Merkle Paths
Slide27
Short IOPs (STARKs etc.)27
VC=Commit( )
Long Proof
and 1 VC Opening
200kb
vs.
600kbSlide28
A Unicorn Walks Into A Bar…28A
ccumulators, Unions, Wesolowski,
I
OPs,
A
ggregation and
B
lockchainsSlide29
ReferencesCL02: Camenisch Lysanskaya 2002 Dynamic AccumulatorsLiLiXue07: Li, Li, Xue 2007 Universal AccumulatorsCF: Catalone Fiore: Vector CommitmentsTodd:
https://petertodd.org/2016/delayed-txo-commitments#further-workMMR: https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.mdUTXO: https://bitcointalk.org/index.php?topic=101734.0
BW88: Buchmann and Williams
29