E DRAX: A Cryptocurrency with Stateless Transaction Validation

Alexander Chepurnoy Charalampos Papamanthou Shravan Srinivasan

Ergo Platform and IOHK University of Maryland University of Maryland
Yupeng Zhang
Texas A&M University

Abstract a secret key to a Bitcoin address) and nodes1 that validate

transactions created by the clients. To decide if an incoming
We present E DRAX, an architecture for cryptocurrencies with
transaction is valid so that it can be included in the next block
stateless transaction validation. In E DRAX, miners and validat-
or propagated to a peer, nodes store all the history of transac-
ing nodes process transactions and blocks simply by accessing
tions so far—namely the whole blockchain. For example, if a
a short commitment of the current state found in the most re-
new transaction appears requiring 5 bitcoins to be sent from
cent block. Therefore there is no need to store off-chain and
address A to address B, a node must query the blockchain to
on-disk, order-of-gigabytes large validation state. We present
check whether A has at least 5 bitcoins in his account. Only
two instantiations of E DRAX, one in the UTXO model and one
if this is the case, this transaction is considered valid and is a
in the accounts model. Our UTXO instantiation uses sparse
candidate for appearing on the blockchain.
Merkle trees, which are very fast and require no trusted setup.
The blockchain data structure, however, is large (as of May
Our accounts instantiation uses a distributed vector commit-
2020, Bitcoin blockchain is around 280 GB and Ethereum
ment, a type of vector commitment that has state-independent
blockchain has exceeded 130 GB) and is growing contin-
updates, meaning it can be synchronized by accessing only
uously. Therefore naively querying it will simply take too
update data (e.g., send 5 ETH from Alice to Bob). Towards
long. For that reason, most cryptocurrency nodes are typically
this goal, we build a new succinct distributed vector commit-
stateful, maintaining an appropriate index called validation
ment based on multiplexer polynomials and zk-SNARKs, that
state that is smaller than the blockchain and which is enough
scales up to one billion accounts. We perform an extensive ex-
for deciding transaction validity. In some cryptocurencies
perimental evaluation comparing to other (recently) proposed
(e.g., Bitcoin, ZCash, Komodo, Monero, Ergo) the validation
approaches for stateless transaction validation, showing that
state is a set of immutable coins called UTXO (unspent trans-
sparse Merkle trees and our new distributed vector commit-
action outputs), in Bitcoin jargon. In this UTXO model, a
ment offer excellent tradeoffs in this application domain.
transaction is valid if it spends coins which belong in UTXO.
Other cryptocurrencies (e.g., Nxt, Ethereum, Bitshares, NEM,
1 Introduction Tezos) organize the validation state as a set of mutable (and
potentially long-living) accounts. In this account model, a
Decentralized cryptocurrencies and smart contracts such as transaction is valid if it is trying to spend no more tokens
Bitcoin [32] and Ethereum [4] promise to remove trusted than the available balance. Advantages and disadvantages of
online parties (e.g., banks and escrows) in sake of faster and both approaches are the focus of an ongoing debate in the
more secure financial transactions. Their underlying technol- cryptocurrency community [41].
ogy, the blockchain, is an ever-growing hashchain built on Challenges due to stateful validation. Locally maintain-
blocks of incoming transactions that is agreed upon by a dy- ing the validation state, however, is quite cumbersome. In
namic set of nodes participating in the peer-to-peer cryptocur- particular, the validation state is in the order of GBs (cur-
rency network. This ever-growing nature of the blockchain, rently the UTXO set in Bitcoin is around 3.7 GB [27] and
however, can limit the cryptocurrency scalability, not only the authenticated Patricia trie in Ethereum is around 14 GB)
in terms of storage required to store all events since gene- and could grow substantially in the coming years. For exam-
sis, but also in terms of increasing overheads for transaction ple, approximately 86,000 Ethereum new accounts/addresses
validation, blockchain verification and initial synchronization.
Most blockchain-based cryptocurrencies known to date 1 Nodes are distinguished into miners proposing new blocks and validating

consist of two kinds of parties, clients that own coins (e.g., nodes that validate and propagate transactions/blocks in the network.

1
are currently generated every day [24] and at this rate the comt comt+1
Ethereum validation state is expected to double in one year

…
from now. For a new node to enter the network, the vali- tx1 proof
dation state needs to be either downloaded and verified or

…
computed from scratch, making such synchronization an ex- Bob
tremely slow process [25] (looking ahead, our approach en- local proofs
txN proof
ables incoming miners to validate transactions instantly, by ① send txi with proof
just accessing the most recent block). Also, being in the order ④ propose block
of GBs, the validation state is stored on disk (e.g., the geth … with verified txs

…
Ethereum implementation stores the authenticated Patricia ⑤ sync local proofs
Trie using Google’s levelDB [26]), leading to slow transac- Miner
tion validation due to expensive I/Os [37]. This has facilitated Alice
② verify transactions using local proofs
various DoS attacks like the one that affected Ethereum in ③ update comt à comt+1
2016 [40], where adversarially-crafted transactions required a
large number of disk accesses causing block validation times Figure 1: E DRAX architecture. Transactions include proofs.
to reach 60 seconds! Finally, having to store such large state Miners verify transactions using the block commitment comt
to verify transactions can lead to disadvantaged miners that stored at the last block t, an updated version of which is in-
cannot dedicate large storage resources [9]. Other practical cluded in the next block t + 1. Clients synchronize their local
issues/system-level components (e.g., storage rent, sharding) proofs after the new block is produced.
that can benefit via erasure of the validation state have been
extensively analyzed [25]. Bootstrapping & storage impact. To validate incoming
transactions, a newly spawned node in E DRAX just requires
the latest block commitment. Thus bootstrapping in E DRAX
1.1 E DRAX architecture just requires downloading block headers since the gene-
We address the above by designing and implementing E DRAX, sis, which is just in MBs (This is in contrast to Bitcoin or
a cryptocurrency protocol where all nodes can check the valid- Ethereum where gigabytes must be downloaded to start veri-
ity of transactions without having to store any local validation fying transactions.) We also remark that, unlike transaction
state, i.e., validation state can be maintained, in the form of signatures, proofs are not fundamentally necessary to verify
a short cryptographic commitment, as part of the cryptocur- the E DRAX blockchain—they serve as an efficiency optimiza-
rency blocks on-chain. E DRAX comes in two versions, one tion: A miner can simply use the proof to quickly verify an
supporting the UTXO model and one for the account model. incoming transaction and later discard the proof from his local
E DRAX’s architecture can be seen in Figure 1. storage. Thus the size of the blockchain does not necessarily
increase.
Block commitment, local proofs, transactions. In E DRAX,
each block b includes a constant-size block commitment of the
current validation state (the one that includes all transactions
1.2 E DRAX for UTXO via sparse Merkle trees
up to block b). Clients, along with their coins, store short
local proofs that their coins can be spent with respect to the As warm-up, we show in Section 3 how to provide stateless
aforementioned block commitment. A local proof is included, transaction validation in the UTXO model by using Merkle
with the traditional digital signature, in an E DRAX transaction, trees. Recall that in the UTXO model, miners and validating
enabling miners and validating nodes to verify transactions nodes are maintaining a set S of unspent transaction outputs.
by accessing the latest commitment. Whenever a new transaction tx appears that has input x and
Local proofs & commitment synchronization. In E DRAX, output y, nodes must first check whether input x belongs in S,
Alice’s local proof for a coin with respect to commitment comt and if so, update set S by removing x and inserting the new
at time t will be outdated at time t + 1, after Bob’s transac- output y. Our construction represents S with a sparse Merkle
tions are incorporated in the blockchain and comt changes to tree of 2W leaves where 2W is the maximum number of out-
comt+1 . E DRAX enables Alice to synchronize her local proofs puts that can ever be generated, e.g., W = 40. (In Section 7
efficiently by accessing, from the blockchain, the updates that we suggest an optimization with less leaves using authenti-
took place between t and t + 1. (The synchronization cost cated red-black trees.) At leaf i we store the i-th transaction
can be large, in particular when Alice has been offline for output that was inserted into set S. To delete a leaf j, we just
a long time. In Section 7 where we discuss an optimization set the value of this leaf to be null. We then naturally define
using “proof-serving nodes".) Similarly, E DRAX allows min- the commitment to be the root of the underlying Merkle tree
ers to easily synchronize the block commitment from comt and local proofs as Merkle tree proofs. The above approach
to comt+1 to incorporate new transactions. The new commit- allows insertions and deletions to be performed by miners
ment will be part of the new block. and validating nodes only if the whole Merkle tree is stored

2
as commitment which is very large. In Section 3 we show vector commitments [14]—these have updates that are not
how to append a new output y to S by having nodes access state-independent (for details see Section 1.5 and Section 1.6).
only the local proof of the most recent output ever inserted Distributed vector commitments are perfect fit for imple-
in S (of size O(W )). Similarly, deletion of Alice’s spent input menting E DRAX in the account model by naturally viewing
x from S can be performed by having nodes process Alice’s account balances as a vector v and by storing C = com(v) as
local proof used to prove membership of x in S. the block commitment: A SPEND transaction is of the form
[πi , vi , i → j, δ] meaning a client i owning vi tokens wants to
send δ ≤ vi tokens to client j; Proof πi enable miners to check
1.3 E DRAX for accounts via distributed vector that δ ≤ vi ; Information i → j, δ allows miners to update C
commitments to reflect vi = vi − δ and v j = v j + δ so as to include it in the
next block—it also allows all other clients to synchronize their
In the account model, nodes maintain a vector of all account proofs πk accordingly. The detailed protocol is in Section 5.
balances which serves as validation state. Whenever Alice
wishes to send δ tokens to Bob, she posts a transaction includ-
ing this information. To verify this transaction, nodes must 1.4 New DVC via multiplexers and SNARKs
access the balances vector to check whether Alice has at least A thorough literature review of distributed vector commit-
δ tokens in her account. ments revealed several inefficiencies of existing approaches
Why Merkle trees are insufficient. One could consider us- (see Section 1.6). Therefore we design and implement a new
ing Merkle trees to provide stateless validation in the account distributed vector commitment for E DRAX—see Section 4.
model as well: Build a Merkle tree on top of the account Our construction uses the `-variate “multiplexer" polynomial
balances, define the block commitment as the Merkle digest f (x) to represent a vector of n = 2` entries. For example, the
and have the owner of account i maintain a Merkle proof for multilinear extension for the vector V = [5 2 8 3] is the polyno-
the balance at position i as her local proof. However, there mial f (x1 , x2 ) = 5·(1−x2 )(1−x1 )+2·(1−x2 )x1 +8·x2 (1−
is a fundamental problem with such an approach. Assume x1 ) + 3 · x2 x1 . Which implies that, f (0, 0) = V [0], f (0, 1) =
Alice’s balance is vA tokens and Bob’s balance is vB tokens. V [1], f (1, 0) = V [2], and f (1, 1) = V [3]. The commitment is
Whenever Alice wants to send, say, 5 tokens to Bob, Alice then computed as g f (s) , where g is a generator of an EC group
needs to include a Merkle tree proof proving her current bal- and s is a random point that is kept secret.
ance is vA ≥ 5. Once the miner verifies the proof, the miner A proof for a vector element in the above construction
can process the verified proof to efficiently update the new has size ` and takes O(`) time to verify. We reduce these
digest so as to reflect Alice’s new account balance as vA − 5. costs to constant (which translate in a significant reduction in
Unfortunately, due to the nature of Merkle trees, Alice’s local block sizes and miners and validating nodes computation) by
proof does not suffice to update Bob’s new balance to vB + 5 using a zk-SNARK on the verification algorithm. While this
as well unless Alice includes Bob’s local proof in her transac- sounds easy from a theory perspective, it is quite challenging
tion. However, this would require Alice to contact Bob and in practice since the verification computation that must be
ask for his proof every time she sends money to him which is “snarked" involves bilinear pairing operations.
not how cryptocurrencies work! (This is even worse if Alice’s Our construction finally features an O(`)-time algorithm2
transaction has many recipients.) Instead Alice should be able for synchronizing proof πi for a point i ∈ {0, 1}` given up-
to send money to Bob by accessing a fixed public address. date ( j, δ) where j is another point in {0, 1}` —see Algorithm
D ELTA P OL in Section 4.
Our approach: Distributed vector commitments. Our ob-
servation is that any instantiation of, what we call, distributed
vector commitments [17], [34], [29], addresses the above prob- 1.5 Comparison with Boneh et al. [14]
lem. In a distributed vector commitment (DVC), Alice stores a
The most closely-related work to E DRAX is the recent work
constant-size commitment C of an n-sized vector a. The vector
by Boneh et al. [14] which built RSA-based accumulators for
a itself is not stored by Alice but is distributed among n parties,
stateless transaction validation in the UTXO model. Unlike
each party holding a proof πi with respect to C, in addition to
our sparse Merkle-tree approach, their construction supports
element ai . When Alice wishes to update a vector element at
proof batching, which can drastically decrease the block size
index u by δ units, she should be able to update C to C0 easily
(For all transactions in the block, one constant-size proof is
by having access only to the information (u, δ). That is, unlike
required, while Merkle trees require one logarithmic-sized
Merkle trees, updates are state-independent. Similarly, when
proof per transaction.) Their construction can also be instanti-
party i learns about the update (u, δ), he should be able to
ated with class groups, avoiding trusted setup, as our sparse
efficiently update his proof to π0i with respect to the new com-
Merkle trees do. RSA operations and class groups are how-
mitment C0 , again only by accessing (u, δ). Distributed vector
ever costly compared to SHA-2 hashing and the practical
commitments are fundamentally different than plain vector
commitments such as Merkle trees and accumulator-based 2 Also, averaging over all j ∈ {0, 1}` the update complexity for i is O(1).

3
overhead can be large. In particular, RSA accumulators add 1.7 Implementation and evaluation
an overhead close to 17× when compared to sparse Merkle
trees. Also, when one focuses on no-trusted setup, the best In Section 6 we implement both instantiations of E DRAX and
approach for UTXO settings, then Merkle trees is a clear win- evaluate the performance. Our evaluation has three main find-
ner by a far bigger gap, since using class groups adds large ings: First, for the UTXO setting, while sparse Merkle trees
overhead (In this regime, a Bitcoin block validation has an increase the size of the block by a logarithmic factor, they sig-
overhead of approximately 18× and miners have an over- nificantly (17×) outperform recently-proposed accumulator-
head of 13600× compared to sparse Merkle trees.) Boneh based approaches [14] in terms of computation (e.g., block
et al. [14] also introduce a new vector commitment based validation), especially when compared to their equivalent no-
on their RSA accumulator construction and propose to apply trusted setup instantiations based on class groups (18×). Sec-
it for stateless transaction validation in the account model. ond, for the accounts setting, while our vector commitment
However, their vector commitment is not a distributed vector verification is slower (6s more to verify a block) compared to
commitment: To update C to C0 , Alice requires, in addition to the only other practical distributed vector commitment [17],
(u, δ), the proof πu (this is also indicated in their definition as it features a logarithmic-time algorithm (as opposed to linear)
“advice" τ). Therefore, their vector commitment is not suitable for updating local coin proofs, which translates to several
for stateless validation for accounts as we explained before. A orders of magnitude savings (5825×) from a cryptocurrency
detailed evaluation and comparison is presented in Section 6. client perspective.

1.6 Comparison to other DVCs 2 Preliminaries

Succinctly representing vectors using multilinear extensions We now give background material on bilinear maps, multilin-
was introduced by Zhang et al. [42, 43] for a different applica- ear extensions, sparse Merkle trees and vector commitments.
tion, where proofs are larger and no efficient proof synchro- Bilinear pairings. We denote by (p, G, GT , e, g) ←
nization algorithms are presented. BilGen(1λ ) generation of bilinear-map parameters, where G,
Distributed vector commitments that can be used to imple- GT are groups of prime order p, with g a generator of G, and
ment E DRAX were also introduced by Catalano and Fiore [17], where e : G×G → GT is an efficient map, i.e., for all P, Q ∈ G
one based on elliptic curve groups and one based on the RSA and a, b ∈ Z p it is e(Pa , Qb ) = e(P, Q)ab . To prove security we
cryptosystem. These approaches do not seem to scale. In will be using the q-Strong Bilinear Diffie-Hellman assump-
particular, the EC-based construction [17] has public param- tion [13] (q-SBDH) on the groups G and GT that we formally
eters of quadratic size. Similarly while the RSA-based con- define in the Appendix—see Assumption 1.
struction [17] has better verification complexities than our Multilinear extension polynomial of vectors. Let F be a
proposed commitment, it requires linear time for proof up- field (e.g., Z p ) and let n = 2` . Let i ∈ {0, . . . , n − 1} and
date (and so does a recent RSA-based work by Campanelli et let ik denote its bit at position k in binary. For a vector
al. [16]), leading to very slow proof synchronization (around a = [a0 , . . . , an−1 ] with elements in the field F, we define its
145 hours for 230 accounts). The DVC scheme by Krupp et multilinear extension polynomial fa : F` → F as a polynomial
al. [28] is using [17] as a black-box (additionally offering a of ` variables that servers as a multiplexer for the vector a,
“Chameleon" property), thus inheriting its inefficiency. The re- i.e.,
cent work of Gorbunov et al. [22] introduces P OINT P ROOFS,
!
a DVC with update keys of linear size. Finally, subsequent n−1 `
to this work, Tomescu et al. [39] present a new DVC that fa (x1 , . . . , x` ) = ∑ ai · ∏ selectik (xk ) , (1)
supports aggregation of proofs and has short update keys. i=0 k=1

All the above distributed vector commitments have trusted where

setup. To the best of our knowledge there are two distributed
(
xk if ik = 1
vector commitments with no trusted setup. The lattice-based selectik (xk ) = . (2)
Merkle tree by Papamanthou et al. [34] (polylogarithmic 1 − xk if ik = 0
asymptotic costs) and the recent generalization of an RSA- Note that polynomial fa is the unique multilinear polynomial
based DVC [17] to hidden order groups by Lai and Mala- such that for all i with binary representation i` , . . . , i1 it is
volta [29] (linear update proof costs). Both do not scale in fa (i1 , . . . , i` ) = ai . For example, for a = [5 2 8 3] the polyno-
practice due to costs associated with lattices and class groups mial fa (x1 , x2 ) equals
respectively. We present a detailed comparison of the asymp-
totic costs of our construction with other distributed vector 5 · (1 − x2 )(1 − x1 ) + 2 · (1 − x2 )x1 + 8 · x2 (1 − x1 ) + 3 · x2 x1 .
commitments in Table 1, as well as detailed experimental
comparison of our distributed vector commitment with the To simplify, we sometimes represent point (x1 , . . . , x` ) as x.
RSA-based one [17] in Section 6. The following polynomial decomposition from [42] is useful.

4
Lemma 2.1. For any multilinear polynomial f : F` → F that recomputes the commitment of the root. If d = com(ε)
and for t ∈ F` , there exist polynomials qi such that f (x) − the verification is successful and one can be assured (ex-
f (t) = ∑`i=1 (xi − ti )qi (x). Moreover, all qi can be computed cept with negligible probability) that (k, v) is the k-th leaf
in O(2` ) = O(| f |) time. of the sparse Merkle tree. After a successful verification,
the verification algorithm can also be used to update com(ε)
Preprocessing zk-SNARKs. Let L be an NP relation such when (k, v) is deleted from the tree. In particular one can run
that x ∈ L if and only if there exists a witness w such that verify(k, null, π(k)) to output the new commitment d 0 . The
L (x, w) = 1. A (zero-knowledge) Succinct Noninteractive proof size is O(W ) and the verification complexity is O(W ).
ARgument of Knowledge (zk-SNARK) [36] for L allows a Batch verification and deletion. The above approach
verifier to efficiently verify that x ∈ L , without using w, but via can be generalized for verifying a set of data items S =
a small proof provided by an untrusted prover. A zk-SNARK {(k1 , v1 ), . . . , (kt , vt )} at once. In particular let path(S) be
consists of three polynomial-time algorithms, (G , P , V ): the union of path(ki ) and let sib(S) be the union of sib(ki ).
The proof π(S) for all (k1 , v1 ), . . . , (kt , vt ) in S, with re-
1. (PK,V K) ← G (1λ , L ): Key generation algorithm gener-
spect to the commitment of the root com(ε) is the set
ates the proving and verifying key for the program L .
∪i com(ki ) ∪ {com(v) : v ∈ sib(S)}. In this case we can call
2. π ← P (PK, x, w): The prover generates a succinct proof verifyMerkle(S, π(S)) to recompute the commitment of the
π to prove that there exists w such that L (x, w) = 1. sparse Merkle tree and verify all elements in S, as well as
verifyMerkle({(k1 , null), . . . , (kt , null)}, π(S)) for the batch
3. {0, 1} ← V (V K, π, x): The verifier checks if the proof π deletion of all data elements in S.
is valid for x using the verifying key V K.
Distributed vector commitments. We now give the defini-
Informally, zk-SNARKs have two properties: First, zero- tion of a distributed vector commitment.
knowledge, meaning that a verifying proof π does not re-
Definition 1 (Distributed Vector Commitment). A distributed
veal anything beyond the validity of the statement; Second,
vector commitment DVC consists of six PPT algorithms:
knowledge-soundness, meaning that if the verifier accepts a
proof for x, the prover “knows" a witness w for x and therefore 1. pp ← Gen(1λ , n): Given security parameter λ and vector
x ∈ L (moreover the witness w can be extracted by inspecting length n, it outputs public parameters pp.
the prover’s tape). For our application we will not be using
the zero-knowledge property. We give the formal definition 2. C ← Compp (a0 , . . . , an−1 ): Given a = (a0 , . . . , an−1 ), it
of knowledge-soundness in the Appendix—see Definition 3. outputs a commitment C.
Sparse Merkle trees. Sparse Merkle trees are Merkle 3. πi ← Openpp (i, v, a): Given index i, value v and a, it
trees [30] built over key-value pairs (ki , vi ) whose keys ki outputs proof πi .
are drawn from a large domain [0, 1, . . . , 2W − 1]. In particu-
lar, data item (ki , vi ) is stored at the ki -th leaf of the tree (the 4. {0, 1} ← Verpp (C, i, v, π): Given commitment C, an in-
tree has a total of 2W leaves). We define a natural labeling for dex i, a value v and a proof π it either accepts or rejects.
all nodes of the sparse Merkle tree: Root takes label ε, his left
5. C0 ← UpdateCompp (u, δ, C): Given update (u, δ)3 and
child takes label 0, his right child takes label 1, his leftmost
commitment C, it outputs the updated commitment C0 .
grandchild takes label 00 and so on.
For W -bit leaf ki that stores the data element (ki , vi ) we de- 6. π0i ← UpdateProof pp (u, δ, πi ): Given update (u, δ) and
fine the commitment of leaf ki as com(ki ) = ki ||vi . For leaves a proof πi , it outputs the updated proof π0i .
` that do not store a key we set com(`) = null. For every
internal node u of the Merkle tree we define the commitment The correctness definition for DVC is in the Appendix—
of u as com(u) = H(com(v)||com(w)), if either com(v) or Definition 4. We now present the soundness definition.
com(w) is not null and com(u) = null otherwise. Here, v is
Definition 2 (Soundness of distributed vector commitment).
the left child of u and w is the right child of u and H is a
Consider the following experiment that takes as input the
collision-resistant hash function such as SHA-2.
security parameter λ and outputs vector a, index i, value a
Single item verification and deletion. For data item (k, v)
and a bit b.
let path(k) be the ordered set of nodes on the path from k
to the root ε and let sib(k) be the ordered set of siblings • Let n be output by the adversary A ;
of nodes on path(k). Recall that the proof π(k) for (k, v),
with respect to the commitment of the root com(ε) is the set • pp ← Gen(1λ , n);
com(k) ∪ {com(v) : v ∈ sib(k)}. In particular, to verify the
• Let a = [a0 , . . . , an−1 ] be output by A ;
proof, one can run a verification algorithm
3 Value δ can be either positive or negative indicating credit or debit for
d ← verifyMerkle(k, v, π(k)) (3) account u.

5
 • C ← Compp (a); null
Tree A
null null
• for i = 1, . . . ,t = poly(λ) null null null null null

0 null null null 4 5 null 7 null null null null null null null null
– A outputs (u, δ) and let a be the updated vector;
Tree B
null
– C ← UpdateCompp (u, δ, C); null null
null null null null null
• A outputs i, a, π and let b ← Verpp (C, i, a, π). 0 null null null null 5 null 7 null null null null null null null null

• return (a, i, a, b); Tree C

null
A distributed vector commitment scheme is sound if for all null null null null

PPT adversaries A , the probability b = 1 and a 6= ai , where 0 null null null null 5 null 7 8 null null null null null null null

ai is the value at i is negligible. Figure 2: Evolution of the sparse Merkle tree on the UTXO
set. In Tree A, the UTXO set contains 4 unspent outputs that
3 E DRAX in UTXO model were added with timestamps 0, 4, 5 and 7. The outputs that
were added with timestamps 1, 2, 3 and 6 have already been
Recall the UTXO-based model follows the design of Bitcoin- spent (and thus deleted/nullified). We highlight with green
like cryptocurrencies, where validating a transaction tx de- color the nodes that constitute the most recent proof π(7). In
pends on whether its inputs belong to a set of unspent trans- Tree B a new transaction tx with input 4 appears in the system
action outputs (or UTXO) that is maintained by the miners. (thus 4 must be deleted from the tree), causing the most recent
Once this condition is verified, the spent inputs of tx are re- proof π(7) to change one of its hashes to H(null||dig(5)),
moved from UTXO and the new outputs of tx are added to indicated with dark green color. The output of tx is added in
UTXO. We first describe a version of E DRAX in this model. Tree C at the next position 8, causing the update of the most
recent proof from π(7) to π(8). Note π(8) in Tree C can be
Representing UTXO as a sparse Merkle tree. We will rep- computed from π(7) in Tree B using Algorithm 3.
resent the UTXO set as a sparse Merkle hash tree. A similar
approach has been used in Zcash [10]—unlike Zcash, how-
ever, here we remove a transaction output from the Merkle output (x, [pk, v]) in her local list L to a specific public key PK
tree after it is spent by marking is as null, see Figure 2. In (we can trivially generalize the SPEND transaction for multiple
particular each element of the UTXO is of the form (i, [pk, v]) inputs and outputs). Let sk be the corresponding secret key to
where i is the an increasing timestamp/counter indicating pk. Alice constructs and signs, using sk, the transaction:
when this output was added to the UTXO (and serves as the
“key" in the sparse Merkle tree) and [pk, v] contains the public [(x, [pk, v]), π(x), PK] .
key pk and E DRAX units v that this output can be spent to
(and serves as the “value" in the sparse Merkle tree). To be valid, π(x) must refer to the last block, i.e., at time t.

Block commitment. Every block b at time t (t refers to the New block creation. Suppose the last block that was com-
rank of the block in the blockchain) in UTXO E DRAX con- puted is block t and miners are competing for block t + 1. For
tains the following information as block commitment. that miners collect incoming SPEND transactions of the type

1. The UTXO commitment comt which is the root com- [(x, [pk, v]), π(x), PK], sig
mitment of the sparse Merkle tree built on transaction
outputs that have been generated up to block b, block b and decide using the block commitment at block t whether to
included (for outputs that have already been spent we include a transaction in block t + 1 as follows:
mark them as null); 1. (transaction signature verification) Check that signature
2. The Merkle tree proof of the most recent entry in the sig is valid under public key pk;
UTXO, i.e., the Merkle tree proof corresponding to the
2. (verifying membership of transaction input in UTXO)
last output of the last transaction in the last block b. We
Run
call this proof most recent proof and we denote it as πt .
verifyMerkle(x, [pk, v], π(x))

Client state. A E DRAX client stores the list L of his unspent as in Relation 3 to output a hash d. If d equals comt
transaction outputs (i, [pki , vi ]) (ones for which he knows re- (part of the block commitment), then the miner is assured
spective secret keys ski ) and respective Merkle proofs π(i). (x, [pk, v]) exists in the UTXO set and thus can be spent.
SPEND transaction. For simplifying exposition, suppose Al- The time required for verifying a transaction is O(W ) since
ice wants to create a transaction tx that spends a transaction one Merkle tree proof must be verified per transaction. The

6
transactions that satisfy the above checks are candidates for block at time t + 1 by performing the same steps as the min-
the next block. The block has size O(m ·W ) where m is the ers above. But instead of outputting commitment comt+1 at
number of transactions in the block. Finally, in the new block time t + 1 and most recent proof πt+1 at time t + 1, he just
t + 1, miners must also include the updated UTXO commit- replaces the affected commitments in π(x), due batch deletion
ment, i.e., comt+1 and the new most recent proof πt+1 . We and addition of the new outputs. In general, to synchronize
describe this procedure next. between t1 and t2 , he repeats this process t2 − t1 times.
Creating the new block commitment. We first show how to
create the new block commitment comt , πt for one transac- 4 DVC Construction
tion [(x, [pk, v]), π(x), PK] with one input and one output and
then we generalize to multiple transactions—see Figure 2. In We now present our new distributed vector commitment
particular, to compute comt+1 and πt+1 given comt and πt the construction used in the implementation of account-based
miners perform the following steps: E DRAX. We present all algorithms in detail, as defined in Def-
inition 1, then we show correctness as defined in Definition 4
1. (deleting transaction input from UTXO) Update in Appendix and soundness, as required by Definition 2.
the UTXO commitment comt to d 0 to not contain
spent input (x, [pk, v]) anymore by running d 0 ← 4.1 Detailed construction
verifyMerkle(x, null, π(x)) as we described in Section 2;
Our construction, among other things, will be using a zk-
2. (updating most recent proof due to deletion) Let cnt be SNARK as a black box, on an NP relation of logarithmic
the timestamp corresponding to the most recent proof size (therefore the prover will be quite efficient). We formally
πt . For every node v ∈ sib(cnt) ∩ path(x) replace every describe this relation in the following.
commitment com(v) in the most recent proof πt with
the new commitments com(v) as computed by running The NP relation Lg . Let now (p, G, GT , e, g) be the output
algorithm verifyMerkle(x, null, π(x)) above leading to a of BilGen(1λ ) and let ` = log n. Let now g = [g1 , . . . , g` ] be `
new proof π0 —see Tree B in Figure 2. fixed group elements of G. Consider now the following NP
relation Lg that contains elements (C, i, v) ∈ (G × Z p × Z p )
3. (adding transaction output to UTXO) The new transac- iff there exists group elements w1 , . . . , w` in G such that
tion output should now be stored at leaf cnt + 1 as (cnt + `
1), [PK, v]). Because of the addition of the new leaf, the e(C · g−v , g) = ∏ e(gk · g−ik , wk )
most recent proof π0 = π(cnt) computed above must be k=1
updated to πt = π(cnt + 1). Intuitively this can be done `
since πt is “to the right" of π0 —see U PDATE M OST R E - i = ∑ ik 2k−1
CENT P ROOF (Algorithm 3 in the Appendix) for the de- k=1

tailed pseudocode and Tree C in Figure 3. After πt+1 is ik (1 − ik ) = 0 for k = 1, . . . , `

computed, miners can finally update the UTXO commit- i.e., i1 , . . . , i` is the binary representation of i. Note now that
ment by running verifyMerkle(cnt +1, [PK, v], πt ) which the witness in the above relation is (w1 , . . . , wk , i1 , . . . , ik ). We
will output the final commitment comt+1 . now describe the DVC algorithms in detail.
pp ← Gen(1λ , n): Let (p, G, GT , e, g) be the output of
Processing multiple inputs and outputs. To process a block
with more than one transactions with more than one inputs BilGen(1λ ). Let ` = log n and let S be the powerset of
and outputs (as it typically happens in practice), miners must {1, 2, . . . , `}. Select s1 , . . . , s` randomly from F and set
perform batch verification and batch deletion to verify and prk = g∏i∈S si : S ∈ S and g = [gs1 , . . . , gs` ] .

delete the inputs from the UTXO, as described in Section 2.
This not just an optimization, but it is needed for correctness Also for all u = 0, . . . , n − 1, we define the update key for
(otherwise proofs will be out-of-sync). Finally, to add the new position u to contain the following ` group elements, i.e.,
outputs to the UTXO, the miners run Step (3) above as many
n t o 
upku = g∏k=1 selectuk (sk ) : t ∈ [`] = upku,t : t ∈ [`] .
times as the number of new outputs generated in the block.
Updating the block commitment with the above steps takes where selectuk (sk ) is by Equation 2.4 For example, for ` = 3,
O(m · W ) time where m is the total number of transaction public parameters pp will contain
inputs and outputs in the block.
g, gs1 , gs2 , gs1 s2 , gs1 s3 , gs2 s3 , gs1 s2 s3 ,
Proof computation & synchronization. For an unspent out- 4 Note each update key upk can be constructed from prk in linear time,
put (x, [pk, v]) in the UTXO, let π(x) be the proof stored lo- u
so update keys need not be part of the public parameters. However, since
cally by the client with respect to time t. To synchronize π(x) Gen has access to s1 , . . . , s` , each update key can be computed faster within
for time t + 1, the client must process all transactions in the Gen. That is why we explicitly make them part of the public parameters.

7
Algorithm 1 Algorithm for computing the polynomials that are required to update the proof at position i on update (u, δ).
1: procedure [∆` (X), . . . , ∆1 (X)] ← D ELTA P OL(u, δ, i, `)
2: if ` > 0 then h i
3: if msb of u is 0 and msb of i is 1 then return −δ · ∏`−1
k=1 select (x
uk k ), 0, . . . , 0 ;
h i
4: if msb of u is 1 and msb of i is 0 then return +δ · ∏`−1
k=1 selectuk (xk ), 0, . . . , 0 ;
h i
5: if msb of u is 0 and msb of i is 0 then return −δ · ∏`−1 ` `
k=1 selectuk (xk ), D ELTA P OL (u mod 2 , δ, i mod 2 , ` − 1) ;
h i
6: if msb of u is 1 and msb of i is 1 then return +δ · ∏`−1
k=1 select uk
(x k ), D ELTA P OL (u mod 2` , δ, i mod 2` , ` − 1) ;

while the update key upk0 will contain π0i ← UpdateProof pp (u, δ, πi ): Assume the witness w used to
generate πi is available as w1 , . . . , w` (in practice this can be
{g1−s1 , g(1−s1 )(1−s2 ) , g(1−s1 )(1−s2 )(1−s3 ) } . proof metadata used only for updating the proof, but not for
verification). For i = 1 to ` set
Let now (PK,V K) ← G (1λ , Lg ), where G generates public
parameters of the zk-SNARK for Lg . All prk, upku (u = w0i = wi · g∆i (s) ,
0, . . . , n − 1) and (PK,V K) comprise the parameters pp of
the distributed vector commitment. where ∆` (x), . . . , ∆1 (x) are the polynomials computed by call-
ing D ELTA P OL(u, δ, i, `) (see Algorithm 1). Note that it is
C ← Compp (a0 , . . . , an−1 ): Set C = g fa (s1 ,...,s` ) ,
where fa
very easy to modify D ELTA P OL to output the terms g∆i (s)
is the multilinear extension polynomial of the vector a =
directly by allowing it to access the update key upku of
[a0 , . . . , an−1 ] as defined in Equation 1.
u (so instead for computing, for example, the polynomial
πi ← Openpp (i, v, a): Let i` , . . . , i1 be the binary representa- −δ · ∏`−1 −δ
k=1 selectuk (xk ) it can just directly output [upku,`−1 ] ).
tion of i. As v = fa (i1 , . . . , i` ), using polynomial decomposi- To output the new proof, we can call
tion, compute polynomials q1 , . . . , q` such that
π0i ← P (PK, (C0 , i, v), {w01 , . . . , w0` }) ,
`
fa (x) − v = ∑ (xk − ik )qk (x) . where C0 is computed C0 ← UpdateCompp (u, δ, C).
k=1

4.2 Correctness and security analysis

Compute elements {gq1 (s) , . . . , gq` (s) }. To compute polynomi-
als q1 , . . . , q` , we divide fa (x)− fa (i1 , . . . , i` ) by x` −i` and set To prove correctness of our scheme according to Definition 4,
q` as the quotient polynomial of the division, which is a multi- we need to prove correctness of Algorithm D ELTA P OL (Algo-
linear polynomial with variables x1 , . . . , x`−1 . The remainder rithm 1). We give the proof in the Appendix—see Lemma 7.1.
is a multilinear polynomial with variables x1 , . . . , x`−1 , which Correctness of the rest of the scheme follows by inspection.
we divide by x`−1 − i`−1 to get q`−1 . We repeat recursively un- Concerning security, our distributed vector commitment
til we get q1 . Let now C = g fa (s1 ,...,s` ) . Note that (C, i, v) ∈ Lg can be viewed as an application of the selectively-secure
with witness {w1 = gq1 (s) , . . . , w` = gq` (s) }. The final proof is verifiable polynomial delegation scheme in [33], for the mul-
tilinear polynomial of Relation 1. While selective security is
πi ← P (PK, (C, i, v), {w1 , . . . , w` }) . very weak in general, we show it is enough for our application.
This is because a vector commitment requires evaluating the
We note here that {w1 , . . . , w` } would suffice as proof of v at polynomial on a fixed number of points, i.e., on the hypercube
index i but consists of log n elements. zk-SNARKs allow us {0, 1}` and not on arbitrary (exponentially-many) points in
to compress the proof to a constant number of elements. Z`p . We provide the detailed proof in the following.
{0, 1} ← Verpp (C, i, v, π): To verify that v is the opening at
Theorem 4.1. The distributed vector commitment scheme
position i of C, we verify the zk-SNARK proof π by invoking
presented above is sound (according to Definition 2) under
{0, 1} ← V (V K, π, (C, i, v)).
Assumption 1 and assuming knowledge-soundness of the un-
C0 ← UpdateCompp (u, δ, C): Compute new commitment as derlying zk-SNARK as defined in Definition 3.

h ` iδ Proof. We now prove the soundness of the distributed vector

C0 = C · g∏k=1 selectuk (sk ) = dig · upku,` .
 δ
commitment. First an `-SBDH instance
`
From the above note upku,` is sufficient to update the digest. ((p, G, GT , e, g), gs , . . . , gs )

8
Table 1: Comparison of our E DRAX DVC with existing DVCs that have short keys for updating proofs. n is the size of the vector.
Scheme Gen |π| Open UpdateComm UpdateProof Trusted Setup Aggregation
[17] (EC) O(n2 ) O(1) O(n) O(1) O(1) yes no
[17] and [16] (RSA) O(n) O(1) O(n log n) O(1) O(n) yes yes
[39] (EC) O(n log n) O(1) O(n) O(1) O(1) yes yes
[34] (lattices) O(1) O(log n) O(n) O(log n) O(log n) no no
[29] (class groups) O(1) O(1) O(n log n) O(1) O(n) no yes
E DRAX O(n) O(1) O(n) O(1) O(log n log log n) yes no

is given to adversary A1 . Then A1 picks random b ∈ {0, 1}` 4.3 Asymsptotics of vector commitment
(such that 2` is poly(λ)) and implicitly computes s1 = s and
si = ri · (s − b1 ) + bi where ri are random. Now, given Gen runs is time O(n), since some elements of prk share
parts of the exponent and some update keys across indices are
` the same. E.g., indices that differ only in the msb will share
gs , . . . , gs ,
` − 1 update keys. Producing the public parameters of the zk-
SNARK does not add to the asymptotic cost of Gen since the
A1 can easily compute pp, which he all gives to A2 . Moreover,
NP relation used is of logarithmic size. Com runs in time O(n)
these keys are indistinguishable from Gen’s output since the
since one exponentiation per vector element is required. The
ri ’s have been picked at random. We now show that if A2
size of pp is O(n), again due to overlap of update keys. Now,
is able to break soundness as defined in Definition 2 (by
due to the use of zk-SNARKs, verification costs (verification
providing a forgery (x, a, π) to A1 ) then A1 will be able to use
key, proof size and verification time) are all O(1). The running
that forgery and break Assumption 1.
time of Open is O(n), due to Lemma 2.1. UpdateCom runs
Indeed, given a vector a and the corresponding commitment
in O(1) time and UpdateProof runs in O(log n log log n) time
C, suppose A2 is able to output a forgery (x, a, π) such that it
in the worst case (the extra log log n factor come from the
holds 1 ← Verpp (C, x, a, π) and a 6= ax , where ax is the current
SNARK prover). We present a detailed comparison of the
value at index x of a after a possible sequence of updates.
asymptotics of our construction with other DVCs in Table 1.
Let us assume that the index x that A2 chose to forge is the
index b that A1 picked previously to compute the secrets
si —namely x = b. Note that the probability of that event 4.4 Fixed update key for updating all proofs
is 1/2` = 1/poly(λ). Now, since 1 ← V (V K, π, (C, x, a)), by
the knowledge-soundness of the zk-SNARK (see Definition 3) Note that as in the EC distributed vector commitment con-
there exists an extractor that can retrieve w1 , . . . , w` such that struction of Catalano and Fiore [17] (that has public param-
eters of quadratic size), our UpdateProof algorithm allows
` for fixed update key for an index i, that can be used to update
e(g fa (s1 ,...,s` )−a , g) = ∏ e(gsi −bi , wi ) all proofs π j , irrespective of the index j. This is contrast to
i=1 other constructions, such as the RSA-based construction of
Calalano and Fiore [17] and the recent one by Lai and Mala-
`
⇔ e(g fa (s1 ,...,s` )−ax +(ax −a) , g) = ∏ e(gsi −bi , wi ) volta [29], where for each combination of i and j a different
i=1 update key is required. This would be cumbersome in our
application of stateless validation: When one would wish to
`
` post a transaction, he would have to include the n update keys
⇔ e(g∑i=1 (si −bi )qi (s1 ,...,s` )+(ax −a) , g) = ∏ e(gsi −bi , wi )
i=1
for the sender and n update keys for the recipient, so that any
party j can update their proofs π j to reflect the decrease in
`  si −bi
wi the sender’s balance and the increase in the recipient’s bal-
⇔ e(g, g)ax −a = ∏ e g, ance. Since this is not possible, to update the proof π j , party j
i=1 gqi (s1 ,...,s` )
would have to compute his “custom" update key, which leads

w1
s−b1 `
wi
ri (s−b1 ) to linear computation time for synchronizing the local proofs
= e g, ∏ e g, (as opposed to our UpdateProof’s logarithmic).
gq1 (s1 ,...,s` ) i=2 gqi (s1 ,...,s` )
  ` ri
ax −a
⇔ e(g, g) s−b1 = e g,
w1 wi
.
5 E DRAX in account model
gq1 (s1 ,...,s` )
∏ g,
e
gqi (s1 ,...,s` )
i=2
We now describe our version of E DRAX stateless cryptocur-
Therefore A1 can compute e(g, g)1/(s−b1 ) with probability rency that uses balances (such as Nxt, Ethereum, Bitshares,
1/poly(λ) which breaks Assumption 1. NEM, Tezos). Recall in such systems the miners maintain a

9
database with balances and transaction validity is checked Client state. Apart from a public and a secret key required in
against this database (instead of UTXO). To implement other cryptocurrencies, an E DRAX client is required to store
E DRAX in the account-based model, we can in theory use the local proof π for the value of his balance with respect to
any distributed vector commitment scheme (as given in Def- the account commitment comt . Since this is a zk-SNARK
inition 1) as a black box. Our evaluation uses the scheme proof for the relation Lg , the client also stores the NP witness
described in Section 4, which, to the best of our knowledge, w1 , . . . , w` . In our implementation, proof π is small, around
is the most efficient both asymptotically and in practice. 268 bytes. Also in our implementation each proof is initialized
by running the zk-SNARK prove algorithm on the witness
Setup. Just like Zcash [10], E DRAX requires an one-time (1, . . . , 1) where 1 is the group identity element.
setup phase. In particular given an upper bound n on the
number of accounts that E DRAX can support5 and the secu- INIT transaction. Just like in Bitcoin and Ethereum, the first
rity parameter λ, algorithm Gen(1λ , n) is executed outputting time Alice ever wants to use E DRAX, she creates a pair of pri-
the public parameters pp. Recall that the public parameters vate and public keys (ska , pka ) (e.g., using elliptic curve cryp-
contain prover key prk, the verification key vrk and update tography). Recall however that E DRAX represents accounts as
keys upki —all these are hardcoded into the E DRAX reference integers in {0, 1, . . . , n−1} (where, in our implementation n is
software client. As an optimization one can just hardcode a around 230 ) and therefore a mechanism to map Alice’s public
Merkle tree digest of these parameters (since they can be quite key pka to an integer i ∈ {0, . . . , n − 1} must exist. To achieve
large) and retrieve them as required during the build—this that, E DRAX offers an INIT transaction for Alice to map her
technique is used in Zcash, for example. Finally, to mitigate public key pka to the next available index i. In particular Alice
the risk of trapdoor leakage during execution of Gen, we can constructs and signs, using ska , the transaction
use a secure multiparty computation protocol as in [15].
[INIT, pka ] .
Block commitment. For each block b at time t E DRAX min-
ers include, along with transaction data, two constant-size Looking forward, after registering a mapping of an index i to
values, that comprise the block commitment: pk, this transaction will implicitly define Alice’s public key
PKa as [pka ||i||upki,l ] where recall that upki,` is the update key
1. The account commitment comt which is a summary of the distributed vector commitment scheme. For example,
(hash) of the account balances in the system up to for ` = 2 and i = 0, upk0,` = g(s1 −1)(s2 −1) .
block b, block b included. It is computed using a DVC
SPEND transaction. Let us assume that Alice has public key
scheme as in Definition 1. It is initialized by running
PKa = [pka ||i||upki,l ], corresponding secret key ska and cur-
C ← Compp (0, . . . , 0) which, in our implementation, is
rent balance equal to v0 E DRAX units. She wants to send v ≤ v0
g0 = 1, where 1 denotes the identity element of group
E DRAX units to Bob with public key PKb = [pkb || j||upk j,l ].
G. In general the commitment comt will be on a vector
Alice constructs and signs the following transaction:
a that stores mappings of public keys to balances. Our
implementation does that by storing mappings of the [PKa , PKb , v, πi , v0 ] ,
type
i → [h(PK)||balance] meaning that public key PKa wishes to send v E DRAX units to
public key PKb and πi is her local proof proving that PKa has
where i is in {0, 1, . . . , n − 1} and is assigned by miners enough funds v0 ≥ v (wrt the latest account commitment comt )
for a specific public key PK—this assignment is triggered to support this transaction. Note the transaction overhead is
via a special INIT transaction serving as “registration" independent of the accounts number n.
for a new user and is described in the following.6 7
New block creation. Again, assume the last block that was
2. The account counter cntt that indicates how many computed is block t and miners compete for block t + 1. Min-
INIT transactions have occurred up to block b, block ers then collect new INIT and SPEND transactions of the type
b included—roughly speaking this indicates how many
accounts are in the system. It is initialized as 0. [INIT, pk], sig and [PKa , PKb , v, πi , v0 ], sig
5 E.g., for Ethereum the number of accounts now is approximately 30 respectively. For an INIT transaction to be candidate for inclu-
million; we will show experiments for 1 billion accounts. sion in block t + 1, it is enough that its signature verifies. To
6 E DRAX cannot map public keys directly to balances as the vector com-
decide if a SPEND transaction [PKa , PKb , v, πi , v0 ], sig can be
mitment supports only a polynomial number of indices and the domain of
public keys is exponential. included in the next block the miner performs the following:
7 E DRAX stores the mapping i → [h(PK)||nonce||balance], where nonce

shows how many payments have been made out from PK, as in Ethereum. 1. Parse PKa as [pka ||i||upki,l ] and check whether sig is a
This is necessary to distinguish between two separate payments from the valid signature under pka ;
same public key and a replay attack of the same payment. For simplicity, we
do not include nonce in our exposition. 2. Check whether v ≤ v0 ;

10
 3. Check whether 1 ← Verpp (comt , i, h(PKa )||v0 , πi ) where 6 E DRAX Evaluation
comt is the account commitment of the block at time t.
In this section, we present the evaluation of E DRAX in both
The new block has size O(m) where m is the number of trans- UTXO and accounts model. In subsection 6.1, we compare the
actions included in the block. Finally, in the new block t + 1, Sparse Merkle Tree (SMT) of E DRAX with RSA groups and
miners must also include the updated account commitment class groups used in [14]. And in subsection 6.2, we compare
comt+1 and the new account counter cntt+1 . We describe how the performance of our distributed vector commitment scheme
miners compute these values next. used in the accounts model with other DVCs.
Creating the new block commitment. To update the block
Experimental setup. We implement the sparse Merkle tree
commitment the miners initially set cnt ← cntt and com ←
scheme in Scala using the Scrypto library [8]. And we imple-
comt . Then they consider INIT transactions first and SPEND
ment our DVC in C++ using standard cryptographic and arith-
transactions later. In particular for every verified INIT trans-
metic precision libraries. Recall that our distributed vector
action [INIT, pk], sig sent by Alice to be included in block
commitment scheme comprises of multiplexer polynomials
t + 1 the miners set cnt = cnt + 1 and implicitly assign the
and zk-SNARKs. We implement the multiplexer polynomial
updated index cnt to pk8 . Then they set
using the GMP library [5] and the libff [2] for field arithmetic
com ← UpdateCompp (com, cnt, δ) and elliptic curve pairings. We implement the zk-SNARK
for the NP language Lg defined in Section 4, using the zk-
where δ = h(PK)||0 (we assume Alice begins with 0 balance) SNARK by Groth [23], implemented in libsnark [12].
and where PK = [pk||cnt||upkcnt,l ]. This operation essentially We perform the experiments of our schemes on an Amazon
registers Alice’s public key to a specific index cnt. Then for EC2 c4.4xlarge machine with 30GB of RAM and an Intel
every verified SPEND transaction [PKa , PKb , v, πi , v0 ], sig the Xeon E5-2666v3 CPU with 16 2.9GHz virtual cores. We
miners set perform 10 runs and report their average for each data point
of running time, unless stated otherwise.
com ← UpdateCompp (com, i, −v) ,
zk-SNARK for NP language Lg . A zk-SNARK consisting
and then again of (G , P , V ) instantiated by an elliptic curve E defined over
a field Fq proves satisfiability of NP statements over Fr ,
com ← UpdateCompp (com, j, +v) . where Fr = #E(Fq ). But recall that membership verification
Note from the public parameters pp only upki,` and upk j,` Lg involves pairing computations over Fq and therefore our
are required to perform the above, already contained in the SNARK logic should encode operations over field Fq , rather
transactions. The above operation updates the sender and than Fr . As noted in prior works [11], it is impossible to find
receiver balances. Finally the miners set cntt+1 ← cnt and a curve where q = r. We adopt the MNT curves approach
comt+1 ← com and output the new block commitment. from [11] and thus we instantiate the polynomial evaluation
scheme with a curve E1 over Fq1 and the SNARK scheme
Proof synchronization. Let π be Alice’s local proof that cor- with a curve E2 over Fq2 such that #E2 (Fq2 ) = Fq1 . In particu-
responds to the state of the system up until block t. Now lar, in our implementation, the polynomial evaluation scheme
assume some transactions are taking place and block t + 1 produces witnesses that are elements over the MNT6 curve
is created. Alice’s local proof π is no longer valid and Alice and our zk-SNARK scheme is instantiated over MNT4 curve.
must synchronize her proof to make sure it incorporates all
updates (u1 , δ1 ), (u2 , δ2 ), . . . , (u p , δ p ) that were included in Arithmetic circuit for verifying membership in Lg . It can
block t + 1. To do that she executes Algorithm 2 by running been seen from Section 4 that verifying membership in Lg
π ← S YNC P ROOF((u1 , δ1 ), . . . , (u p , δ p ), π) and outputs a new consists of performing pairing operations (whose primary
synchronized proof π. Note that since the SPEND transactions components are the Miller algorithm and the final exponen-
only contains element upki,` , Alice can fetch the rest of the tiation), exponentiating group elements to values i1 , . . . , ik ,
update keys (e.g., upkui ,1 , . . . , upkui ,`−1 ) from an untrusted checking to see that i1 , . . . , ik are bits and in particular that
server, verify them using the hash of the reference software, they constitute the binary representation of value i. . The en-
and then update the local proof. Note also that Alice does not
have to synchronize her proof at every new block. She just has
Algorithm 2 Algorithm for synchronizing the proof so that
to synchronize her proof whenever she wants to spend some
updates (u1 , δ1 ), . . . , (ut , δt ) are included.
E DRAX units to someone else in which case she must process
all the blocks since her proof was last synchronized in the 1: procedure π ← S YNC P ROOF ((u1 , δ1 ), . . . , (u p , δ p ), π)
same way as above. Note that the time to synchronize after p 2: for i = 1, . . . , p do
updates is O(p log n), due to the efficiency of D ELTA P OL. 3: π ← UpdateProof pp (ui , δi , π);
8 This 4: return π;
defines Alice’s public key as [pk||cnt||upkcnt,l ].

11
Table 2: Sparse merkle trees vs. groups of unknown order. Table 4: One-time setup in our DVC for various values of `.
(Time taken for 1000 runs of the same operation) The notation ∗ means estimation due to long running times.
trusted proof verify update local Time taken can be reduced by a factor of 10 × using Lim-Lee
primitive setup (bytes) (ms) proof (ms) exponentiation [7]. Alternative EC representations can reduce
RSA Yes 256 471 707 the size of the keys [23].
class groups No 768 6095 9142 KeyGen memory prk vrk & upk
SMT `
usage size size
(W = 40) No 371 39 15
25 5,519s 20GB 5.3GB 11.8KB
Table 3: Mining and validation per block of 1000 transactions. 26 11,122s 30GB 10.5GB 12.3KB
E DRAX RSA class groups 28 45,556s 30GB 41.4GB 13.2KB
Accumulator (ms) (ms) (ms) 29 96,965s 30GB 83.6GB 14.2KB
Mining 264 21850 3590387 30 230,453s∗ 40GB 165GB 14.7KB
Validation 264 4646 4925
operations using class groups, we use the VDF implemen-
tire verification consists of 787K multiplication gates and the tation from Chia Network to estimate the overhead of class
peak memory usage is 2, 214 MB even for ` = 30. group [3]. Thus the numbers reported in Table 2 is a conser-
vative evaluation (lower bound) of the overhead of classgroup
6.1 Evaluation of sparse Merkle tree operations.
A sparse Merkle tree (SMT) can be considered as a form Macrobenchmarks. In Table 3, we macro-benchmark the
of cryptographic accumulator. In this subsection, we com- performance of E DRAX with the accumulator construction
pare our construction with other accumulators proposed by proposed by Boneh et al. [14] in the blockchain setting with
the concurrent work of Boneh et al. [14] which is based on optimizations such as batching and aggregation. We extend
groups of unknown order (RSA and class groups). We com- the implementation of the rust accumulators library [1] to
pare the performance of bare-bone primitives that make up measure the performance of RSA accumulators [14].
the accumulators (micro-benchmarks) and the performance Note that the mining costs are substantially higher (com-
of the accumulators in the blockchain setting with available pared to validation) in groups of unknown order as every
optimizations enabled (macro-benchmarks). miner must: (i) verify every transaction in the block first (re-
In all our experiments, we set the height of the SMT to W = quires expensive group exponentiations); (ii) aggregate the
40, as this value is sufficient to support the total number of proofs using the batching techniques (requires multiplication
transaction outputs ever generated in Bitcoin—right now this of large primes and computing Bezouts coefficients for every
number is about 765 million (computed using the BlockSci TX); (ii) add new coins to the accumulated set; (iv) generate
tool [6]). We also instantiate the RSA accumulator and the membership proofs for element added to the set by factorizing
class group accumulator at accepted 2048-bit security level the aggregate membership proof.
across all experiments. Also in our experiments, we assume
a block size of 1000 transactions, each with single input and
6.2 Evaluation of our vector commitment
single output coin.
In this section, we evaluate the performance of our new dis-
Microbenchmarks. In Table 2, we micro-benchmark the per-
tributed vector commitment scheme and justify its practical-
formance of SMT with other primitives. The accumulators
ity over other DVC schemes listed in Table 1. Due to the
based on RSA and class groups are space efficient, as a mem-
impracticality of class group objects, we exclude [29] from
bership proof is just one group element. Thus they add mini-
our comparison. Thus we limit the comparison only with
mal storage overhead when compared to sparse Merkle trees.
the lattice-based vector commitment from [38] and the RSA-
However, it is computationally cheaper to verify the mem-
based vector commitment from Catalano et al. [17].
bership of an element in SMT over other primitives, as the
overhead of hashing using a lightweight SHA-2 hash function One-time setup. The costliest part of our vector commitment
is lower than the cost exponentiating in RSA or class group. scheme is the one-time setup to generate the prover, update,
Similarly it is cheaper to update the local membership proofs and verification keys. Such an expensive setup is not present in
in SMT than other primitives. Note that in our experiments, the lattice-based scheme (whose setup involves just a constant-
we consider an update as either an addition of element to time sampling of two lattice-based hash functions) but is
the accumulated set (requires one exponentiation) or deletion required for the RSA-based DVC [17] whose linear-time setup
of an element from the set (requires two exponentiations). involves generating primes for each vector index. Moreover
Moreover, SMTs do not require trusted setup, unlike RSA- using Lim-Lee [7] exponentiation techniques, setup time can
based accumulators. Even though class groups do not require be reduce by a factor of 10×.
a trusted setup, it is simply too expensive to perform group Results for our scheme are provided in Table 4. As shown
operations. Due to the lack of a standard library to perform in the table, it takes 5,519s to generate the keys for a vector of

12
 Vector Commitment Vector Commitment Vector Commitment Vector Commitment
Lattice-based Lattice-based Lattice-based Lattice-based

Update Proof Time (ms)

Update Digest Time (ms)
Hidden order (RSA) Hidden order (RSA) Hidden order (RSA) 103

Verification Time (ms)

102 102
Proof Size (KB)

102 102
101 101
101 100 100
100
100 10 2 10 1
24 26 28 30 32 24 26 28 30 32 28 3024 26 32
26 28 30 32 24
L L L L
Figure 3: Proof size and verification times. Figure 4: Time for digest update and proof synchronization.
RSA scheme [17] is not shown: it takes 14.5 hr to synchronize.
32 million elements, which is close to the current number of
accounts in Ethereum [18]. Most of the time in key generation choice, as it outperforms other DVCs both asymptotically
is spent on computing exponentiations in the base group, and practically in one of the most crucial operations in the
which can be easily parallelized. stateless blockchain setting, the proof update. Our DVC also
Moreover, our implementation stores the prover key on has comparable asymptotic proof size and verification time.
disk, so it can scale to a larger ` as long as the disk size is
larger than the proving key size. The overhead for disk I/O
6.3 Security of E DRAX
is already included in the key generation time reported in
Table 4. We remark that E DRAX nodes do not require the The security of E DRAX is based on the security of the un-
multilinear polynomial evaluation scheme’s prover key—just derlying sparse Merkle tree (for UTXO) and the underlying
the update key and verification key are sufficient to function vector commitment (for accounts setting). In particular we
in the distributed setting. Both the verification key and the note that E DRAX satisfies the security definition presented
update key for one element are less than 15KB for ` ≤ 30 and in Section 2 of [20] (which appeared in EUROCRYPT [21]):
grow logarithmically with the elements in the vector. The only difference between E DRAX and the protocol proved
Proof size and verification time. Figure 3 shows the com- secure in [20] is the way the validation predicate V (XC ) (page
parison of proof size and the verification time. Our scheme is 13) is implemented: Instead of maintaining a large state vari-
asymptotically better than the lattice scheme and comparable able for accounts/UTXO to implement V (XC ), E DRAX saves
to the RSA scheme. In practice, the proof size is less than space by maintaining just a small digest of accounts/UTXO
0.15KB for ` ≤ 32 in our scheme, while it is 62–78KB in and validates XC using client provided proofs. Clearly, for the
the lattice scheme and it is 0.256 KB in the RSA scheme. same XC , both implementations of V (XC ) output the same bit
This is because the the SNARK proof is three group elements with overwhelming probability, due to DVC/SMT soundness.
whereas the proof of the RSA scheme is one group element. Therefore, E DRAX’s real-world execution almost never devi-
ates from the protocol proved secure in [20] and as such it is
For verification time, our scheme outperforms lattice-based
secure based on [20].
schemes both in asymptotics and practice (7ms vs 210ms).
However, despite the comparable asymptotics with the RSA-
based scheme, in practice RSA-based schemes fare better than
7 Conclusions and discussion
our approach. This is because our verifier performs expensive
In this paper we presented E DRAX, an architecture (and two
pairings to verify the proof, whereas the RSA based scheme
different implementations) for stateless transaction validation
performs cheaper modular exponentiations to verify the proof.
in cryptocurrencies. Our concrete implementations are first
Digest update and proof synchronization. Figure 4 shows steps —in future more practical authenticated structures or
the time to update the digest and to synchronize a local proof. vector commitments can be used as replacement, leading to
Our scheme requires 35µs to update the digest and 89µs (amor- even better performance. Here we outline future research.
tized) to synchronize the proof for one element. Recall that Authenticated balanced trees instead of sparse Merkle
our proof update algorithm is logarithmic in the vector size. trees. The fixed structure of sparse Merkle trees allows flexi-
In the lattice based schemes, both updating the digest and the ble updates even without the need for storing the entire tree
proof takes around 790 ms for ` = 25 and grows logarithmi- locally. However, they have proofs, O(W ), irrespective of the
cally with `. On the contrary, proof update in RSA-based VC current size of the UTXO. We believe one can implement
is very expensive: It features a linear-time algorithm, which the E DRAX UTXO using an authenticated balanced tree that
involves computing the product of primes associated with maintains a proof size O(log n), where n is the current size
each position of the vector and performing modular exponen- of the UTXO. Prior works have studied authenticated skip
tiations. In reality the RSA-based VC requires around 14.5 lists and authenticated trees, but it is not clear how these data
hours to update the proof of a single position in the vector of structures can be updated with just the most recent proof
size 230 (which is the number of accounts in eth now). [31, 35]. UTREEXO [19], that appeared after the first version
Main finding. To summarize, our DVC is the pragmatic of E DRAX, solves this problem by using a series of trees that

13
have a number of leaves that are powers of two, depending [10] E. Ben-Sasson, A. Chiesa, C. Garman, M. Green,
on the current size of UTXO. I. Miers, E. Tromer, and M. Virza, “Zerocash: Decentral-
Proof-serving nodes. Unlike existing cryptocurrencies, ized anonymous payments from bitcoin,” in 2014 IEEE
E DRAX clients are required to synchronize their proof before Symposium on Security and Privacy, SP 2014, Berkeley,
posting a new transaction. This changes the user experience CA, USA, May 18-21, 2014, 2014, pp. 459–474.
for clients and introduces a modest cost. To alleviate this cost, [11] E. Ben-Sasson, A. Chiesa, E. Tromer, and M. Virza,
we can extend the E DRAX architecture to contain untrusted “Scalable zero knowledge via cycles of elliptic curves,”
proof-serving nodes9 (e.g., an Amazon machine) that do not in Annual Cryptology Conference. Springer, 2014, pp.
participate in the blockchain consensus, which are responsi- 276–294.
ble for storing and serving up-to-date proofs. Note that there is
no requirement that they serve correct proofs: If the provided [12] ——, “Succinct non-interactive zero knowledge for
proof is correct (which can be checked by using blockchain a von neumann architecture,” in Proceedings of the
digest), then this proof can be readily used, otherwise the 23rd USENIX Conference on Security Symposium,
client can always use the “default" setting and synchronize ser. SEC’14. USA: USENIX Association, 2014, p.
his proof by using the algorithms presented before. 781–796.
Supporting smart contracts in the stateless setting. In the [13] D. Boneh and X. Boyen, “Short signatures without
smart contract setting, the flow of money will depend of the random oracles,” in International Conference on the
execution of some contract code on the current contract state. Theory and Applications of Cryptographic Techniques.
Hence for Alice to post a contract-triggering transaction she Springer, 2004, pp. 56–73.
must provide a proof of correctness of the current contract
state for E DRAX nodes to execute on. Two challenges are: [14] D. Boneh, B. Bünz, and B. Fisch, “Batching techniques
(i) who is storing the contract state as any client can post for accumulators with applications to iops and stateless
transactions to trigger a contract execution; (ii) how to avoid blockchains,” in CRYPTO, 2019.
including the contract state as part of the transaction (the
contract state might be too large). We leave this a future work. [15] S. Bowe, A. Gabizon, and M. Green, “A multi-party
protocol for constructing the public parameters of the
pinocchio zk-snark,” in International Conference on
References Financial Cryptography and Data Security. Springer,
2018.
[1] “Accumulators with class groups,” https://github.com/
[16] M. Campanelli, D. Fiore, N. Greco, D. Kolonelos,
cambrian/accumulator.
and L. Nizzardo, “Vector commitment techniques and
[2] “C++ library for finite fields and elliptic curves,” https: applications to verifiable decentralized storage,” IACR
//github.com/scipr-lab/libff. Cryptol. ePrint Arch., vol. 2020, p. 149, 2020. [Online].
Available: https://eprint.iacr.org/2020/149
[3] “Chia vdf challange,” https://github.com/Chia-Network/ [17] D. Catalano and D. Fiore, “Vector commitments and
oldvdf-competition. their applications,” in Public-Key Cryptography - PKC
2013 - 16th International Conference on Practice and
[4] “Ethereum white paper,”
Theory in Public-Key Cryptography, Nara, Japan, Febru-
https://github.com/ethereum/wiki/wiki/white-paper.”
ary 26 - March 1, 2013. Proceedings, 2013, pp. 55–72.
[5] “The GNU multiple precision arithmetic library,” https: [18] E. U. A. G. Chart, “https://etherscan.io/chart/address.”
//gmplib.org/.
[19] T. Dryja, “Utreexo: A dynamic hash-based accumulator
[6] “https://github.com/citp/blocksci.” optimized for the bitcoin utxo set,” Cryptology ePrint
Archive, Report 2019/611, 2019.
[7] “Libra zk reference implementation,” https:
//github.com/sunblaze-ucb/Libra/blob/Libra/ [20] J. Garay, A. Kiayias, and N. Leonardos, “The bitcoin
implementation/src/VPD/inputvpd.cpp. backbone protocol: Analysis and applications,” Cryp-
tology ePrint Archive, Report 2014/765, 2014, https:
[8] “Scrypto,” https://github.com/input-output-hk/scrypto. //eprint.iacr.org/2014/765.

[9] “Utxo uh-oh...," http://gavinandresen.ninja/utxo-uhoh.” [21] J. A. Garay, A. Kiayias, and N. Leonardos, “The bit-
coin backbone protocol: Analysis and applications,” in
9 These nodes could be incentivized through cryptocurrency rewards. Advances in Cryptology - EUROCRYPT 2015 - 34th

14
 Annual International Conference on the Theory and Ap- [33] C. Papamanthou, E. Shi, and R. Tamassia, “Signatures
plications of Cryptographic Techniques, Sofia, Bulgaria, of correct computation,” in Theory of Cryptography.
April 26-30, 2015, Proceedings, Part II, ser. Lecture Springer, 2013, pp. 222–242.
Notes in Computer Science, E. Oswald and M. Fischlin,
Eds., vol. 9057. Springer, 2015, pp. 281–310. [34] C. Papamanthou, E. Shi, R. Tamassia, and K. Yi,
“Streaming authenticated data structures,” in Advances
[22] S. Gorbunov, L. Reyzin, H. Wee, and Z. Zhang, in Cryptology - EUROCRYPT 2013, 32nd Annual Inter-
“Pointproofs: Aggregating proofs for multiple vector national Conference on the Theory and Applications of
commitments,” IACR Cryptol. ePrint Arch., vol. Cryptographic Techniques, Athens, Greece, May 26-30,
2020, p. 419, 2020. [Online]. Available: https: 2013. Proceedings, 2013, pp. 353–370.
//eprint.iacr.org/2020/419
[35] C. Papamanthou and R. Tamassia, “Time and space effi-
[23] J. Groth, “On the size of pairing-based non-interactive cient algorithms for two-party authenticated data struc-
arguments,” in Advances in Cryptology - EUROCRYPT tures,” in Information and Communications Security,
2016 - 35th Annual International Conference on the 9th International Conference, ICICS 2007, Zhengzhou,
Theory and Applications of Cryptographic Techniques, China, December 12-15, 2007, Proceedings, 2007, pp.
Vienna, Austria, May 8-12, 2016, Proceedings, Part II, 1–15.
2016, pp. 305–326.
[36] B. Parno, J. Howell, C. Gentry, and M. Raykova, “Pinoc-
[24] https://etherscan.io/chart/address. chio: Nearly practical verifiable computation,” in 2013
IEEE Symposium on Security and Privacy, SP 2013,
[25] https://ethresear.ch/t/the-stateless-client concept/172. Berkeley, CA, USA, May 19-22, 2013, 2013, pp. 238–
252.
[26] https://medium.com/cybermiles/diving-into-
ethereums-world-state c893102030ed. [37] S. Ponnapalli, A. Shah, A. Tai, S. Banerjee, V. Chi-
dambaram, D. Malkhi, and M. Wei, “Scalable and ef-
[27] https://statoshi.info/dashboard/db/unspent-transaction- ficient data authentication for decentralized systems,”
output set. 2019.

[28] J. Krupp, D. Schröder, M. Simkin, D. Fiore, G. Ate- [38] Y. Qian, Y. Zhang, X. Chen, and C. Papamanthou,
niese, and S. Nürnberger, “Nearly optimal verifiable “Streaming authenticated data structures: Abstraction
data streaming,” in Public-Key Cryptography - PKC and implementation,” in Proceedings of the 6th edition
2016 - 19th IACR International Conference on Practice of the ACM Workshop on Cloud Computing Security,
and Theory in Public-Key Cryptography, Taipei, Taiwan, CCSW ’14, Scottsdale, Arizona, USA, November 7, 2014,
2016, pp. 417–445. 2014, pp. 129–139.

[29] R. W. F. Lai and G. Malavolta, “Subvector commitments [39] A. Tomescu, I. Abraham, V. Buterin, J. Drake, D. Feist,
with application to succinct arguments,” in Advances and D. Khovratovich, “Aggregatable subvector commit-
in Cryptology - CRYPTO 2019 - 39th Annual Interna- ments for stateless cryptocurrencies,” Cryptology ePrint
tional Cryptology Conference, Santa Barbara, CA, USA, Archive, Report 2020/527, 2020, https://eprint.iacr.org/
August 18-22, 2019, Proceedings, Part I, 2019, pp. 530– 2020/527.
560.
[40] . h. e.-s.-a.-n.-s. Vitalik Buterin. Transaction spam at-
[30] R. C. Merkle, “A certified digital signature,” in Advances tack: Next steps.
in Cryptology - CRYPTO ’89, 9th Annual International
Cryptology Conference, Santa Barbara, California, USA, [41] J. Zahnentferner, “Chimeric ledgers: Translating and
August 20-24, 1989, Proceedings, 1989, pp. 218–238. unifying utxo-based and account-based cryptocurren-
cies,” Cryptology ePrint Archive, Report 2018/262,
[31] A. Miller, M. Hicks, J. Katz, and E. Shi, “Authenticated 2018, https://eprint.iacr.org/2018/262.
data structures, generically,” in The 41st Annual ACM
SIGPLAN-SIGACT Symposium on Principles of Pro- [42] Y. Zhang, D. Genkin, J. Katz, D. Papadopoulos,
gramming Languages, POPL ’14, San Diego, CA, USA, and C. Papamanthou, “vRAM: Faster verifiable
January 20-21, 2014. ram with program-independent preprocessing,” in
2018 IEEE Symposium on Security and Privacy
[32] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash (SP), vol. 00, pp. 203–220. [Online]. Available:
system,” http://bitcoin.org/bitcoin.pdf.” doi.ieeecomputersociety.org/10.1109/SP.2018.00013

15
[43] Y. Zhang, D. Genkin, J. Katz, D. Papadopoulos, and 1. If msb of u is 0 and msb of i is 1, then the algorithm
C. Papamanthou, “vsql: Verifying arbitrary sql queries returns ∆` (x) = −δ · ∏`−1k=1 selectuk (xk ) and ∆i (x) = 0 for all
over dynamic outsourced databases,” in 2017 IEEE Sym- i < `. Since u 6= i, these polynomials must satisfy Relation 4
posium on Security and Privacy (SP), 2017, pp. 863– which can be rewritten as
880. `−1 `−1
δ·(1−x` )· ∏ selectuk (xk ) = (x` −1)·∆` (x)+ ∑ (xk −ik )·∆k (x) .
k=1 k=1
Appendix
It is easy to see that this is indeed the case by simple substitu-
7.1 Correctness of D ELTA P OL tion.
The proof of correctness of our new vector commitment 2. If msb of u is 0 and msb of i is 0, then the algorithm returns
`−1
scheme lies upon proving the correctness of D ELTA P OL used ∆` (x) = −δ · ∏k=1 selectuk (xk ) along with ∆`−1 (x), . . . , ∆1 (x)
to update the witness for an index i, when another update as output by D ELTA P OL(u mod 2` , δ, i mod 2` , `−1). We dis-
(u, δ) takes place on an index u. To see why D ELTA P OL cor- tinguish two subcases.
rectly performs this task, note that before the update (u, δ),
(a) u 6= i. In this case polynomials ∆` (x), . . . , ∆1 (x) must
witness wi consists of {gq1 (s) , . . . , gq` (s) } where polynomi-
satisfy Relation 4 which can be rewritten as
als qi (x) satisfy fa (x1 , . . . , x` ) − ai = ∑`k=1 (xk − ik ) · qk (x).
Due to the update (u, δ), the digest fa (x1 , . . . , x` ) increases by `−1 `−1
δ · ∏`k=1 selectuk (xk ) and therefore polynomials qi (x) should δ·(1−x` )· ∏ selectuk (xk ) = x` ·∆` (x)+ ∑ (xk −ik )·∆k (x) .
be adjusted to qi (x) + ∆i (x) to accommodate this change, as k=1 k=1

described in the following lemma: By substituting the output polynomials and by using our
Lemma 7.1. Algorithm D ELTA P OL(u, δ, i, `) correctly com- inductive hypothesis that states δ · ∏`−1 k=1 selectuk (xk ) =
`−1
putes polynomials ∆` (x), . . . , ∆1 (x) such that ∑k=1 (xk − ik ) · ∆k (x) it is easy to see that this is indeed the
case.
` `
δ · ∏ selectuk (xk ) = (b) u = i. In this case polynomials ∆` (x), . . . , ∆1 (x) must
∑ (xk − ik ) · ∆k (x) , if u 6= i (4)
satisfy Relation 5 which can be rewritten as
k=1 k=1
or `−1 `−1
δ·(1−x` )· ∏ selectuk (xk )−δ = x` ·∆` (x)+ ∑ (xk −ik )·∆k (x) .
` `
k=1 k=1
δ · ∏ selectuk (xk ) − δ = ∑ (xk − ik ) · ∆k (x) , if u = i , (5)
k=1 k=1 By substituting the output polynomials and by using our
where ik is the k-th bit of i. inductive hypothesis that states δ · ∏`−1 k=1 selectuk (xk ) − δ =
`−1
Proof. By induction on `. For the base case, note that Algo- ∑k=1 (xk − ik ) · ∆k (x) it is easy to see that this is indeed the
rithm D ELTA P OL(u, δ, i, 1) outputs ∆1 (x) = −δ in case u is case.
0 and i is 1 or both u and i are 0 and ∆1 (x) = δ in case u is 1
3. If msb of u is 1 and msb of i is 0, then algorithm returns
and i is 0 or both u and i are 1. Indeed ∆1 (x) does satisfy the
∆` (x) = δ· ∏`−1
k=1 selectuk (xk ) and ∆i (x) = 0 for all i < `. Since
relations above as we prove in the following by considering
u 6= i, these polynomials must satisfy Relation 4 which can
all four possible cases.
be written as
1. u = 0 and i = 1. In this case Relation 4 is indeed satisfied `−1 `−1
as δ · (1 − x1 ) = (x1 − 1) · (−δ). δ · x` · ∏ selectuk (xk ) = x` · ∆` (x) + ∑ (xk − ik ) · ∆k (x) .
k=1 k=1
2. u = 0 and i = 0. In this case Relation 5 is indeed satisfied
as δ · (1 − x1 ) − δ = x1 · (−δ). It is easy to see that this is indeed the case by simple substitu-
tion.
3. u = 1 and i = 0. In this case Relation 4 is indeed satisfied
as δ · x1 = (x1 − 0) · δ. 4. If msb of u is 1 and msb of i is 1, then the algorithm returns
∆` (x) = δ · ∏`−1
k=1 selectuk (xk ) along with ∆`−1 (x), . . . , ∆1 (x)
4. u = 1 and i = 1. In this case Relation 5 is indeed satisfied as output by D ELTA P OL(u mod 2` , δ, i mod 2` , `−1). We dis-
as δ · x1 − δ = (x1 − 1) · δ. tinguish two subcases.
For the inductive hypothesis, assume D ELTA P OL(u, δ, i, ` − (a) u 6= i. In this case polynomials ∆` (x), . . . , ∆1 (x) must
1) outputs polynomials ∆`−1 (x), . . . , ∆1 (x) that satisfy either satisfy Relation 4 which can be rewritten as
Relation 4 or Relation 5 (depending whether u = i or not). We
`−1 `−1
prove the same claim for D ELTA P OL(u, δ, i, `) by considering
δ · x` · ∏ selectuk (xk ) = x` · ∆` (x) + ∑ (xk − ik ) · ∆k (x) .
the following cases. k=1 k=1

16
 By substituting the output polynomials and by using our Definition 3 (Knowledge-soundness of zk-SNARK). We say
inductive hypothesis that states δ · ∏`−1 k=1 selectuk (xk ) = that the a zk-SNARK (G , P , V ) has knowledge-soundness if
`−1
(x
∑k=1 k k − i ) · ∆k (x) it is easy to see that this is indeed the for any PPT A and any NP relation R , there is a polynomial
case. time extractor E such that the probability
(b) u = i. In this case polynomials ∆` (x), . . . , ∆1 (x) must  
satisfy Relation 5 which can be rewritten as (PV,V K) ← G (1λ , R );
 (x, π) ← A (PK,V K); 
 1 ← V (V K, π, x)
Pr  
`−1 `−1 w ← E (PK,V K); 
δ·(1−x` )· ∏ selectuk (xk )−δ = x` ·∆` (x)+ ∑ (xk −ik )·∆k (x) . R (x, w) 6= 1
k=1 k=1

By substituting the output polynomials and by using our is negligible.

inductive hypothesis that states δ · ∏`−1 k=1 selectuk (xk ) − δ =
`−1
(x
∑k=1 k k − i ) · ∆k (x) it is easy to see that this is indeed the
case. Correctness definition of a vector commitment
scheme

7.2 Assumptions and definitions Definition 4 (Correctness of distributed vector commitment).

A distributed vector commitment is correct, if for all λ ∈ N and
Assumption 1 ( [13] q-Strong Bilinear Diffie-Hellman n = poly(λ), for all public parameters pp ← Gen(1λ , n), for
(q-SBDH)). For any PPT adversary A , the following proba- all vectors a = [a0 , . . . , an−1 ], if C is computed by Compp (a)
bility is negligible: and πi , for all i, is a proof generated Openpp (i, a, ai ), then
  for a polynomial number of updates (u, δ) if C and πi , for
(p, G, GT , e, g) ← Gen(1λ ); all i, are produced by calls to UpdateCompp (u, δ, C) and
R
s ← Z∗p ; UpdateProof pp (u, δ, πi ) respectively then for all i it is Pr[1 ←
 
Pr  .
 
q
 σ = ((p, G, GT , e, g), gs , . . . , gs ) :  Verpp (C, i, ai , πi )] = 1, where ai is the value at index i after
1
(x, e(g, g) s+x ) ← A (1λ , σ) all updates took place.

17
Algorithm 3 Algorithm for updating most recent proof when a new output [PK, v] is generated.
1: procedure π(cnt + 1) ← U PDATE M OST R ECENT P ROOF (π(cnt), PK, v)
2: Parse π(cnt) as d0 , . . . , dW where d0 is cnt||[pk, v0 ];
3: Initialize π(cnt + 1) as δ0 , . . . , δW
where δ0 is (cnt + 1)||[PK, v] and δi = null for i > 0;
4: Let the binary representations of cnt and cnt + 1
be B||bk , . . . , b0 and B||βk , . . . , b0 respectively, where B is their common prefix;
5: Set q = |B| − 1;
6: Copy the last q hashes from π(cnt) to the last q positions of π(cnt + 1);
7: Let π contain the first W − q hashes of π(cnt);
8: Run d ← verifyMerkle(cnt, [pk, v], π);
9: Set δW −q+1 = d and δi = null for all 0 < i < W − q + 1 ;
10: return π(cnt + 1);

18