Atomic and Fair Data Exchange via Blockchain

Ertem Nusret Tas∗ István András Seres† Yinuo Zhang‡

Stanford University Eötvös Loránd University University of California, Berkeley

Márk Melczer§ Mahimna Kelkar¶ Joseph Bonneau∥

Eötvös Loránd University Cornell University A16Z Crypto Research
Cornell Tech New York University

Valeria Nikolaenko∗∗
A16Z Crypto Research

ABSTRACT server in advance and must trust the reputation of the server to
We introduce a blockchain Fair Data Exchange (FDE) protocol, en- deliver the data, or altruistic, where either the server provides the
abling a storage server to transfer a data file to a client atomically: data free of charge or the data is exchanged between the users
the client receives the file if and only if the server receives an agreed- themselves as in BitTorrent [24]. The former approach does not
upon payment. We put forth a new definition for a cryptographic safeguard the client from a malicious server that receives payment
scheme that we name verifiable encryption under committed key without fulfilling the data request, while the latter lacks incentives
(VECK), and we propose two instantiations for this scheme. Our pro- for clients to offer data for download, leading to free-riding and
tocol relies on a blockchain to enforce the atomicity of the exchange limited capacity. Moreover, the vast majority of storage systems do
and uses VECK to ensure that the client receives the correct data not provide data integrity guarantees to users [5].
(matching an agreed-upon commitment) before releasing the pay- While blockchains were originally conceived as payment sys-
ment for the decrypting key. Our protocol is trust-minimized and tems, it was quickly observed that they could also be used for
requires only constant-sized on-chain communication, concretely 3 data storage [23]. Bitcoin [52] adopted a dedicated mechanism
signatures, 1 verification key, and 1 secret key, with most of the data (OP_RETURN) for storing data on-chain in 2014, which has been
stored and communicated off-chain. It also supports exchanging used for a variety of purposes [68]. Ethereum [70] has always sup-
only a subset of the data, can amortize the server’s work across mul- ported arbitrary data storage (calldata) as required by its Turing-
tiple clients, and offers a general framework to design alternative complete smart contract platform (EVM). As append-only, immutable,
FDE protocols using different commitment schemes. A prominent and distributed ledgers, blockchains can provide data storage that
application of our protocol is the Danksharding data availability is robust against faults and abuse of power.
scheme on Ethereum, which commits to data via KZG polynomial However, by themselves, blockchains are highly limited in both
commitments. We also provide an open-source implementation for storage and computational capacity, making on-chain data storage
our protocol with both instantiations for VECK, demonstrating our expensive. For example, storing 1 megabyte of data on Ethereum
protocol’s efficiency and practicality on Ethereum. as calldata would cost approximately $2,100 at the time of writing.
While many blockchain projects are working to improve capacity
1 INTRODUCTION and reduce costs, it is conjectured that these systems will always
be limited as increased capacity is at odds with maintaining secu-
Cloud data storage is a rapidly growing global market (≈ 18.5% rity and decentralization (an observation dubbed the blockchain
annual growth rate) with an estimated value of $78.6 billion in trilemma [14]).
2022 [50]. The volume of cloud data being stored today is counted Limited on-chain capacity has led to the development of so-called
in tens to hundreds of zettabytes (1 zettabyte = 270 bytes) [61]. Data layer-2 (L2) solutions (e.g., rollups, validiums) for both computation
economy globally is much larger and is estimated at the trillions and data storage. These solutions perform computation and store
of US dollars (based on Canadian [19, 65] and European [45] as- data off-chain while enabling the main blockchain (now called a
sessment). Recent regulations [56] enforce companies to make the layer-1) to verify off-chain computation via verifiable computa-
generated data more widely accessible potentially helping expand tion (as [63, 67, 71]) and off-chain storage via proofs-of-storage
the global market for cloud data. Fair and secure protocols to pur- and replication (as in [34]). In the case of off-chain storage, the
chase access to data are essential to unlock the massive potential blockchain typically receives a succinct commitment to the data
of global data markets. However, most approaches for accessing uploaded to the servers. It can then use the commitment to ver-
data today are either subscription-based, where the client pays the ify proofs-of-storage (also called proofs-of-retrievability [13]) or
∗ [email protected]. Big part of the work was done at a16z crypto research.
proofs-of-replication [35, 36] attesting to the persistence of the
† [email protected]. Big part of the work was done at a16z crypto data.
research. A current gap in both theory and practice is that, while these
‡ [email protected]. Big part of the work was done at a16z crypto research.
§ [email protected] proofs provide a natural mechanism to pay servers to store data,
¶ [email protected]. Big part of the work was done at a16z crypto research. they don’t provide a means to pay for actually serving the data when
∥ [email protected] requested by the clients. Today’s protocols only incentivize storage
∗∗ [email protected]

1
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

and assume servers will provide download access essentially “for subset of the committed data. Second, KZG commitments are also
free.” This is problematic for two reasons: First, transferring the data used in Danksharding, making our protocol a natural fit.
comes with its own costs, which servers should be compensated for, We describe the blue-print of our FDE protocol in Figure 1. We
proportional to the number of times the data is downloaded. Second, consider data stored as a length 𝑛 + 1 vector of field elements.
without any incentives, malicious servers might store the data (and Let 𝜙 (·) with commitment 𝐶𝜙 be the degree 𝑛 polynomial whose
receive payment for doing so) but never respond to legitimate evaluation over the points {0, . . . , 𝑛} correspond to the data entries.
download requests.1 Storage is useless unless the data is made To start the exchange of data for funds, the server posts a public
available for access. verification key vk to a contract along with the specific details of
The FDE problem. To fill this gap, in this work, we introduce the the data exchange, e.g., the agreed price and the client’s blockchain
concept of a blockchain Fair Data Exchange (FDE) protocol, where address (step 1). Subsequently, the server sends the client (off-chain)
clients and servers have cryptographic fairness and data integrity the encryptions {ct𝑖 }𝑛𝑖=0 of the data points {𝜙 (𝑖)}𝑛𝑖=0 along with
guarantees, and formalize its syntax and security properties (cf. a proof which shows that indeed for all 𝑖 ∈ [𝑛], ct𝑖 is the correct
Section 4.1). We notice that in most scenarios, it’s natural to assume encryption of the evaluation 𝜙 (𝑖) at index 𝑖 of the polynomial 𝜙 (·)
that the client holds a short cryptographic commitment to the committed by 𝐶𝜙 , under some decryption key sk committed by
stored data that the server possesses in its entirety. Therefore, we vk (step 2). After receiving the encrypted data, the client locks up
informally require that in FDE protocols, the server will receive the funds in the on-chain contract if the details of the exchange and
payment from the client if and only if the client receives the data the proofs are correct with respect to the ciphertexts and the KZG
beneath the commitment. commitment (step 3). The server can redeem the payment only if it
A prominent application of our scheme is ProtoDanksharding provides the (secret) decryption key sk that matches its previously
(EIP-4844) [15], a new data availability scheme being designed submitted verification key vk (step 4). The client can then read sk
for Ethereum.In ProtoDanksharding, validators store special kind from the contract and decrypt the ciphertexts to obtain the data
of blockchain data designated for storage and not for execution, (steps 5 and 6). If the server does not reveal a decryption key, the
called blob-data. The blob-data expires, but the KZG-commitment client can withdraw its locked coins after a timeout. We show that
to the data is persisted. After the blob-data expires, data-availability our FDE protocol satisfies correctness, client-fairness (the server
servers or full-nodes might voluntarily continue storing it, but they cannot receive any payment if the client does not obtain the data)
are not required to. Our FDE protocol helps incentivize nodes to and server-fairness (the client cannot learn anything about the data
continue storing the data by enabling the users to purchase expired without paying the server).
data from nodes in a trust-minimized, fair, and efficient way. Our Our protocol also extends to the multi-client setting in which
scheme also applies to Danksharding [29], an extension that would multiple clients download the same data. We introduce a multi-
disseminate blob-data to nodes avoiding data-replication. client FDE protocol where, via preprocessing, we amortize the
server’s computation cost to serve multiple clients. In certain appli-
A strawman blockchain-based solution. Pagnia and Gärtner’s cations, this protocol can also reduce the clients’ computation by
well-known impossibility result states that fair exchange is impos- having the blockchain verify the server’s preprocessing output.
sible without a trusted third party (TTP) [54]. A straightforward For the proof-system/encryption scheme combination required
but inefficient solution to the FDE problem using an L1 blockchain in FDE we make the following important observation: the decryp-
(such as Ethereum) as the TTP would be as follows: Suppose the tion key for the ciphertext is produced together with the ciphertext
client has a short commitment 𝐶 to the data that it wishes to obtain itself, and the decryption key is only used once. Henceforth more ef-
from the server. The client locks some funds for payment in an ficient encryption schemes could be used, including symmetric-key
FDE smart contract on the blockchain along with the commitment or one-time schemes, opening a broader design space for the under-
𝐶. The contract enables the server to receive these funds only if it lying cyprographic primitive that we introduce in this work: Veri-
publishes the requested data, that correctly verifies against 𝐶 in a fiable Encryption under Committed Key (VECK). The blockchain
smart contract. While this is a secure and fair solution, it is highly FDE protocol is then built using VECK in a black-box way. We
inefficient as it requires all data to be written to the L1 chain. If build two instantiations for VECK: using a symmetric-key version
the data is too large to fit in a single transaction, the parties would of exponential ElGamal encryption and using public-key version of
also need to interact multiple times with the blockchain, adding Paillier encryption. Our instantiations of VECK allow encrypting
latency and additional costs. Our goal is to design a constant-round evaluations of a polynomial under a KZG commitment, however
protocol with a small (ideally constant) storage footprint on the we set forth more general definitions to capture other potential
blockchain. applications or commitment schemes.
Our approach. We introduce a new FDE protocol (cf. Figure 1), Implementation and benchmarks. We provide a practical, open-
where a client and a server atomically exchange funds for data source implementation2 of our FDE protocols accompanied by as-
committed using the KZG polynomial commitment scheme [47]. ymptotic and concrete performance evaluations (cf. Table 1 for a
Our choice of KZG is due to two reasons: First, it has the ability to comparison of our performance metrics with prominent related
provide constant-size commitments and batchable opening proofs, work). Our FDE protocols are practical and have low round com-
which are particularly useful when a client only wants to retrieve a plexity (3 rounds). For the server, the cost of proving the consistency
of ciphertexts for 4, 096 KZG-committed BLS12-381 field elements
1 Game-theoretic approaches to enforce responses require posting the data on the
blockchain in the worst-case [69]. 2 https://github.com/PopcornPaws/fde.
2
Atomic and Fair Data Exchange via Blockchain

# Rounds data com. |𝜋 disp | S → C comm. C → E comm. S → E comm. Online

FairSwap [30] 5 Merkle tree 3 log(𝑘)|H| (𝑘 + 1)|H| 2|H| + |𝜎 | 2|𝜎 | + |G| ✓
FileBounty [46] 𝑘 Merkle-Damgård [28] 3G 𝑘 (𝜆 + |H|) 𝑘 |𝜎 | 2|𝜎 | ✗
FairDownload [44] 𝑘 Merkle tree log(𝑘)|H| 𝑘 |ct| 𝑘 |𝜎 | 2|𝜎 | + O (log 𝑘)|H| ✗
FDE-ElGamal (cf. Figure 2) 3 KZG [47] N/A 𝑘8|ct| + 6|G| |𝜎 | 2|𝜎 | + 2|G| ✓
FDE-Paillier (cf. Figure 4) 3 KZG [47] N/A 𝑘 (2|ct| + |F𝑝 |) |𝜎 | 2|𝜎 | + 2|G| ✓

Table 1: Comparing our 𝐹 𝐷𝐸 protocols with our closest related works. 𝑘 denotes the number of exchanged chunks of data.
Each data chunk has 𝜆 bits. S, C, E denotes the server, the client, and the payment environment (typically a smart contract),
respectively. The size of the proof submitted during the dispute protocol is denoted as |𝜋disp |. We say a fair exchange protocol
is online if the protocol assumes that C and S must be online during the entire execution of the protocol. Here, |H|, |G|, and
|F𝑝 | refer to the size of a single hash function output, (an elliptic curve or Z𝑁 2 ) group element, and field element, respectively,
whereas |𝜎 | refers to the signature size. N/A means not applicable.

VECK protocol as a black-box. In Section 5, we provide two con-

3) structions for secure FDE protocols: based on exponential ElGamal
Lo
ck
ey 5) s and based on Paillier encryptions. We provide an extensive perfor-
ck Re Pa
li ym
ub ke
y ad mance evaluation of our implementation in Section 6. In Section 7,
sp t ins Contract ss en
en
d
e cre co ec t
1 )S ss ws re we introduce a multi-client FDE protocol where, via preprocessing,
nd ra tk
)S
e thd
4 Wi ey we amortize the server’s computation cost to serve multiple clients
5)
We conclude our paper with some discussions, possible extensions,
2) Sends encrypted data with proofs
and open problems in Section 8.
Client( )
Server( )
Data Payment

Decrypt( , )=
2 RELATED WORK
It has been long known that fair exchange without a trusted third
6) Obtaining the data party (TTP) is impossible [54]. Recently, with the development of
blockchains as reliable trusted third parties, fair exchange protocols
Figure 1: The blueprint of FDE protocols on Ethereum that have received renewed attention [6, 30, 44, 46]. These protocols
relies on a smart contract for achieving fairness. typically resolve a witness-selling problem: the buyer is willing
to offer 𝐷 coins for the witness value 𝑥 (e.g., factorization of a
modulus) such that 𝑓 (𝑥) = true. The protocol then goes as follows:
(enough to transfer 128 KiB of data) takes ≈ 89 seconds for expo- the buyer locks 𝐷 coins, and only if the seller provides 𝑥 to the
nential ElGamal (vs. ≈ 5 seconds for Paillier) on a consumer laptop. buyer does the seller get these coins; if no 𝑥 is provided, the buyer
We foresee several venues for optimizing our proof of concept im- gets its money back after a time-out. This protocol effectively boils
plementation. The bulk of the cost (≈ 40%) for ElGamal is due to down to exchanging a signature for a witness, and a more general
generating range-proofs which can be amortized when serving version of it is tasked with fairly exchanging two witnesses (e.g., two
multiple clients. Our exponential ElGamal-based protocol has a signatures or two keys, or a signature for a key, etc.). Such protocols
constant-size proof (9 G and 2 F𝑝 elements), but we split the plain- roughly fall into two categories: optimistic (e.g., [3]) and atomic.
texts into 𝑘 smaller chunks to enable efficient decryption, resulting The former uses a TTP for dispute resolution, where one party
in a 𝑘-factor blowup in the ciphertext size. On the other hand, the encrypts its signature under the TTP’s public key and sends it to
Paillier-based protocol has linear-sized proofs in the number of the other party. TTP then helps the parties complete the exchange
exchanged BLS12-381 field elements. Overall, we observe a ≈ 10× in the event one of the parties aborts or cheats. However, in these
bandwidth overhead in our ElGamal protocol (vs. ≈ 50× for Paillier), works, the trusted party is assumed to handle secrets which is
that is, the size of the ciphertexts and proofs compared solely to not translatable to the general blockchain setting. In an atomic
the size of the exchanged data. Despite of this, interestingly, both exchange, the TTP holds the coins and sends them to the seller if
the Paillier prover and verifier are concretely more efficient than the given witness value 𝑥 satisfies a statement, i.e., 𝑓 (𝑥) = true. In
the ElGamal prover and verifier, cf. Figure 6. For more benchmarks, these schemes, the TTP need not store any secret information.
cf. Section 6. In FairSwap [30], Dziembowski et al. develop a general protocol
Outline. The rest of this paper is organized as follows. We review for exchanging the witness, 𝑥, of an NP statement 𝜙 for a signature
the pertinent literature in Section 2. We introduce the notion of (or a payment). The server encrypts the input 𝑥 of the NP state-
verifiable encryption under committed key (VECK) in Section 3. ment and the wires of the circuit for evaluating the statement 𝜙 (𝑥),
In Section 4, we introduce the syntax, security, and privacy require- commits to all of these encryptions in a Merkle tree, and submits
ments of blockchain Fair Data Exchange (FDE) protocols, and con- the Merkle root to a smart contract. It also submits a Merkle root
struct secure FDE protocol instances on Ethereum and Bitcoin using committing to the circuit 𝜙. The client then locks the payment to
3
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

the server in the smart contract, after which the server submits the and it is friendly to data-dispersal protocols which utilize erasure
decryption key. A complaint period allows the client to succinctly coding (e.g., Danksharding [29]).
prove to the contract the inconsistency of the data, in which case Our protocol builds a variant of verifiable encryption (VE) for
the client gets its money back. Our solution avoids the complaint committed values. VE allows an encryptor to prove an NP-relation
period and allows the exchange to happen at network speed. A about a plaintext encrypted under a public key encryption scheme.
follow-up work, OptiSwap [31], improves the performance of the It was first introduced by Stadler [66] for discrete logarithms and
protocol for the optimistic case when both parties behave honestly later generalized by [4] for the fair exchange of signatures. A related
by introducing interaction to the dispute resolution process. problem of practical encryption for discrete-logarithm values was
More efficient protocols have been built for a special case of solved by Camenish and Shoup [16] using a CCA-secure encryp-
the problem above, aiming at exchanging the data underneath tion scheme based on Paillier’s Decision Composite Residuosity
the client’s commitment for a signature (i.e. a payment). In File- (DCR) assumption [55], with application, among others, to the fair
Bounty [46], the commitment to the data (𝑀1, 𝑀2, . . . , 𝑀𝑁 ) is as- exchange of Schnorr or DSS signatures. This was the first scheme
sumed to be an application of an iterated hash function (e.g., SHA256 to avoid the expensive "cut-and-choose" paradigm adopted by the
based on Merkle-Damgard paradigm): earlier works [4, 66].
Whereas VE can be instantiated generically using zero-knowledge
C = ℎ(ℎ(. . . ℎ(ℎ(𝐻 𝑁 , 𝑀𝑁 ), 𝑀𝑁 −1 ) . . .), 𝑀1 ). (zk)SNARKs, this requires the inclusion of the encryption as part of
the SNARK relation, with potential effects on efficiency. In this con-
The data is transferred chunk-by-chunk from 𝑀1 to 𝑀𝑁 , and each text, the LegoSNARK framework allows proving relations satisfied
chunk 𝑀𝑖 is accompanied by a value 𝐻𝑖 with 𝐻 1 := C and it is by a witness with respect to an existing commitment, thus com-
checked that ℎ(𝐻𝑖+1, 𝑀𝑖 ) = 𝐻𝑖 . In case any one of the parties cheats bines the commitment and SNARK akin to lego pieces [17]. SAVER
or disappears, the dispute resolution is done on a blockchain, where extends this idea to encryptions of the witness by allowing SNARK
zkSNARKs are used in order to hide the data. If the server or the proofs without including encryption in the SNARK circuit [48].
client stops executing the protocol in the middle, then at worst, Unlike VE, VECK allows the use of symmetric key encryption.
the client receives a small chunk that it did not pay for, or the In fact, VECK is generically realizable using symmetric encryption
server is paid a small amount for a small chunk it did not provide. and NIZKs, as we discuss in Section 8. Morever, as our scheme uses
In both cases, the loss can be tolerated since the chunk and the a fresh key to encrypt the data in each request, unlike [16], we
corresponding payment are both small. This model, however, only do not need CCA-security, and simpler, more efficient CPA-secure
works if the client’s utility in receiving a portion of the data is schemes such as ElGamal or Paillier would suffice. We explore both
proportional to its size, and it is not suitable for scenarios where variants and demonstrate their efficiency in this work.
the client is only interested in receiving the whole data. In these A related construction to VE is commitment consistent encryp-
cases, the blockchain can be used to help participants complete the tion (CCE), which is a public key encryption scheme with the ability
exchange, albeit at the expense of privacy concerns and higher costs. to generate a commitment to the encrypted message (with the pub-
Our work mitigates these issues by employing efficient verifiable lic key) and to subsequently open the commitment (with the secret
encryption protocols. key) [26]. CCEs were developed to provide universally verifiable
He et al. [44] provide an FDE protocol called FairDownload, voting schemes with perfectly private audit trail; so that the elec-
where a Merkle root hash of the data is published on-chain. The data tion results can be verified via the audit data while preserving voter
is the leaves of the Merkle tree. The client and the server exchange privacy even after key leakages [26, 57]. Unlike CCEs, VECKs en-
the data chunk by chunk without any consistency proofs with able verifiable encryption of subsets of the messages under a vector
respect to the Merkle root hash. However, the exchanged chunks or polynomial commitment.
are signed by the server. Therefore, if there is any dispute between ...[1]...
the client and the server, the client can prove the misbehavior of
the server to the on-chain contract with a O (log 𝑘)-sized Merkle-
inclusion proof. Linus [49] also designs a similar scheme called
3 VERIFIABLE ENCRYPTION UNDER
BitStream with optimistic dispute resolution on Bitcoin with the COMMITTED KEY (VECK)
help of Merkle proofs. The O (log 𝑘) cost of these schemes is in A verifiable encryption under committed key (VECK) is a scheme
contrast with our constant-sized on-chain communication cost. with the following functionality: given a commitment to the data,
Interestingly, He et al. define novel notions of fairness (e.g., delivery it allows to encrypt the data (or a pre-specified function of the
fairness) and show that their protocol satisfies them. data). The encryption outputs a verification key, a ciphertext and a
Finally, Bitcoin zk-Contingent-Payments introduced as a zero-knowledge proof of correct encryption. It satisfies correctness,
concept by Gregory Maxwell in 2011 [51] aims to solve a fair ex- soundness and zero-knowledge. Correctness guarantees that the
change problem for the Bitcoin blockchain limited in scripting decryption key corresponding to the verification key decrypts the
capabilities. However, concrete instantiations were shown to be original data (or a pre-specified function of it). Thus, the verifica-
insecure [18, 38]. tion key can be viewed as a commitment to the decryption key.
In contrast to the previous work, our protocol has a minimum Soundness guarantees that no polynomial-time adversary can gen-
number of rounds and entirely avoids a dispute resolution phase. erate a convincing proof about an incorrect encryption without
See Table 1 for a more detailed comparison. Our protocol also breaking the underlying assumptions, or the security of the com-
supports selective download, where a subset of the data is requested, mitment schemes. Zero-knowledge guarantees that the ciphertext,
4
Atomic and Fair Data Exchange via Blockchain

verification key and the proof leak no information that enables the algorithm A, there exists a negligible function 𝜈 (·) such that the
recovery of the underlying data, therefore, the data would remain following is less than 𝜈 (𝜆):
private until the decryption key is revealed.
Although such functionality can be generically achieved using 
 crs ← Setup(1𝜆 ) 

public-key encryption and generic SNARKs, we show that building  Verct (𝐹, 𝐶 𝑤 , vk, ct, 𝜋) = 1 ∧ 𝐶 𝑤 ← Commit(crs, 𝑤) 
 
it holistically using tailored one-time encryption and proofs results Pr  Verkey (vk, sk) = 1 ∧ pp ← Gen(crs) 

in a simpler and more elegant stand-alone construction. 
 𝑦 ≠ 𝐹 (𝑤) (sk, vk, ct, 𝜋) ← A (pp, 𝐹, 𝐶 𝑤 ) 

VECK allows us to reduce the problem of fair data exchange to 
 𝑦 ← Dec(𝐹, sk, ct) 

a problem of fair exchange of decryption key for a payment, as we
show in Section 4. The latter exchange can be done fairly through a We note that for 𝐹 that computes identity, knowledge extraction
blockchain, since the validity of the decryption key can be verified (knowledge-soundness) is implicit in the definition of security and
against the verification key using a blockchain smart-contract. is given by the decryption, i.e., a valid 𝑤 can be extracted from the
Preliminaries. We let 𝜆 ∈ N denote the security parameter. A non- adversary that convinces the verifiers.
negative function 𝜎 (𝜆) is called negligible if for every polynomial Computational Zero-Knowledge: The ciphertext and the proof leak
𝑝 (𝜆) it holds that 𝜎 (𝜆) ≤ 1/𝑝 (𝜆) for all sufficiently large 𝜆 ∈ N. For no additional information about the witness. For any PPT algorithm
a random variable 𝑥 we denote by 𝑥 ←𝑅 𝑋 the process of sampling A, there exists a PPT simulator Sim such that there is a negligible
a value 𝑥 from the set 𝑋 uniformly at random. function 𝜇 (·), s.t. for all 𝑤 ∈ W, ∀𝐹 ∈ F the following probability is
less than 1/2 + 𝜇 (𝜆):
Definition 3.1 (verifiable encryption under committed
key (VECK)). Let (Setup, Commit) be a non-interactive binding
commitment scheme, where Setup(1𝜆 ) → crs generates a public  crs ← Setup(1𝜆 ) 
common-reference string, and Commit(crs, 𝑤 ∈ W) → 𝐶 𝑤 ∈ C 
 𝐶 𝑤 ← Commit(crs, 𝑤)


generates a commitment. A non-interactive VECK scheme for a class 
 pp ← Gen(crs)


functions F = {𝐹 : W → V} is a tuple of algorithms Π F = 
 (vk0, sk0, ct0, 𝜋0 )


(Gen, Enc, Verct, Verkey, Dec): Pr A (pp, 𝐹, 𝐶 𝑤 , vk𝑏 , ct𝑏 , 𝜋𝑏 ) = 𝑏 
Enc(pp, 𝐹, 𝐶 𝑤 , 𝑤)

↱

• Gen(crs) → − pp: Probabilistic polynomial-time algorithm
 
 (vk1, ct1, 𝜋1 ) 
that takes as input the crs generated by the setup of the com-
 
Sim(pp, 𝐹, 𝐶 𝑤 )

↱
 
mitment scheme and outputs parameters for the system, as
 
 𝑏 ←𝑅 {0, 1} 
well as the description of appropriate spaces. The parameters
 
pp are implicitly taken by all the following algorithms, we Zero-knowledge property can also be statistical instead of com-
omit them where it is clear from the context. putational, where instead of having the algorithm A distinguishing
• Enc(pp, 𝐹, 𝐶 𝑤 , 𝑤) → − (vk, sk, ct, 𝜋) : Probabilistic polynomial- the real (pp, 𝐶 𝑤 , vk0, ct0, 𝜋0 ) and the simulated (pp, 𝐶 𝑤 , vk1, ct1, 𝜋1 )
time algorithm, run by the server, It takes in the function 𝐹 , distribution as above, we would say that they are statistically indis-
the commitment to 𝑤 and the 𝑤 itself, and outputs a verifi- tinguishable. Some of our constructions satisfy this stronger notion
cation key vk, a decryption key sk, an encryption ct of 𝐹 (𝑤) of zero-knowledge.
and a proof 𝜋. Note that VECK allows the use of symmetric key encryption and
• Verct (pp, 𝐹, 𝐶 𝑤 , vk, ct, 𝜋) →
− 1/0: A deterministic polynomial- can be built generically using symmetric encryption and NIZKs as
time algorithm run by the client that outputs accept or reject. we discuss in Section 8. Likewise, it can be built using public key
• Verkey (pp, vk, sk) → − 1/03 : A deterministic polynomial-time encryption, but the possibility of using symmetric key encryption
algorithm run by the blockchain or a trusted third party that opens up a prospect for using more efficient schemes.
checks the validity of the secret key. For the FDE application, we will explore a polynomial commit-
• Dec(pp, sk, ct) → − 𝑣/⊥ : A deterministic polynomial-time ment scheme, where the VECK function 𝐹 is the evaluations of
algorithm run by the client, it outputs a value (such as an a given degree-ℓ polynomial: 𝐹 (𝜙) = {𝜙 (𝑖)}𝑖 ∈ [ℓ ] , where 𝜙 (𝑋 ) is
evaluation of 𝐹 on 𝑤) or ⊥. a polynomial of degree ℓ, and more generically 𝐹 computes the
A VECK scheme satisfies the following properties: subsets of evaluations: 𝐹𝑆 (𝜙) = {𝜙 (𝑖)}𝑖 ∈𝑆 . In practice, instead of
Correctness: Verifications for honestly generated encryption succeed: 𝑖 ∈ {0, 1, . . . , ℓ }, an FFT-friendly set (and its subsets) can be used for
∀𝑤 ∈ W, ∀𝐹 ∈ F , the following event holds with probability 1: efficiency: {1, 𝜔, 𝜔 2, . . . , 𝜔 ℓ }, where 𝜔 ∈ F𝑝 is a primitive (ℓ + 1)-th
root of unity.

 crs ← Setup(1𝜆 ) 
 Given our choice of 𝐹 , we briefly recall polynomial commitments
 Verct (𝐹, 𝐶 𝑤 , vk, ct, 𝜋) = 1 ∧ 𝐶 𝑤 ← Commit(crs, 𝑤) 
Pr   and their properties.
Verkey (vk, sk) = 1 pp ← Gen(crs) 
  Polynomial Commitment schemes allow committing to uni-

 (vk, sk, ct, 𝜋) ← Enc(𝐹, 𝐶 𝑤 , 𝑤) 
 variate polynomials of degree at most ℓ over F𝑝 and are comprised
Soundness: No probabilistic polynomial time adversary can generate of the following algorithms, where Setup is randomized and the
sk, vk, ct and 𝜋 such that verification succeeds, yet decryption does rest are deterministic (although Commit might also be randomized,
not output a valid value. Namely, ∀ 𝑤 ∈ W, ∀𝐹 ∈ F , for any PPT but this case will not be our focus here):
• Setup(1𝜆 , 𝑛) → crs : generates public parameters for com-
3 In our constructions, the key verification will not need full public parameters. mitting to polynomials of degree at most 𝑛.
5
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

• Commit crs, 𝜙 (𝑋 ) → 𝐶 : deterministically computes the • FDE.Com⟨C(data), S()⟩ → ⟨C(com), S(data)⟩. The par-
commitment 𝐶 to the polynomial 𝜙 (𝑋 ) ∈ F𝑝≤𝑛 [𝑋 ] of degree ties C and S engage in a non-interactive protocol, where C
not greater than 𝑛.
commits to data ∈ {0, 1}ℓ ·𝜆 consisting of ℓ blocks of data and
• VerifyPoly crs, 𝜙 (𝑋
), 𝐶 → 0/1 : outputs 1 if it holds that stores the commitment com ∈ {0, 1}𝜆 . C then sends data to
Commit crs, 𝜙 (𝑋 ) = 𝐶, and outputs 0 otherwise. S.
• Open(crs, 𝑖, 𝜙 (𝑋 )) → 𝜋 : outputs a proof 𝜋 for the fact that • FDE.Vrfy(data, com) → {0, 1}. Given data and com, the
𝜙 (𝑋 ) evaluates to 𝜙 (𝑖) at index

𝑖. server S verifies the correctness of the commitment com with
• VerifyEval crs, 𝐶, 𝑖, 𝜙 (𝑖), 𝜋 → 0/1 : verifies the proof. respect to the data data.
• BatchOpen(crs, 𝑆 = (𝑖 1, . . . , 𝑖𝑘 ), 𝜙 (𝑋 )) → 𝜋 : outputs a • FDE.Exc⟨C(com, tk), S(com, data)⟩ → ⟨C(data), S(tk)⟩.
proof for multiple evaluations of 𝜙 (𝑋 ) at indices 𝑆. The parties C and S engage in an interactive protocol to
• BatchVerify(crs, 𝐶, (𝑚𝑖 1 , . . . , 𝑚𝑖𝑘 ), (𝑖 1, . . . , 𝑖𝑘 ), 𝜋) → 0/1 exchange the data held by S and the tokens tk held by C over
verifies the batch proof. E.
A secure polynomial commitment scheme satisfies the following FDE protocols satisfy the following properties.
properties (for the full statements, please refer to e.g., [47]):
Definition 4.2 (FDE Correctness). If the client C and server S
Correctness: Honestly generated commitment and proofs verify
correctly. − FDE.Setup(1𝜆 ) and ⟨C(com), S(data)⟩ ←
are honest, given pp ← −
FDE.Com⟨C(data), S()⟩; with probability 1,
Polynomial Binding: No PPT adversary can generate a commit-
ment 𝐶 and two different polynomials 𝜙 (𝑋 ), 𝜙 ′ (𝑋 ) ∈ F𝑝≤𝑛 [𝑋 ] ∧ ⟨C(data), S(𝑝)⟩ ←
− FDE.Exc⟨C(com, 𝑝), S(com, data)⟩,
𝜙 (𝑋 ) ≠ 𝜙 ′ (𝑋 ), such that the commitment verifies against both i.e., C receives the data, and S receives tk tokens.
of them correctly,
i.e., they generate the
same commitment: 𝐶 =
The client-fairness property guarantees that the server cannot
Commit crs, 𝜙 (𝑋 ) = Commit crs, 𝜙 ′ (𝑋 ) 4 .
receive any payment if the client does not obtain the data, and
Evaluation Binding: No PPT adversary can generate a commit- server-fairness guarantees that the client cannot learn anything
ment 𝐶 and two different evaluations 𝜙 (𝑖) ≠ 𝜙 ′ (𝑖) on the same about the data without paying the server.
point 𝑖 with proofs 𝜋, 𝜋 ′ that would verify correctly.
Definition 4.3 (Client-Fairness). Given an honest client C, for
Polynomial commitments can be viewed as a special case of
any data from an appropriate space, for all PPT S ∗ , the following
vector commitments, where a data vector m = (𝑚 0, . . . , 𝑚 ℓ ) ∈ F𝑝ℓ+1
probability that C does not receive the whole data while S ∗ receives
is mapped to a polynomial 𝜙 (𝑋 ) ∈ F𝑝ℓ (𝑋 ) of degree ℓ, s.t. ∀𝑖 ∈
a positive payment5 is negligible in 𝜆:
[ℓ] : 𝜙 (𝑖) = 𝑚𝑖 [20], BatchOpen then allows to generate subvector-
 pp←FDE.Setup(1𝜆 ) 
opening proofs. FDE.Vrfy(data′ ,com)=0 ⟨ C (com),S (data) ⟩←FDE.Com⟨ C (data),S () ⟩ 

Pr 

∧ tk′ >0 Inputs: C (com,tk),S ∗ (com,data) 
⟨ C (data′ ),S ∗ (tk′ ) ⟩←FDE.Exc⟨ C,S ∗ ⟩ 
 
4 APPLICATION OF VECK: FAIR 
BLOCKCHAIN DATA EXCHANGE Definition 4.4 (Server-Fairness). Given an honest server S,
for all PPT C ∗ , there exists a PPT simulator Sim C∗ with oracle access
PROTOCOLS
to C ∗ s.t. for all possible values data, the following probability is less
We introduce the syntax of fair blockchain data exchange (FDE) than 12 + 𝜇 (𝜆) for a negligible function 𝜇 (·):
protocols and instantiate them by combining a VECK scheme with
 pp←FDE.Setup(1𝜆 ) 
smart contracts on Ethereum and adaptor signatures on Bitcoin.  ⟨ C (com),S (data) ⟩←FDE.Com⟨ C (data),S () ⟩ 
We define a transparent payment environment E as a trusted Inputs: C ∗ (com,tk),S (com,data) 


third party that holds money under addresses belonging to the Pr C ∗ (com, 𝛼𝑏 ) = 𝑏
 𝛼0 ←−tr(⟨ C ∗ ,S⟩ ←−FDE.Exc⟨ C ∗ ,S⟩) 
 Outputs: C ∗ (data′ ),S (tk′ ) s.t. tk′ <tk
other parties. It can transfer money from one party’s address to  −SimC∗ (pp,com,tk) 
𝛼1 ←

another but requires a message authorizing the transaction with the 
𝑏←
𝑅
− {0,1} 


sender’s signature. It is transparent in the sense that any message
Here, tr denotes the interactive protocol’s transcript. It includes all
sent to E eventually becomes visible to all other parties.
public inputs (the public parameters pp and commitment com), the
exchanged bits, the payment tk′ server gets, and the data data′ client
4.1 The FDE Protocol Syntax and Properties
C ∗ obtains as outputs. In other words, C ∗ does not learn anything
Definition 4.1 (Blockchain Data Exchange Protocols). A about the data other than FDE.Com(data) = com unless S receives a
FDE protocol consists of two PPT algorithms and two protocols be- payment of tk tokens.
tween a client C and a server S involving a transparent payment
environment E: Efficiency requirement. The asymptotic communication com-
• FDE.Setup(1𝜆 ) → pp. Probabilistic polynomial-time algo- plexity between the server and client in the FDE.Exc protocol is
rithm that outputs the public parameters for the system (e.g., linear in ℓ, the number of data blocks, as the client has to decrypt
the description of appropriate spaces). The public parame- every data block. Therefore, we will minimize the communication
ters are implicitly taken by all the following algorithms and complexity and size of the overhead of the FDE.Exc protocol on top
protocols; we omit them for brevity. of the exchanged data. We also minimize the amount of amortized
computation made by the parties as part of the FDE.Exc protocol.
4We only work with polynomials of degree ℓ by assuming that the size of the committed
data is known. 5We assume that the server S ∗ cannot ever receive payment greater than tk.
6
Atomic and Fair Data Exchange via Blockchain

4.2 The FDE Protocol on Ethereum 4.3.2 Protocol. Algorithms FDE.Setup(1𝜆 ), FDE.Vrfy(data, com)
Consider a client C interested in the output of a function 𝐹 (.) and the protocol FDE.Com⟨C(data), S()⟩ are instantiated as in Sec-
applied on a sequence of data (denoted by data = (𝑚 1, . . . , 𝑚 ℓ )) tion 4.2. The adaptor signature scheme used by the protocol is
attested by the polynomial (or vector) commitment com. In return, based on the relation satisfied by 𝑦 = sk and 𝑌 = vk with language
C offers some payment tk to the server S that stores the data. To 𝐿key = {vk|Verkey (vk, sk) = 1}. The FDE protocol proceeds as
facilitate this exchange, the FDE protocol uses a VECK scheme and follows:
a smart contract on Ethereum. 1) This is the same step as step (2) in Section 4.2, except that S
The relation used by the VECK scheme involves a polynomial (or sends both the verification key vk and the ciphertext ct to C.
vector) commitment, and FDE.Setup(1𝜆 ), FDE.Com⟨C(data), S()⟩ 2) The client verifies the ciphertext ct: Verct (com, vk, ct, 𝜋) → − 1/0.
and FDE.Vrfy(pp, data, com) are instantiated with the Setup and Then, it creates a bonding contract on Bitcoin that does the follow-
Commit algorithms for this polynomial commitment scheme (cf. ing: Before a timelock expires, it allows the spending of tk tokens
Section 3). Let 𝜙 (.) be the degree ℓ polynomial that takes the values by a transaction with two signatures: one must verify with respect
of the data points 𝑚𝑖 at inputs 𝑖 ∈ [ℓ]: 𝜙 (𝑖) = 𝑚𝑖 . Then; to S’s public key pk S , and the other must verify with respect to the
FDE.Setup(1𝜆 ) = Setup(1𝜆 , ℓ) → − pp. public key of the adaptor signature, i.e., pk𝜎 · vk. After the expiry,
the tokens can be spent to any address and returned to C with a
FDE.Com⟨C(data), S()⟩: C runs Commit(pp, 𝜙 (𝑋 )) →
− com and
signature that is created with C’s signing key sk C and that verifies
sends com to S.
under C’s public key pk C .
FDE.Vrfy(data, com) →
− [Commit(pp, 𝜙 (𝑋 )) = com]. 3) If the verification above succeeds, C also sends a pre-signature
The protocol FDE.Exc⟨C(com, 𝑝), S(com, data)⟩ proceeds as: on a transaction tx: 𝜎ˆ ← pSign(sk𝜎 , tx, vk), where tx transfers the
tokens in the bonding contract to S’s address.
1) The client C creates a smart contract called the bonding con-
tract on Ethereum that allows the spending of tk tokens to only 4) If the timelock has not expired yet, there are tk tokens locked
the address of the server S before a timelock expires. After it is in a correctly structured bonding contract and 𝜎ˆ verifies, namely,
deployed, the contract takes as input a verification key vk, tokens of pVerify(pk𝜎 , tx, 𝜎,ˆ vk) = 1, the server adapts the pre-signature us-
amount tk and sends the tokens to S only if it receives the correct ing the decryption key sk to get a full signature 𝜎 on the transaction
decryption key sk such that Verkey (vk, sk) = 1. After the timelock tx: 𝜎 ← Adapt(pk𝜎 , 𝜎, ˆ sk). It also signs tx with its signing key sk S
expires, the tokens are returned to C. corresponding to pk S and posts tx to Bitcoin with both signatures.
5) The client extracts sk from 𝜎: sk ← Extract(𝜎, 𝜎, ˆ vk). Using sk,
2) The server S encrypts the data using the VECK scheme for the it decrypts ct and retrieves the data: Dec(sk, ct) → − data.
function 𝐹 and the polynomial commitment scheme used by the
Note that the existence of both the adaptor signature and S’s signa-
FDE protocol (Section 3): Enc(com, data) →− (vk, sk, ct, 𝜋). It then
ture on tx prevents C from frontrunning the server. If tx were signed
posts vk to the contract and sends ct off-chain (along with the
by only the adaptor signature, upon receiving the adaptor signature
associated proof 𝜋) to the client C.
from the mempool, C could have extracted the decryption key sk,
3) The client verifies the ciphertext ct: Verct (com, vk, ct, 𝜋) →
− 0/1. and created another transaction, signed by the adapted signature
It then locks tk tokens in the contract. and spending the tokens to C’s address, before S’s transaction is
confirmed on Bitcoin.
4) The server S checks if C has locked the correct amount (tk) of
tokens. If the timelock has not expired yet, and there are tk tokens 4.4 Security Proof
locked in the contract, S posts the decryption key sk to the contract.
Theorem 4.1. Suppose the VECK scheme satisfies correctness, se-
The contract sends the tk tokens to S if Verkey (vk, sk) = 1.
curity and computational zero-knowledge, and Ethereum (Bitcoin)
5) The client reads sk from the contract. Using sk, it decrypts ct satisfies security with some finite latency. Then, for a sufficiently
and obtains the data: Dec(sk, ct) →
− data. long timelock period, the FDE protocol on Ethereum (Bitcoin) satisfies
correctness, client-fairness, and server-fairness.
4.3 FDE Protocol on Bitcoin The proof is given in Appendix C.1 and follows directly from the
4.3.1 Preliminaries. In the absence of smart contracts, we design a security of the VECK scheme and the security of Ethereum / Bitcoin.
bonding contract on Bitcoin using adaptor signatures. Consider a
signature scheme Σ = (KeyGen, Sign, Verify) and a hard relation 5 VECK CONSTRUCTIONS
R. Let (pk𝜎 , sk𝜎 ) ← KeyGen(1𝜆 ) and (𝑌, 𝑦) ∈ R. An adaptor sig- In this section, we design efficient instantiations of VECK schemes
nature scheme Sig with respect to Σ and 𝑌 consists of the following for selective openings of KZG polynomial commitments (Section 1).
four algorithms: 𝜎ˆ ← pSign(sk𝜎 , 𝑚, 𝑌 ), 𝑏 ← pVerify(pk𝜎 , 𝑚, 𝜎,
ˆ 𝑌 ), We start with preliminaries and recall KZG polynomial commit-
𝜎 ← Adapt(pk𝜎 , 𝜎, ˆ 𝑦) and 𝑦 ← Extract(𝜎, 𝜎, ˆ 𝑌 ). Here, 𝜎ˆ is a ments. Section 5.1 describes a VECK protocol based on the Deci-
ˆ and 𝜎
presignature, 𝑏 denotes the output of the verification for 𝜎, sional Diffie-Hellman (DDH) assumption and uses a symmetric
denotes the adapted signature (that verifies against the public key variant of exponential ElGamal encryption, whereas Section 5.2
pk𝜎 · 𝑌 ) from which 𝑦 can be extracted. For the FDE protocol on describes a scheme based on the Decisional Composite Residuosity
Bitcoin, we use adaptor signatures based on Schnorr signatures. (DCR) assumption and uses Paillier encryption.
For details on adaptor signatures, cf. Appendix A.5 and [27]. Preliminaries.
7
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

For a prime 𝑝, we use F𝑝 to denote the finite field of size 𝑝. A BatchVerify(crs, 𝐶, (𝑚𝑖 1 , . . . , 𝑚𝑖𝑘 ), (𝑖 1, . . . , 𝑖𝑘 ), 𝜋) → 0/1 accepts
bilinear operation 𝑒 : G1 × G2 → G𝑇 defined over three elliptic if the following holds:
curve groups G1, G2, G𝑇 of prime order 𝑝 and generators 𝑔1, 𝑔2, 𝑔𝑇 ,  Î𝑘 
satisfies the following properties: for any 𝑎, 𝑏 ∈ F𝑝 , 𝑒 (𝑔𝑎1 , 𝑔𝑏2 ) =

𝜙 (𝜏 )
 (𝜏 −𝑖 𝑗 )
𝑒 𝐶/𝑔1 𝑆 , 𝑔2 = 𝑒 𝜋, 𝑔2 𝑗 =1
𝑒 (𝑔1, 𝑔2 )𝑎𝑏 and generators are respected: 𝑒 (𝑔1, 𝑔2 ) = 𝑔𝑇 . Denote by
F𝑝 [𝑋 ] the ring of polynomials over F𝑝 , and by F𝑝ℓ [𝑋 ] ⊂ F𝑝 [𝑋 ] the
Here, 𝜙𝑆 (𝑋 ) is as defined above for BatchOpen.
group of polynomials of degree ℓ, by F𝑝≤ℓ [𝑋 ] ⊂ F𝑝ℓ [𝑋 ] – polynomi-
The scheme described above is polynomial- and evaluation-
als of degree at most ℓ. The Lagrange basis polynomial for a given
binding provided that the t-BSDH assumption holds in (G1, G2, G𝑇 ).
set 𝑆 ⊆ F𝑝 and 𝑥 ∈ 𝑆, denoted by 𝐿𝑥,𝑆 (𝑋 ) ∈ F𝑝 [𝑋 ], is defined as
follows:
Ö 𝑋 −𝑖 5.1 ElGamal-based VECK for KZG
𝐿𝑥,𝑆 (𝑋 ) = . Commitments
𝑥 −𝑖
𝑖∈S In this section, we present a VECK protocol based on the DDH
𝑖≠𝑥
assumption and prove its security in the Algebraic Group Model
𝐿𝑥,𝑆 (𝑋 ) has degree |𝑆 | − 1 and can alternatively be uniquely (AGM) [39] (cf. Appendix A.1.3). First, we build VECK protocols
defined by its |𝑆 | evaluations: 𝐿𝑥,𝑆 (𝑥) = 1 and 𝐿𝑥,𝑆 (𝑖) = 0 for for the function defined from polynomials of degree ℓ ≤ 𝑛, i.e.,
∀𝑖 ∈ 𝑆, 𝑖 ≠ 𝑥. When the set 𝑆 = {0, 1, . . . , ℓ } consists of ℓ + 1 conse- 𝜙 (𝑋 ) ∈ F𝑝≤𝑛 [𝑋 ] (where 𝑛 is the length of the crs and also an upper-
quitive integers, we denote the Lagrange polynomial by 𝐿𝑥,ℓ (𝑋 ) := bound on the polynomials that can be committed with this crs), to
𝐿𝑥,𝑆 (𝑋 ) For a polynomial 𝜙 (𝑋 ), we let 𝜙𝑆 (𝑋 ) denote the unique F𝑝ℓ+1 , that outputs their evaluations at the ℓ + 1 points specified by
polynomial of degree at most |𝑆 | − 1 that agrees with 𝜙 (𝑋 ) on the set [ℓ]:
the set 𝑆: ∀𝑖 ∈ 𝑆, 𝜙 (𝑖) = 𝜙𝑆 (𝑖). It can be constructed as follows:
Í
𝜙𝑆 (𝑋 ) := 𝑗 ∈𝑆 𝜙 ( 𝑗)𝐿 𝑗,𝑆 (𝑋 ). For an integer 𝐵, we denote by [𝐵] = full-eval
𝐹 [ℓ (𝜙) = (𝜙 (0), 𝜙 (1), . . . , 𝜙 (ℓ)) ∈ F𝑝ℓ+1 (5.1)
]
{0, 1, . . . , 𝐵} the set of consecutive integers from 0 to 𝐵.
KZG Polynomial Commitments. The KZG [47] scheme com- full-eval
For instance, when 𝜙 (𝑋 ) ∈ F𝑝ℓ [𝑋 ], i.e., is of degree ℓ, 𝐹 [ℓ
mits to univariate polynomials 𝜙 (𝑋 ) ∈ F𝑝≤𝑛 [𝑋 ] and works as fol- ]
lows: outputs ℓ + 1 evaluations of 𝜙 (𝑋 ) at the points in [ℓ]. The function
is index by full-eval since its output uniquely determines the input
Setup(1𝜆 , 𝑛) → crs : trusted setup that generates the group struc- polynomial. We first show the protocol for polynomials where each
ture G comprised of elliptic curve groups: G1, G2, G𝑇 of order evaluation is within a small range ∀𝑖 ∈ [ℓ] : 0 ≤ 𝜙 (𝑖) < B,
𝑝 ≥ 22𝜆 with generators 𝑔1, 𝑔2, 𝑔𝑇 respectively and bilinear pairing and then we show how to generalize the protocol to arbitrary
operation 𝑒 : G1 × G2 → G𝑇 . It samples a uniformly random secret polynomials 𝜙 (𝑋 ) ∈ F𝑝ℓ [𝑋 ].
𝜏 ←𝑅 F𝑝 and computes the public parameters The high-level intuition of our protocol is as follows. We use
𝑖 𝑖 exponential ElGamal to encrypt the 𝜙 (𝑖) values: ∀𝑖 ∈ [ℓ] : ct𝑖 :=
crs = (G, {𝑔𝜏1 }𝑛𝑖=1, {𝑔𝜏2 }𝑛𝑖=1 ). 𝜙 (𝑖 )
ℎ𝑠𝑖 · 𝑔1 ∈ G1 with independent generators 𝑔1, {ℎ𝑖 }𝑖=1ℓ ,ℎ ∈ G ,
1
Such setup can also be run through an MPC ceremony [7, 12, 53]. where the decryption key is sk = 𝑠 ∈ F𝑝 and the verification

𝜙 (𝜏 ) key is vk = ℎ𝑠 . Recall that in a VECK scheme, we want to prove
Commit crs, 𝜙 (𝑋 ) → 𝐶 : computes the commitment 𝐶 := 𝑔1 that ∀𝑖 ∈ [ℓ], ct𝑖 indeed encrypts 𝜙 (𝑖) for a secret polynomial
using the public parameters crs and the coefficients of 𝜙 (𝑋 ). 𝜙 (𝜏 )


𝜙 (𝑋 ) ∈ F𝑝ℓ [𝑋 ] KZG-committed by 𝐶𝜙 = 𝑔1 ∈ G1 for a trapdoor
VerifyPoly crs, 𝜙 (𝑋 ), 𝐶 → 0/1 : outputs 1 if Commit crs, 𝜙 (𝑋 ) = 𝜏. For this purpose, a pseudo-random challenge 𝛼 ∈ F𝑝 is sampled,
𝐶, and outputs 0 - otherwise. and the polynomial commitment 𝐶𝜙 is opened in the exponent at 𝛼
𝑞 (𝜏 ) 𝜙 (𝛼 )
Open(crs, 𝑖, 𝜙 (𝑋 )) → 𝜋 : outputs the opening proof 𝜋 := 𝑔1 , with a blinding factor 𝑠 (𝜏 − 𝛼) to yield blinded 𝑔1 . The verifier
where 𝑞(𝑋 ) := (𝜙 (𝑋 ) − 𝜙 (𝑖))/(𝑋 − 𝑖) is a quotient polynomial, in turn interpolates through the encryptions, combining them with
computed as the commitment using the public parameters, crs. Lagrange coefficients in order to get the ElGamal encryption of

𝜙 (𝑖 ) 𝜙 (𝛼). It then verifies that the value in the combined encryption
VerifyEval crs, 𝐶, 𝑖, 𝜙 (𝑖), 𝜋 → 0/1 : if 𝑒 (𝐶/𝑔1 , 𝑔2 ) = 𝑒 (𝜋, 𝑔𝜏2 /𝑔𝑖2 ) matches the blinded opening. The full protocol is described in detail
outputs 1, otherwise, outputs 0. in Figure 2.
BatchOpen(crs, 𝑆 = (𝑖 1, . . . , 𝑖𝑘 ), 𝜙 (𝑋 )) → 𝜋 : outputs the proof
𝑞 (𝜏 )
𝜋 := 𝑔1 , where 𝑞(𝑋 ) is a quotient polynomial defined as Theorem 5.1. The protocol described in Figure 2 is a secure VECK in
the random oracle and algebraic group models for function 𝐹 defined
𝜙 (𝑋 ) − 𝜙 𝐼 (𝑋 ) in Equation (5.1).
𝑞(𝑋 ) = Î ,
𝑖 ∈𝑆 (𝑋 − 𝑖)
Í We give the proof of this Theorem in Appendix C.2.
where 𝜙𝑆 (𝑋 ) = 𝑖 ∈𝑆 𝜙 (𝑖)𝐿𝑖,𝑆 (𝑋 ) is a polynomial of degree at most Alternative approach. We note that there is an alternative,
𝑘 − 1 that agrees with 𝜙 (𝑋 ) on 𝑆 6 . less efficient protocol that does not involve publishing 𝐶𝛼 as part
of the proof. The ciphertexts can be directly verified against the
6 Feistand Khovratovich [32] provide optimizations for BatchOpen when the set 𝑆 is commitment by checking that the discrete logarithm of 𝑄 ∗ with
a set of consecutive powers of the root of unity, and it is commonly used in practice. respect to 𝑄 matches that of vk with respect to ℎ, for 𝑄 defined as
8
Atomic and Fair Data Exchange via Blockchain

follows and 𝑄 ∗ = 𝑄 𝑠 : 𝑧𝑖 = 𝑟𝑖 + 𝑐𝜙 (𝑖) ∈ Z, and sends ct𝑖 , 𝑧𝑖 and 𝑊𝑖 to the verifier. The veri-
fier reconstructs 𝑇𝑖 and 𝑇 , and then checks 𝑐 = 𝐻 (vk, {ct𝑖 }, {𝑇𝑖 },𝑇 ).
ℓ Note this protocol, for technical reasons, uses a crs that commits
𝐿 (𝜏 )
Ö
𝑒 (ct𝑖 , 𝑔2 𝑖,ℓ ) = 𝑄 𝑠 · 𝑒 (𝐶𝜙 , 𝑔2 ) to Lagrange-basis polynomials instead of the more common mono-
𝑖=0 mial basis. It also uses an adaptation of standard discrete logarithm
ℓ
Ö 𝐿 (𝜏 ) equality proofs to the groups of unequal order.
𝑄= 𝑒 (ℎ𝑖 , 𝑔2 𝑖,ℓ ) Next, we prove that the protocol described above and formalized
𝑖=0
by Figure 4 is a secure VECK protocol.
However, this alternative approach requires ℓ computationally Theorem 5.2. The protocol in Figure 4 is a secure VECK in the
costly pairing operations and would be far less efficient for the random oracle and algebraic group models for function 𝐹 defined
client who does the ciphertext verification in our FDE protocol (for in Equation (5.1).
comparison, one pairing operation is 10x more expensive than one
exponentiation in G1 for the bn256 curve (see Table 15.1 of [11]), We give the proof of this theorem in Appendix C.3.
and multi-exponentiations can be done even faster). The protocol in Figure 4 has a negligible probability of correct-
Exponential ElGamal encryption only works for a small or low- ness failure. It can be modified to achieve perfect correctness by
entropy message space (e.g., M = {0, 1}32 ), as the decryption proce- restarting the encryptor until all of the 𝑧 values are in the range
dure outputs 𝑔𝑚 [0, 𝐴). However, this process would result in a significant slow-
1 ∈ G1 , and obtaining the message 𝑚 ∈ M requires
the decryptor to brute-force the discrete logarithm of 𝑔𝑚 down of the encryption. For practicality, we suggest the version
1 to find 𝑚.
Hence, we had to bound the evaluations of the polynomial. A com- with a negligible probability of correctness failure.
mon practice to adapt it to large messages is to split the message Concrete parameters: For an instantiation of this protocol at
(e.g., M = {0, 1}256 ) into some 𝑘 chunks of size 𝐷 = log2 (|M|)/𝑘 𝜆-bits security level (e.g., 𝜆 = 128), we would set 𝐵 ≈ 22𝜆 to achieve
and encrypt these chunks separately, accompanying each encryp- collision resistance for the hash function at 𝜆-bits security, and
tion with a zero-knowledge range proof showing that the encrypted 𝑝 = 22𝜆 for the hardness of the discrete logarithm problem to be
value is within the range [0, . . . , 2𝐷 − 1], where 𝐷 is such that it at 𝜆-bits security level in the elliptic curve groups. Then, for any
is efficient to brute force a discrete logarithm computation as in practical vector length 𝑛 ≪ 2𝜆 , we get 𝐴 ≥ 26𝜆 and 𝑁 ≥ 28𝜆+2 .
the decryption algorithm of Figure 2. We explain this approach in Therefore, for 𝜆 = 128, the length of the modulus 𝑁 should be at
detail in Figure 3, and we show the parts of the protocol that need least 2050 bits, which is a reasonable size RSA modulus widely used
to be modified. in production today.
Optimizations: Note that computing (𝑁 + 1)𝑎 mod 𝑁 2 = 1 + 𝑎𝑁
5.2 Paillier Encryption with KZG Commitments mod 𝑁 2 is very cheap. Computing 𝑈𝑖𝑁 mod 𝑁 2 is expensive but
The VECK based on exponential ElGamal has an inherent down- can be done in advance. Decryption can be calculated twice: once
side: while transmitting a message 𝑚 ∈ M, the ciphertext size mod 𝑝 2 and once mod 𝑞 2 instead of mod 𝑁 2 by using 𝐿𝑝 (𝑥) =
and accompanying proofs are blown up by a factor of log2 (|𝑀 |)/𝐷. (𝑥 − 1)/𝑝 and 𝐿𝑞 (𝑥) = (𝑥 − 1)/𝑞 instead of normal 𝐿(·) respectively.
This section explores an alternative approach using Paillier encryp- These two “partial decryptions” can be combined into 𝑚 using the
tion [55] to avoid the aforementioned ciphertext blow-up. Paillier Chinese Remainder Theorem.
encryption allows encrypting arbitrary messages 𝑚 ∈ Z𝑁 with a
ciphertext-to-message length ratio of two: |𝑐 |/|𝑚| = 2. However, we
will be encrypting dlog values, so our ciphertext-to-message length 5.3 VECK for subset openings of KZG
ratio would be: |𝑐 |/|𝑚| = 2𝑁 /𝑝. We recall how Paillier encryption commitments
works in Appendix A.4, and in Figure 4, we show the VECK proto- Here we show how to build VECK for encrypting subvectors of
col that allows a server to prove in zero-knowledge that the Paillier evaluations of the committed polynomial, namely VECK for the
ciphertexts {ct𝑖 }𝑖 ∈ [ℓ ] encrypt the evaluations {𝜙 (𝑖)}𝑖=0ℓ of a KZG |𝑆 |
function 𝐹𝑆 : F𝑝ℓ [𝑋 ] → F𝑝 , where 𝑆 ⊆ F𝑝 , |𝑆 | ≤ ℓ + 1:
committed polynomial 𝜙.
We take inspiration from the Fouque and Stern construction [37] 𝐹𝑆 (𝜙) = {𝜙 (𝑖)}𝑖 ∈𝑆 (5.2)
of a one-round distributed key generation protocol, where they In the previous sections we showed constructions for the case of
show how to prove the recoverability of discrete logarithm values 𝑆 = [ℓ] = {0, 1, . . . , ℓ }, we note that they trivially generalize to any
from the Paillier ciphertext. arbitrary set 𝑆 of the same size |𝑆 | = ℓ + 1. We refer to such scheme
The high-level intuition for our protocol (it is a Σ-protocol) is as a VECK for the full opening function 𝐹 full-eval . We now show how
as follows. The verification key is vk = 𝑁 and the secret key is to support smaller sets (compared to the degree of the committed
the factorization of 𝑁 . The prover encrypts the evaluations of 𝜙 polynomial, ℓ) using the full opening VECK as subroutine.
with ℓ + 1 Paillier ciphertexts: ct𝑖 = (𝑁 + 1)𝜙 (𝑖 ) 𝑈𝑖𝑁 mod 𝑁 2 for
Î
At a high level, we generate a polynomial 𝑉𝑆 (𝑋 ) = 𝑖 ∈𝑆 (𝑋 − 𝑖)
𝑖 ∈ [ℓ], where 𝑈𝑖 ←𝑅 Z∗𝑁 . It then encrypts the evaluations of of degree |𝑆 | − 1 which vanishes on the set 𝑆, and we generate a
Í
ℓ + 1 randomly sampled values: 𝑇𝑖 = (𝑁 + 1)𝑟𝑖 𝑆𝑖𝑁 mod 𝑁 2 for polynomial 𝜙𝑆 (𝑋 ) = 𝑖 ∈𝑆 𝜙 (𝑖)𝐿𝑖,𝑆 (𝑋 ) of degree |𝑆 | − 1 that agrees
𝑟𝑖 ←𝑅 [0, 𝐴) and 𝑆𝑖 ←𝑅 Z∗𝑁 and generates a KZG commitment 𝑇 with 𝜙 (𝑋 ) on the set 𝑆. We next sample a random 𝑡 ←𝑅 F𝑝 and
to the polynomial with evaluations 𝑟𝑖 . After computing a random create a blinded polynomial 𝜙𝑆′ (𝑋 ) = 𝜙𝑆 (𝑋 ) + 𝑡𝑉𝑆 (𝑋 ) of degree
challenge 𝑐 = 𝐻 (vk, {ct𝑖 }, {𝑇𝑖 },𝑇 ), it finds 𝑊𝑖 = 𝑆𝑖 𝑈𝑖𝑐 mod 𝑁 2 and |𝑆 | − 1. This polynomial agrees with 𝜙 (𝑋 ) on the set 𝑆. Therefore
9
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

𝑖 𝑖
Gen(crs) → pp: On input crs = (G, {𝑔𝜏1 }𝑛𝑖=1, {𝑔𝜏2 }𝑛𝑖=1 ), generate random group elements with unknown discrete logarithms ℎ𝑖 ←𝑅
G1, ℎ ←𝑅 G1 for 𝑖 ∈ [𝑛]. In practice, these can be generated using a Hash-to-Curve [8] function 𝐻 curv : F𝑝 →
− G1 , ℎ𝑖 := 𝐻 curv (𝑖).
Output pp = (crs, {ℎ𝑖 }𝑛𝑖=0, ℎ).
full-eval , 𝐶 , 𝜙 (𝑋 )) →
Enc(𝐹 [ℓ − (vk, sk, ct, 𝜋) :
] 𝜙
(1) Sample 𝑠 ←𝑅 F𝑝 , set sk := 𝑠, vk = ℎ𝑠 .
𝜙 (𝑖 )
(2) Compute the encryptions {ct𝑖 := ℎ𝑠𝑖 · 𝑔1 }𝑖=0
ℓ .
(3) Generate a Fiat-Shamir pseudo-random challenge 𝛼 := H(𝐶𝜙 , ct0, . . . , ctℓ , [ℓ]).a
𝜙 (𝛼 )+𝑠 (𝜏 −𝛼 )
(4) Compute 𝐶𝛼 := 𝑔1 .
(𝜙 (𝜏 ) −𝜙 (𝛼 ) )/(𝜏 −𝛼 ) −𝑠
(5) Compute the opening proof for 𝛼: 𝜋𝛼 := Open(crs, 𝛼, 𝜙 (𝑋 ) − 𝑠 (𝑋 − 𝛼)) (note that 𝜋𝛼 = 𝑔1 ).
(6) Compute 𝜋LIN to prove that 𝐶𝛼 is indeed of the form 𝑔1 raised to a known power, multiplied by 𝑔𝜏1 −𝛼 raised to the secret 𝑠
of the verification key, i.e., we compute the proof for the relation R LIN as described in the Appendix A.2, Equation (A.4):
𝑔1,1 = 𝑔1 𝑔1,2 = 𝑔𝜏1 −𝛼 𝑢 1 = 𝐶𝛼
 
𝑥 1 = 𝜙 (𝛼)
R LIN = ; 𝑔𝑥1,11 𝑔𝑥1,22 = 𝑢 1 ∧ 𝑔𝑥2,11 𝑔𝑥2,22 = 𝑢 2 .
𝑔2,1 = 1 𝑔2,2 = ℎ 𝑢 2 = vk 𝑥2 = 𝑠
Îℓ 𝐿 (𝛼 ) − (𝜏 −𝛼 )
(7) Compute 𝑄 := 𝑖=0 ℎ𝑖 𝑖,ℓ · 𝑔1 .
(8) Compute discrete logarithm equality 𝜋DLeq with respect to (𝑄, 𝑄 𝑠 , ℎ, vk) for the witness 𝑠, i.e., we compute the proof for
the relation R DLeq as described in the Appendix A.2, Equation (A.3):
R DLeq := {((𝑔 = 𝑄, ℎ, 𝑎 = 𝑄 𝑠 , 𝑏 = vk); 𝑥 = 𝑠) | 𝑎 = 𝑔𝑥 ∧ 𝑏 = ℎ𝑥 }.
(9) Output (sk, vk, ct = [ct0, . . . , ctℓ ], 𝜋 = (𝐶𝛼 , 𝜋𝛼 , 𝜋LIN, 𝜋DLeq )).
full-eval , 𝐶 , vk, ct, 𝜋) →
Verct (𝐹 [ℓ − 0/1 :
] 𝜙
(1) Parse ct = (ct0, . . . , ctℓ ) and the server’s proofs 𝜋 = (𝐶𝛼 , 𝜋𝛼 , 𝜋LIN, 𝜋DLeq ).
(2) Verify 𝜋LIN for 𝐶𝛼 against 𝑔1, 𝑔𝜏1 −𝛼 , ℎ, 𝐶𝛼 , vk.
(3) Compute the Fiat-Shamir challenge: 𝛼 := H(𝐶𝜙 , ct0, . . . , ctℓ ).
(4) Verify the opening proof 𝜋𝛼 : 𝑒 (𝐶𝜙 /𝐶𝛼 , 𝑔2 ) = 𝑒 (𝜋𝛼 , 𝑔𝜏2 −𝛼 ).
(5) Compute 𝑄 as above for encryption.
𝐿 (𝛼 )
∈ G1 , and 𝑄 ∗ := ct/𝐶𝛼 .
Îℓ
(6) Compute ct := 𝑖=0 ct𝑖 𝑖,ℓ
(7) Verify 𝜋DLeq for the relation (𝑄, 𝑄 ∗, ℎ, vk).
(8) If any of the verification checks fail, output 0. Otherwise, output 1.
Verkey (vk, sk) → − 0/1 : For sk = 𝑠 ∈ F𝑝 , return 1 if and only if vk = ℎ𝑠 .
full-eval
Dec(𝐹 [ℓ ] , sk, ct) → ℓ
− {𝜙 (𝑖)}𝑖=0 : For sk = 𝑠 ∈ F𝑝 , for each 𝑖 ∈ [ℓ], recover the value 𝑥 = 𝜙 (𝑖) by brute-forcing 𝑥 ∈ [B] in
𝑥 𝑠
𝑔1 = ct𝑖 /ℎ𝑖 . Pollard’s rho algorithm for logarithms [58], Shank’s baby-step-giant-step algorithm [64] or brute-force with
pre-computed tables [21] could be helpful to find the right trade-off between decryption memory and time.
a Generalizing to more general subsets 𝑆 other than [ℓ ] , the description of the subset 𝑆 would be part of the input of H(·) generating the Fiat-Shamir challenge.

Figure 2: A VECK protocol instantiated with the exponential ElGamal encryption and KZG polynomial commitment schemes
for the function 𝐹 defined in Equation (5.1).

we can use full-opening VECK for polynomial 𝜙𝑆 (𝑋 ) on the set Theorem 5.3. The protocol described in Figure 5 is a secure VECK
𝑆 ′ = 𝑆 ∪ {−1} to get the encryptions of values 𝜙 (𝑖) for 𝑖 ∈ 𝑆 and, for function 𝐹 defined in Equation Equation (5.2).
additionally, an encryption of its value at (−1) (evaluation of 𝜙𝑆 (𝑋 )
on point (−1)) to assist with VECK ciphertext verification. By the We give the proof in Appendix C.4.
zero-knowledge property of the full-opening VECK, this encryption
would leak no additional information about the polynomial. 6 PERFORMANCE EVALUATION
An important property of our scheme, is that the output of en- In this section, we report on the asymptotic and concrete perfor-
cryption can also be computed without knowing the full polynomial mance metrics of an implementation of our FDE protocols.
𝜙 (𝑋 ), but only knowing the subset of evaluations: {𝜙 (𝑖)}𝑖 ∈𝑆 and the
batch opening proof for this subset. It makes our scheme also appli- 6.1 Theoretical performance
cable to distributed data-storage, where independent servers store Our FDE protocols consist of three rounds: first, the server sends
the commitment 𝐶𝜙 , subsets of evaluations and the batch-proof the ciphertexts and proofs. Second, the client locks money on-chain,
(e.g. Danksharding see the discussion Section 8 and Appendix A.3 and finally, the server reveals its VECK decryption key. Note that the
for more details). withdrawal rounds can be amortized over multiple protocol runs as
one does not necessarily need to withdraw their earned (or locked)
10
Atomic and Fair Data Exchange via Blockchain

Gen(crs) → pp: Let the bound be B = poly(𝜆). request the same data with amortized prover costs, cf. Section 7.
log 𝑝
Let 𝑘 be such that B = 2⌈ 𝑘 ⌉. The prover’s amortized overhead for proving the consistency of
Generate ℎ𝑖,𝑗 ←𝑅 G1 for 𝑖 ∈ [𝑛], 𝑗 ∈ [𝑘]. 4, 096 BLS12-381 field elements (≈ 128 KiB) with respect to ElGamal
ciphertexts takes less than 40 ms. Prover time in the exponential
full-eval , 𝐶 , 𝜙 (𝑋 )) →
Enc(𝐹 [ℓ − (vk, sk, ct, 𝜋) : ElGamal protocol for a small number of exchanged points is domi-
] 𝜙
nated by the computation of the FFTs (i.e., computing the quotient
(2) For ∀𝑖 ∈ [ℓ], let 𝜙 (𝑖) = 𝜙𝑖,0 + 𝜙𝑖,1 B + . . . + 𝜙𝑖,𝑘 B𝑘 , polynomial 𝑞(𝑋 ) in Step 5 of the protocol in Figure 2). Therefore, we
for 𝜙𝑖,𝑗 ∈ [B] for ∀𝑗 ∈ [𝑘]. observe that the proving overhead is larger for transferring fewer
𝜙
Compute {ct𝑖,𝑗 := ℎ𝑠𝑖,𝑗 · 𝑔1 𝑖,𝑗 }𝑘𝑗=0 . BLS12-381 scalar field elements. However, for larger exchanged
Compute range-proof of encrypted values: data, ElGamal encryption and the range proof generation dominate
𝜋range (attesting to 𝜙𝑖,𝑗 ∈ [B]). our ElGamal prover time. On the other hand, proof generation in
(3) 𝛼 := H(𝐶𝜙 , {ct𝑖,𝑗 }𝑖 ∈ [ℓ ],𝑗 ∈ [𝑘 ] ). the Paillier-based protocol (cf. Figure 4) is monotonically increasing
Îℓ Î𝑘  𝐿 (𝛼 ) in the number of transferred data points. For 4, 096 BLS scalar field
B 𝑗 𝑖,ℓ − (𝜏 −𝛼 )
(7) 𝑄 := 𝑖=0 ℎ
𝑗=0 𝑖,𝑗 · 𝑔1 . elements, proof generation takes on average ≈ 5.09 s.
(9) Output (sk, vk, ct = {ct𝑖,𝑗 } (𝑖 ∈ [ℓ ],𝑗 ∈ [𝑘 ] ) ,
Proof size We implemented our exponential ElGamal protocol
𝜋 = (𝐶𝛼 , 𝜋𝛼 , 𝜋LIN, 𝜋DLeq, 𝜋range ).
full-eval , 𝐶 , vk, ct, 𝜋) →
(Section 5.1) with the range proof derived from the homomorphic
Verct (𝐹 [ℓ ] 𝜙 − 0/1 : polynomial commitment schemes by Boneh et al. [10]. These range
Îℓ Î𝑘  𝐿 (𝛼 )
(6) Compute ct := 𝑖=0 ct B 𝑗 𝑖,ℓ ,
proofs can be batched to improve the proof size (two G1 elements
𝑗=0 𝑖,𝑗 for any number of ranges) and the verifier’s concrete efficiency by
𝑄 ∗ := ct/𝐶𝛼 , replacing O (𝑛) pairing computations with O (𝑛) MSMs in G1 . We
check 𝜋 range against {ct𝑖,𝑗 } (𝑖 ∈ [ℓ ],𝑗 ∈ [𝑘 ] ) . leave this optimization for future work. To exchange 4, 096 BLS
scalar field elements (0.13 MB), the total bandwidth (cipher texts
Figure 3: Modifications to Figure 2 to remove the bound on and proofs) is 1, 56 MB in the exponential ElGamal protocol (with
the evaluations 𝜙 (𝑖) and support arbitrary polynomials of 𝑘 = 8 chunks per BLS field element), while 6, 55 MB in the Paillier-
degree ℓ. The precise relation for the range proofs is provided based protocol (𝜆 = 128, thus, log2 (𝑁 ) = 3072). This constitutes a
in Equation (A.5) in Appendix A.2. 11, 95× (and 50, 18×) factor bandwidth overhead in our protocols,
respectively, in comparison to the size of the exchanged data. In
conclusion, we observe that the Paillier-based protocol does not
coins after each exchange. The server’s proofs are constant-sized in improve concretely the bandwidth costs of the exponential ElGamal
the exponential ElGamal-based protocol, cf. Figure 2 and linear in protocol (cf. Figure 2) due to its larger cryptographic groups and the
the Paillier-based protocol, cf. Figure 4. In both protocols, the client linear-sized VECK proofs (cf. Figure 4). It is an interesting future
needs to submit only a single signature. The on-chain footprint of direction to design constant-sized VECK proofs with the Paillier-
our protocols consists of three signatures (two transactions from encryption scheme.
the server, one from the client) and two group elements (sk and Verifier time Verifying the proofs is slightly more expensive but
vk of the underlying VECK scheme). We compare our asymptotic still efficient. In particular, verifying the correctness of 4, 096 El-
performance with related work in Table 1. Gamal ciphertexts with respect to a KZG commitment using the
protocol in Figure 2 takes around 34.15 s. The verifier’s time strictly
6.2 Implementation performance increases in the number of opened points as it is dominated by
To measure concrete performance, we created a proof of concept multi-scalar multiplications that have sizes proportional to the
implementation of our protocols using Rust v1.74.0 and Solidity number of exchanged data points. It should be noted that the veri-
v0.8.13. All our source code is publicly available7 . fier time is dominated by the split scalar encryption verification,
All experiments were run on a consumer-grade PC with an AMD meaning that the verifier needs to check whether an encrypted
Ryzen 5 3600 (6-core) CPU and 8GB RAM. We used the Criterion field element is properly split into smaller field elements within the
benchmarking crate8 to measure the execution time of the prover brute-forceable range. With lookup tables, decryption of ElGamal
and the verifier in our protocols. Each measurement was repeated ciphertexts would be quick and negligible in terms of compute
10 times, and below, we report the mean of these protocol runs. costs. Verifying the proof of correctness in the Paillier-based pro-
tocol for 4, 096 BLS scalars takes roughly 19.45 s. Decrypting the
6.2.1 Off-chain costs.
4, 096 Paillier ciphertexts takes ≈ 9.54 s.

Prover time. In the exponential ElGamal scheme, we used 𝑘 = 8, 6.2.2 On-chain costs.
that is, each BLS12-381 scalar is split into 𝑘 smaller plaintexts. Range Bitcoin. We include the Bitcoin Script corresponding to the bond-
proofs and exponential ElGamal encryptions are computed in 89
ing contract of Section 4.3 in Appendix B.1. The script contains two
s for 4, 096 exchanged BLS12-381 points (cf. Figure 6). This is a
conditional executions. One execution uses a timelock and enables
one-time cost for the prover and can serve multiple clients who
the spending of the locked tokens by the client after a timeout
7 https://github.com/PopcornPaws/fde. period. The other enables the spending of the funds by any trans-
8 https://crates.io/crates/criterion. action carrying the adaptor signature and the server’s signature.
11
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

Gen(crs) → pp: On input crs = (G, {𝑔𝜏1 }𝑛𝑖=1, {𝑔𝜏2 }𝑛𝑖=1 ), where 𝜏 is the secret trapdoor, let H : {0, 1}∗ → [0, 𝐵) denote a hash function,
𝑖 𝑖

and 𝐴 := 𝐵𝑝ℓ2𝜆 .
full-eval
Enc(𝐹 [ℓ ] , 𝐶𝜙 , 𝜙 (𝑋 )) →
− (vk, sk, ct, 𝜋) :
√
(1) Generate keys for Paillier encryption: let 𝑝 ′, 𝑞 ′ ←𝑅 Primes(1𝜆 ), and compute the modulus 𝑁 := 𝑝 ′𝑞 ′ , s.t. 𝑁 ≥ 2 2𝐴𝐵. Let
𝜇 := lcm(𝑝 ′ − 1, 𝑞 ′ − 1), where lcm(·, ·) returns the least common multiple of two integers. We set the Paillier public key
vk := 𝑁 , and the secret key sk := (𝑝 ′, 𝑞 ′, 𝜇).
(2) Calculate the encryptions of {𝜙 (𝑖)}𝑖 ∈ [ℓ ] : for each 𝑖 ∈ [ℓ] sample 𝑈𝑖 ←𝑅 Z∗𝑁 and compute ct𝑖 := (𝑁 + 1)𝜙 (𝑖 ) 𝑈𝑖𝑁 mod 𝑁 2 .
Î  𝐿𝑖,[ℓ ] (𝜏 )  𝑟𝑖
(3) For each 𝑖 ∈ [ℓ] sample 𝑆𝑖 ←𝑅 Z∗𝑁 , 𝑟𝑖 ←𝑅 [0, 𝐴) and compute 𝑇𝑖 := (𝑁 + 1)𝑟𝑖 𝑆𝑖𝑁 mod 𝑁 2 . Let 𝑇 := 𝑔1 .
𝑖 ∈ [ℓ ]
(4) Sample a random challenge 𝑐 := H(vk, ct0, . . . , ctℓ , 𝐶𝜙 ,𝑇0, . . . ,𝑇ℓ ,𝑇 ) using the Fiat-Shamir transformation.
(5) Compute ∀𝑖 ∈ [ℓ] : 𝑊𝑖 := 𝑆𝑖 𝑈𝑖𝑐 mod 𝑁 2 and 𝑧𝑖 := 𝑟𝑖 + 𝑐𝜙 (𝑖) over the integers (𝑧𝑖 ∈ Z).
(6) Output (sk, vk, ct = (ct0, . . . , ctℓ ), 𝜋 = (𝑐,𝑊0, . . . ,𝑊ℓ , 𝑧 0, . . . , 𝑧 ℓ )).
full-eval , 𝐶 , vk, ct, 𝜋) →
Verct (𝐹 [ℓ − 0/1 :
] 𝜙
(1) Parse the input ct = (ct0, . . . , ctℓ ) and 𝜋 = (𝑐,𝑊0, . . . ,𝑊ℓ , 𝑧 0, . . . , 𝑧 ℓ )).
(2) Reject the proof if any of the z values are not within [0, 𝐴).
Î  𝐿𝑖,[ℓ ] (𝜏 )  𝑧𝑖 𝑐
(3) Compute ∀𝑖 ∈ [ℓ] : 𝑇𝑖 := (𝑁 + 1)𝑧𝑖 𝑊𝑖𝑁 ct𝑖−𝑐 mod 𝑁 2 , and 𝑇 := 𝑔1 /𝐶𝜙 .
𝑖 ∈ [ℓ ]
(4) Accept if 𝑐 = H(vk, ct0, . . . , ctℓ , 𝐶𝜙 ,𝑇0, . . . ,𝑇ℓ ,𝑇 ).
− 0/1 : Return 1 if and only if vk = 𝑁 = 𝑝 ′𝑞 ′ for sk = (𝑝 ′, 𝑞 ′ ).
Verkey (vk, sk) →
𝜇
full-eval , sk, ct) → 𝐿 (ct mod 𝑁 2 ) 𝑥 −1 2
Dec(𝐹 [ℓ ]
− {𝑚𝑖 }𝑖 ∈ [ℓ ] : Compute ∀𝑖 ∈ [ℓ] : 𝑚𝑖 = 𝐿 ( (𝑁 +1)
𝑖
𝜇 mod 𝑁 2 ) mod 𝑁 , where 𝐿(𝑥) = 𝑁 for 𝑥 < 𝑁 ∧ 𝑥 ≡ 1
Í
mod 𝑁 . Construct a polynomial 𝑚(𝑋 ) = 𝑖 ∈ [ℓ ] 𝑚𝑖 𝐿𝑖,ℓ (𝑋 ) and check that C𝜙 = KZG.Commit(crs, 𝑚(𝑋 )), if equality holds,
we are done. Otherwise, following [37] for each 𝑚𝑖 , we search the values (𝜎1, 𝜎2 ) that constitute the smallest vector in the
lattice of dimension two with basis ((𝑁 , 0), (𝑚𝑖 , 1)). The smallest vector can be found in time 𝑂 (log 𝑁 ) using Gauss algorithm
(see [25], p.23). We then set 𝑚𝑖 := 𝜎1 /𝜎2 mod 𝑝.

Figure 4: A VECK protocol instantiated with the Paillier encryption and the KZG polynomial commitment scheme for encrypting
polynomial’s evaluations.

We expect the transaction fee of the bonding contract (≈ 231 Bytes) Transaction Gas cost USD cost
to be below $10 for a confirmation time of 1 hour on Bitcoin [9] ElGamal Paillier ElG. Pail.
regardless of the data size.
serverSendsPubKey 158, 449 176, 296 5.11 $ 5.68 $
clientLocksPayment 30, 521 30, 521 0.98 $ 0.98 $
serverSendsSecKey 73, 692 82, 475 2.37 $ 2.65 $
Ethereum All of our protocols in Section 4, except the protocol
withdrawPayment 43, 836 43, 836 1.41 $ 1.41 $
in Section 4.3, rely on the same on-chain smart contract logic that
guarantees the atomicity of our fair exchange protocols. We imple- Table 2: EVM gas costs of the smart contract components
mented this FDE bonding logic for the Ethereum Virtual Machine for 𝜆 = 128 bits of security. Note these costs are constant
(EVM), compiled from Solidity (our full source is included in Ap- in the size of the exchanged data. (cf. Appendix B.2), in the
pendix B.2). The smart contract implements four functionalities ( Exponential Elgamal (cf. Figure 2) and Paillier encryption-
cf. Figure 1), and we report the EVM gas costs for each in Table 2. based FDE schemes (cf. Figure 4). For the USD costs, we used
First, the server registers its public key on the blockchain in a com- the transaction fee 14 GWei and 2, 302.35 USD/ETH exchange
pressed form, i.e., only the 𝑥-coordinate of its public key by calling rate as of 2024 February 3rd.
the serverSendsPubKey function. Additionally, the server sets the
agreed price of the exchanged data. Afterward, the client locks her
payment by calling the clientLocksPayment function according to
the previously agreed price. Third, the server sends the decryption
key of the VECK scheme and calls the serverSendsSecKey function.
aforementioned operations are highly efficient and affordable on
This function ensures that the contract verifies that the provided
today’s Ethereum in both of our protocols.
decryption key sk matches the public key vk the server submit-
ted in the first step. Finally, the parties can withdraw their money
with the withdrawPayment function: the server can withdraw if 7 MULTI-CLIENT MODEL
it has provided the decryption key, while the client can withdraw In certain applications of the FDE protocol, the server is expected to
its locked payment after a timeout if the server fails to reveal the provide the same data to multiple clients over time. For instance, in
decryption key sk for the data. We observe in Table 2, that all the blockchain applications, light clients might query the same blocks
12
Atomic and Fair Data Exchange via Blockchain

Gen(crs) → pp: Output the result of FGen(crs). for the messages. In the multi-client model, we would like to guar-
Enc(𝐹𝑆 , 𝐶𝜙 , 𝜙 (𝑋 )) → − (vk, sk, ct, 𝜋): antee that a client cannot obtain the messages without getting the
(1) Sample 𝑡 ←𝑅 F𝑝 and construct the following polyno- ciphertexts and the decryption key from the server, except when
mials in F𝑝 [𝑋 ]: it downloads the data from one of the other clients. Clients can
Î
• 𝑉𝑆 (𝑋 ) := 𝑖 ∈𝑆 (𝑋 − 𝑖), communicate with each other, but the total number of bits, received
Í
• 𝜙𝑆 (𝑋 ) := 𝑖 ∈𝑆 𝜙 (𝑖)𝐿𝑖,𝑆 (𝑋 ) by a client from the other clients cannot exceed a constant 𝐿.
′
• 𝜙𝑆 (𝑋 ) := 𝑡𝑉𝑆 (𝑋 ) + 𝜙𝑆 (𝑋 ), In the setting of multiple clients, we can save the server some
(2) Compute 𝐶𝑆 := Commit(crs, 𝜙𝑆′ (𝑋 )). work by moving parts of the proof generation to a preprocessing step
(3) Compute 𝜋𝑆 := Commit(crs, (𝜙 (𝑋 )-𝜙𝑆′ (𝑋 ))/𝑉𝑆 (𝑋 )). that is amortized across all clients querying the same data. Thus,
(4) Let 𝑆 ′ := 𝑆 ∪ {−1} we distinguish between the preprocessing phase of the protocol
(5) Run Enc(𝐹𝑆full-eval
′ , 𝐶𝑆 , 𝜙𝑆′ (𝑋 )) →− (vk, sk, ct, 𝜋 ′ ) and the online phase that is repeated for each client. To illustrate
(6) Output (vk, sk, ct, 𝜋 = (𝐶𝑆 , 𝜋𝑆 , 𝜋 ′ )). this distinction, consider an example with 𝐿 = 0. In this case, S has
to generate an encryption of the messages and the proof only once,
Verct (𝐹𝑆 , 𝐶𝜙 , vk, ct, 𝜋) →− 0/1:
and can reuse the same ciphertexts and the proof across all clients.
(1) Parse 𝜋 as (𝐶𝑆 , 𝜋𝑆 , 𝜋 ′ ). Since the proof is generated only once, S can pick a symmetric key
𝑉 (𝜏 )
(2) Verify 𝑒 (𝐶𝜙 /𝐶𝑆 , 𝑔2 ) = 𝑒 (𝜋𝑆 , 𝑔2 𝑆 ). encryption scheme with secret key 𝛼 (succinct in 𝑛)9 that has an
(3) Run Verct (𝐹𝑆 ′ full-eval , 𝐶𝑆 , vk, ct, 𝜋 ′ ), where 𝑆 ′ is de- efficient decryption algorithm and a small message complexity for
fined above. the ciphertexts, but not necessarily a fast algorithm for generating
Verkey (vk, sk) → − 0/1: Output the result of FVerkey (vk, sk). a VECK proof. Then, it can leverage the power of a generic SNARK
Dec(𝐹𝑆 , sk, ct) → − {𝜙 (𝑖)}𝑖 ∈𝑆 : Output the result of with an efficient constant time verifier and a small constant size
FDec(𝐹𝑆 ′ , sk, ct) (𝑆 ′ is defined above). proof (e.g., [40, 41]) to generate the proof. As the encryption and the
proof generation are not repeated per client, this scheme achieves a
small amortized proving cost for large 𝐾 and reduces the ciphertext
Figure 5: VECK protocol for encryptions of subsets of com- decryption time and proof verification time.
mitted vectors, i.e., function of Equation (5.2). In practice, clients do communicate with each other. When they
are able to convey each other the whole length 𝑁 message sequence,
i.e., 𝐿 = O (𝑁 log(|M|)) bits, S cannot expect to profit from its inter-
ElGamal Verifier ElGamal Prover
Paillier Verifier Paillier Prover action with the clients, since the first client to receive the messages
could broadcast it to the others, making any further communica-
104
tion obsolete. However, this implicitly assumes that clients can act
as servers themselves, which contradicts the premise of the FDE
problem in the first place. Thus, in this section, we assume that
Time (ms)

103 𝐿 = 𝑜 (𝑁 log(|M|) + 𝜆). Note that a small 𝐿 still yields a non-trivial

problem, as S can no longer use the same secret key 𝛼 for all clients,
lest they share the key with each other.
102
7.2 Security Definition
We now define the security properties for MC-VECK.
101
Definition 7.1 (multi-client-VECK). A non-interactive Multi-
21 23 25 27 29 211 Client-VECK (MC-VECK) scheme for a function 𝐹 augments a VECK
Data size (#BLS12-381 field element) scheme from Definition 3.1 with an additional preprocessing algorithm
that outputs a secret and a public state for the server that is used
Figure 6: Prover and verifier times in the VECK schemes in the encryption. Namely, MC-VECK is a tuple of algorithms Π =
described in Figure 2 and Figure 4. Interestingly, in the expo- (Gen, Prep, Enc, Verct, Verkey, Dec) defined for a class of functions
nential ElGamal VECK scheme, the prover time is dominated F = {𝐹 : W → V} and a commitment scheme (Setup, Commit)
by the FFT computations. Hence, if smaller sets 𝑆 ⊂ [1, 𝑛] are over the space W. The only algorithms whose input-output formats
opened, then we observe larger prover time due to the larger are different are Prep and Enc defined as follows:
degree of the quotient polynomial 𝑞(𝑋 ), cf. Step 5 in Figure 2. • Prep(pp, 𝐶 𝑤 , 𝑤) →− (aux, msk): Probabilistic polynomial-
time algorithm that outputs a public value aux and a server’s
master secret key msk (pp will be omitted from the algorithms
from the validators. We next formulate a model for this setting and for brevity).
construct a VECK protocol that minimizes the server’s work. • Enc(pp, 𝐹, aux, msk) → − (vk, sk, ct, 𝜋) : Probabilistic polynomial-
time algorithm run by the server, it takes as input the value
7.1 Problem Setup aux and a master secret key msk, and outputs a verification
Consider a single server S with the messages (𝑚𝑖 )𝑖 ∈ [𝑛] from some
message space M, and multiple clients (C𝑖 )𝑖=1,...,𝐾 that query S 9 Otherwise, the scheme violates the succinctness assumption.
13
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

key vk, a secret key sk, an encryption ct of 𝐹 (𝑤) and a proof Construction 1: ElGamal MC-VECK for the function 𝐹 :=
𝜋. full-eval . It readily generalizes to subset openings since
𝐹 [𝑛]
An MC-VECK protocol Π = (Gen, Prep, Enc, Verct, Verkey, Dec) the protocol for subset openings use a VECK protocol
is correct and sound if the VECK Π ′ = (Gen, Enc′, Verct, Verkey, Dec) full-eval as blackbox.
for 𝐹 [𝑛]
where encryption is derived as follows is correct and sound.
Enc′ (pp, 𝐹, 𝐶 𝑤 , 𝑤) : Gen(crs) → pp : Output Setup(crs) → − pp as in Figure 2.
• Run Prep(pp, 𝐹, 𝐶 𝑤 , 𝑤) → (aux, msk). Prep(𝐹, 𝐶𝜙 , 𝜙) →
− (aux, msk) :
• Run Enc(pp, 𝐹, aux, msk) → (vk, sk, ct, 𝜋) (1) Run Enc(𝐹, 𝐶𝜙 , 𝜙) → − (vk, sk, ct, 𝜋) as in Fig-
• Output (vk′ = (vk, aux), sk, ct, 𝜋). ure 2.
We additionally require the MC-VECK scheme to satisfy computa- (2) Output aux = (vk, ct, 𝜋).
tional L-bits zero-knowledge. This property implies that one client, (3) Output msk = sk.
Alice, who successfully completed the data-exchange, won’t be able Enc(𝐹, aux, msk) →− (vk C , sk C , ct, 𝜋 C ) :
to help the other client, Bob, who only downloaded the encryption, (1) Parse aux, msk → − (vk, sk, ct, 𝜋).
learn anything about the encrypted data, other than the bits that Alice (2) Sample 𝛿 C ←𝑅 F𝑝 .
𝛿
sends Bob directly. With this property, it is guaranteed that in order (3) Set 𝐷 C = ℎ𝛿 C , ℎ C,𝑖 = (ℎ𝑖 C )𝑖 ∈ [𝑛] .
to obtain the data, Bob has to either complete the data-exchange with (4) Set 𝑒𝑖 = 𝐻 (𝐷 C , 𝑖) for all 𝑖 ∈ [𝑛].
Calculate 𝑄 = 𝑖 ∈ [𝑛] ℎ𝑖𝑒𝑖 .
Î
the server or download full data from Alice, as no partial help from (5)
Alice would help Bob avoid paying the server for the decryption key (6) Compute discrete logarithm equality 𝜋DLEq for
in our FDE protocol. (𝑄, 𝑄 𝛿 C , ℎ, 𝐷 C ) with the witness 𝛿 C [22].
Computational L-bits Zero-Knowledge: We generalize zero- (7) Set
knowledge in order to prevent the attacker who learns some L-bits • vk C = vk · 𝐷 C .
from other clients from learning anything else about the data. For any • sk C = sk + 𝛿 C .
PPT algorithms A1, A2 , where A1 outputs at most L-bits hint, there • 𝜋 C = (𝜋, 𝐷 C , 𝜋DLEq, (ℎ C,𝑖 )𝑖 ∈ [𝑛] ).
exists a PPT simulator Sim, there is a negligible function 𝜇 (·) such (8) Output (vk C , sk C , ct, 𝜋 C ).
that for all 𝑤 ∈ W, the following probability is less than 12 + 𝜇 (𝜆): Verct (𝐹, 𝐶𝜙 , vk C , ct, 𝜋 C ) →
− 0/1 :
(1) Parse 𝜋 C → − (𝜋, 𝐷 C , 𝜋DLEq, (ℎ C,𝑖 )𝑖 ∈ [𝑛] ).
(2) Verify if Verct (𝐹, 𝐶𝜙 , vk C /𝐷 C , ct, 𝜋) → − 1 as
 crs ← Setup(1𝜆 ) 
  in Figure 2.
 𝐶 𝑤 ← Commit(crs, 𝑤) 
  (3) Set 𝑒𝑖 = 𝐻 (𝐷 C , 𝑖) for all 𝑖 ∈ [𝑛].
 𝑝𝑝 ← Gen(crs) 
  (4) Compute 𝑄 as above.
 (aux, msk) ← Prep(𝐹, 𝐶 𝑤 , 𝑤) 
(5) Compute 𝑄 ∗ = 𝑖 ∈ [𝑛] ℎ𝑒C,𝑖
Î 𝑖



 .
 A (pp, 𝐹, 𝐶 𝑤 , hint
(6) Verify 𝜋DLEq for the relation (𝑄, 𝑄 ∗, ℎ, 𝐷 C ).

Pr  2 (vk∗, sk∗, ct∗, 𝜋∗ ) ← Enc(𝐹, aux, msk) 
 vk𝑏 , ct𝑏 , 𝜋𝑏 ) = 𝑏 hint ← A1 (vk∗, sk∗, ct∗, 𝜋∗ )  (7) Return 1 if the steps above succeed, 0 o.w.
Verkey (vk C , sk C ) →− 0/1 : Return 1 if vk C = ℎ skC , 0 o.w.
 
 
Dec(𝐹, sk C , (ct, (ℎ C,𝑖 )𝑖 ∈ [𝑛] )) →
− 𝜙 (𝑖) :
 

 (vk0, sk0, ct0, 𝜋0 ) ← Enc(𝐹, aux, msk) 
 (vk1, ct1, 𝜋1 ) ← Sim(pp, 𝐶 𝑤 , hint)  (1) Parse ct → − (ct𝑖 )𝑖 ∈ [𝑛] .
 
 𝑏 ←𝑅 {0, 1}  (2) Set ct C = (ct𝑖 · ℎ C,𝑖 )𝑖 ∈ [𝑛] .
 
(3) Output Dec(𝐹, sk C , ct C ) as in Figure 2.
7.3 MC-VECK for ElGamal Encryption
We next describe an MC-VECK protocol for exponential ElGamal Figure 7: The MC-VECK protocol for ElGamal encryption.
encryption that extends the VECK scheme in Section 5.1 (Figure 2). The parameters with subscript C are generated per client C.
The protocol consists of an offline phase and an online phase (Fig-
ure 7). Recall that (ℎ𝑖 )𝑖 ∈ [𝑛] ∈ G𝑛+1
1 denote the public parameters
of the ElGamal encryption.
Preprocessing Step. In the preprocessing step, S runs the Enc It then calculates 𝑄 = ℎ𝑖𝑒𝑖 , where 𝑒𝑖 = 𝐻 (𝐷 C , 𝑖) for all 𝑖 ∈ [𝑛], and
algorithm of the original VECK scheme (cf. Definition 7.1) and computes a single discrete logarithm equality proof 𝜋 DLEQ with
outputs the verification key vk, the ciphertexts ct and the VECK respect to (𝑄, 𝑄 𝛿 C , ℎ, 𝐷 C ). Informally, the values {ℎ C,𝑖 } will be used
proof 𝜋 for the function 𝐹 as part of the preprocessing output aux to rerandomized the ElGamal encryption so that the corresponding
and outputs the decryption key sk as the master secret key msk decryption key becomes sk C = msk + 𝛿 C . The proof 𝜋 DLEQ , on the
(cf. Figure 2 and Figure 7). Let 𝐻 : {0, 1}∗ → F𝑝 be a hash function other hand, will attest to the correct rerandomization. The final
modelled as a random oracle. proof 𝜋 C includes 𝜋, 𝐷 C , 𝜋DLEq and (ℎ C,𝑖 )𝑖 ∈ [𝑛] .
Upon receiving vk C , ct and 𝜋 C = (𝜋, 𝐷 C , 𝜋DLEq, (ℎ C,𝑖 )𝑖 ∈ [𝑛] ),
Online Step of MC-VECK. When S starts interacting with a
the client C first verifies the VECK proof 𝜋 with respect to 𝐶𝜙 ,
new client C, it samples a new key 𝛿 C u.a.r., and calculates the
vk C /𝐷 C and ct. It then finds (𝑒𝑖 )𝑖 ∈ [𝑛] and 𝑄 as described above
commitments
and checks the proof 𝜋DLEQ against (𝑄, 𝑖 ∈ [𝑛] ℎ𝑒C,𝑖
Î 𝑖
, ℎ, 𝐷 C ). If the
𝛿
𝐷 C = ℎ𝛿 C and ℎ C,𝑖 = (ℎ𝑖 C )𝑖 ∈ [𝑛] . steps succeed in C’s view, it accepts the proof 𝜋 C .
14
Atomic and Fair Data Exchange via Blockchain

Once the decryption key sk C is published, its correctness is 8 DISCUSSION AND FUTURE DIRECTIONS
verified by checking if ℎ skC = vk C . We leave the following open problems, extensions, and possible
Finally, to decrypt ct, C calculates ct C = (ct𝑖 · ℎ C,𝑖 )𝑖 ∈ [𝑛] as improvements for future work.
the rerandomized ciphertexts in the target group, and outputs
Dec(sk C , ct C ) as in Figure 2 by running the decryption algorithm Optimizations. If a client requests multiple batches of data under
in the target group. different commitments, the server can reuse the same decryption
key for the ciphertexts, reducing the on-chain footprint of the pro-
Discussion. The MC-VECK protocol enables the prover to reuse the tocol. In the multi-client model, the server currently generates and
original ciphertexts and the VECK proof 𝜋 across all clients (e.g., the remembers a different decryption key to interact with each client.
proofs 𝜋𝛼 , 𝜋 LIN , 𝜋 DLeq and most importantly the range proofs). As As an optimization, the server could instead use a PRF function
generating the ciphertexts and the range proofs constitute the bulk 𝑓𝑘 (·), and compute the 𝑖-th client’s decryption key as sk𝑖 := 𝑓𝑘 (𝑖);
of the proving time, this saves the prover considerable computation the server would then only store an index for each client.
(cf. Section 6).
Optimizing bandwidth. Both our protocols concretely incur
To minimize the client’s verification work and the server’s com-
at least a 10×-factor of bandwidth blowup (i.e. ciphertexts and
munication complexity, the server S could also post 𝐶𝜙 , the veri-
proofs) in comparison to just sending the plaintext data, cf. Sec-
fication key vk, ciphertexts ct and proof 𝜋 to a smart contract on
tion 6. Thus, it is an interesting open problem to design a VECK
the blockchain after the preprocessing step. The contract then runs
proof system with smaller overhead and for the KZG commitment
Verct (𝐶𝜙 , vk, ct, 𝜋), thus removing the need for the clients to later
and Paillier encryption schemes, with constant proof size. One
individually verify the proof 𝜋. Moreover, in any future interaction
approach for smaller overhead would be “packing” multiple data
with a client C, S would no longer have to send ct and 𝜋 to C;
points {𝜙 (𝑖)}𝑘𝑖=1 ∈ F𝑘𝑝 into a single Paillier ciphertext 𝑐 ∈ Z∗𝑁 2 .
since 𝜋 would already be verified by the contract, and C would be
able to retrieve ct and 𝜋 from the blockchain. This would improve Distributed data-storage. In Danksharding [15] the blockchain
applications where the total cost of server’s communication and data is erasure coded using Reed-Solomon codes [60] and stored on
the clients’ verification dominates the cost of verifying the data multiple different servers. Hence, when a client wishes to pay for
once on the blockchain. certain data, it needs to fetch the data and the accompanying proofs
Finally, the MC-VECK protocol above can be readily modified to from multiple servers. Our FDE protocol with subset openings
support subset openings of KZG commitments as the protocol in readily generalizes to this setting; so that the client can engage
Section 5.3 makes use of a VECK protocol for the function 𝐹 full-eval with multiple servers independently to reconstruct the original data
as blackbox. after fairly obtaining all the fragments required for reconstruction.
We provide technical details on Danksharding in Appendix A.3.
Analysis. Security of MC-VECK protocols is stated below.
An intermediate step towards Danksharding is EIP-4844 [15],
which provides the functionality of persisting data on-chain for a
Theorem 7.1. Given 𝐻 modelled as a random oracle, the protocol
predetermined period of 1-2 months. After the data expires, the
in Figure 7 is a secure MC-VECK protocol in the random oracle and
validators are no longer obliged to store it, although they keep the
algebraic group models.
KZG commitments to the data. Our protocol can be used to pay
archival nodes for accessing the expired data in a fair and trust-
Proof is given in Appendix C.5. Intuitively, correctness and
minimized way, thus bringing in financial incentives to ensure that
soundness follow from the same properties of the VECK proto-
the data continues to be available.
cols used in the preprocessing step.
One important property inherited from the zero-knowledge of Server griefing. In our current design, a malicious client could
VECK protocols is that given any two values 𝑤 0 ≠ 𝑤 1 committed grief the server by having it produce the ciphertext (and the correct-
by the same 𝐶 𝑤 , no PPT adversary would be able to distinguish ness proofs) but never requesting the decryption key. While this can
their encryptions. Although many such values exist, certainly no be mitigated in a similar way to standard denial-of-service attacks,
PPT algorithm can break binding and actually find them (assuming a promising alternative approach is to split the client’s payment
that the crs was generated securely), so we talk about them as into two parts as follows: a first small payment is provided with
barely hypothetical values. Then, even if the adversary knows the the request, essentially to reimburse the server for its computation
value 𝑤 0 , it would not be able to distinguish the encryption of cost; the second payment is provided as before—as an exchange for
𝐹 (𝑤 0 ) from the encryption of 𝐹 (𝑤 1 ) until the decryption keys the VECK decryption key. While this can allow the server to sim-
are revealed. Since this is true for the adversary that might know ply pocket the first payment, assuming that a competitive market
𝑤 0 , it is also true for the adversary that holds partial information exists for providing the data, users will simply choose a different
about 𝐹 (𝑤 0 ) or 𝑤 0 itself, e.g., a hint based on 𝑤 0 . Then, assuming server, and the servers will not risk their reputation to steal the first
multiple (possibly colluding) clients downloading the same data, if payment, which would typically be small compared to the price
one client, who already holds 𝐹 (𝑤), tries to help the other client, of the content. Moreover, faced with a grieving attack, the server
who only downloaded the encryption of 𝐹 (𝑤) from the server can reuse the same ciphertext, the proof and the decryption key in
without yet obtaining the decryption key, it won’t be able to do its interaction with different clients willing to buy the same data,
so, since the communicated hint reveals no additional information thus mitigating the attack in a practical sense (despite saving on
about 𝐹 (𝑤). This would imply 𝐿-bits zero-knowledge for the MC- compute, the server would not save on bandwidth as it would still
VECK protocols. have to send the encryptions).
15
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

Market pricing. We envision a marketplace for committed data [13] Kevin D. Bowers, Ari Juels, and Alina Oprea. 2009. Proofs of retrievability: theory
with multiple servers and clients, where servers compete to fulfill and implementation. In CCSW. ACM, 43–54.
[14] Vitalik Buterin. 2017. Sharding FAQ. https://vitalik.eth.limo/general/2017/12/31/
clients’ requests for data. In our proof of concept implementations, sharding_faq.html
the server S sets explicitly the agreed price for the data exchange. [15] Vitalik Buterin, DL Dankrad Feist, G Kadianakis, M Garnett, and A Dietrichs.
2022. Eip-4844: Shard blob transactions. EIPS/eip-4844 (2022).
We envision that real-world deployments of our protocols will [16] Jan Camenisch and Victor Shoup. 2003. Practical Verifiable Encryption and
employ other (automated) market-making mechanisms, e.g., the Decryption of Discrete Logarithms. In CRYPTO (Lecture Notes in Computer Science,
constant product formula of Uniswap [2], to establish automati- Vol. 2729). Springer, 126–144.
[17] Matteo Campanelli, Dario Fiore, and Anaïs Querol. 2019. LegoSNARK: Modular
cally and trustlessly the price of the subsequent fair data exchange. Design and Composition of Succinct Zero-Knowledge Proofs. In CCS. ACM,
Specifically, the pricing function is 𝑓 (𝑥, 𝑦) = 𝑥 · 𝑦 = const, where 𝑥 2075–2092.
is the amount of data waiting to be exchanged in the FDE protocol, [18] Matteo Campanelli, Rosario Gennaro, Steven Goldfeder, and Luca Nizzardo. 2017.
Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for
while 𝑦 is the number of clients wishing to download committed Services. In CCS. ACM, 229–243.
data. Future FDE applications could also apply more sophisticated [19] Statistics Canada. 2019. Study: The value of data in Canada: Experimental esti-
mates. https://www150.statcan.gc.ca/n1/en/daily-quotidien/190710/dq190710a-
market-making mechanisms. eng.pdf.
Other commitment and encryption schemes. We believe that [20] Dario Catalano and Dario Fiore. 2013. Vector Commitments and Their Applica-
tions. In Public Key Cryptography (Lecture Notes in Computer Science, Vol. 7778).
we only scratched the surface of FDE protocols’ design space. In Springer, 55–72.
particular, we leave it to future work to explore other combinations [21] Panagiotis Chatzigiannis, Konstantinos Chalkias, and Valeria Nikolaenko. 2021.
of encryption (or functional encryption) and commitment schemes, Homomorphic Decryption in Blockchains via Compressed Discrete-Log Lookup
Tables. In DPM/CBT@ESORICS (Lecture Notes in Computer Science, Vol. 13140).
such as a recent FRI-based commitment schemes for distributed data Springer, 328–339.
storage [43]. The design principles behind VECK schemes and FDE [22] David Chaum and Torben P. Pedersen. 1992. Wallet Databases with Observers.
In CRYPTO (Lecture Notes in Computer Science, Vol. 740). Springer, 89–105.
protocols can also be generalized to functions beyond data exchange [23] Jeremy Clark and Aleksander Essex. 2012. CommitCoin: Carbon Dating Com-
such as exchanging the result of a generic computation; however, mitments with Bitcoin - (Short Paper). In Financial Cryptography (Lecture Notes
the applications explored in this paper focus on functions with in Computer Science, Vol. 7397). Springer, 390–398.
[24] Bram Cohen. 2003. Incentives build robustness in BitTorrent. In Workshop on
non-succinct outputs, enabling the use of more communication- Economics of Peer-to-Peer systems.
permissive techniques. [25] Henri Cohen. 2013. A course in computational algebraic number theory. Vol. 138.
Springer Science & Business Media.
[26] Edouard Cuvelier, Olivier Pereira, and Thomas Peters. 2013. Election Verifiability
9 ACKNOWLEDGMENTS or Ballot Privacy: Do We Need to Choose?. In ESORICS (Lecture Notes in Computer
We thank Dan Boneh for suggesting us to look at the multi-client Science, Vol. 8134). Springer, 481–498.
[27] Wei Dai, Tatsuaki Okamoto, and Go Yamamoto. 2022. Stronger Security and
setting for FDE and for helping us start working on that direction. Generic Constructions for Adaptor Signatures. In INDOCRYPT (Lecture Notes in
We also thank Robin Linus for his help with the Bitcoin script. Computer Science, Vol. 13774). Springer, 52–77.
[28] Ivan Bjerre Damgård. 1989. A design principle for hash functions. In Conference
Ertem Nusret Tas was partially supported by the Stanford Center on the Theory and Application of Cryptology. Springer, 416–427.
for Blockchain Research. [29] Danksharding 2024. Danksharding. https://ethereum.org/roadmap/danksharding
[30] Stefan Dziembowski, Lisa Eckey, and Sebastian Faust. 2018. FairSwap: How To
Fairly Exchange Digital Goods. In CCS. ACM, 967–984.
REFERENCES [31] Lisa Eckey, Sebastian Faust, and Benjamin Schlosser. 2020. OptiSwap: Fast
[1] Aydin Abadi, Steven J. Murdoch, and Thomas Zacharias. 2023. Recurring Con- Optimistic Fair Exchange. In AsiaCCS. ACM, 543–557.
tingent Service Payment. In EuroS&P. IEEE, 724–756. [32] Dankrad Feist and Dmitry Khovratovich. 2023. Fast amortized KZG proofs. IACR
[2] Guillermo Angeris, Hsien-Tang Kao, Rei Chiang, Charlie Noyes, and Tarun Chitra. Cryptol. ePrint Arch. (2023), 33.
2021. An analysis of Uniswap markets. Cryptoeconomic Systems Journal (2021). [33] Amos Fiat and Adi Shamir. 1986. How to Prove Yourself: Practical Solutions to
[3] Nadarajah Asokan, Victor Shoup, and Michael Waidner. 2000. Optimistic fair Identification and Signature Problems. In CRYPTO (Lecture Notes in Computer
exchange of digital signatures. IEEE Journal on Selected Areas in communications Science, Vol. 263). Springer, 186–194.
18, 4 (2000), 593–610. [34] Filecoin 2024. Filecoin. https://filecoin.io/
[4] N. Asokan, Victor Shoup, and Michael Waidner. 2000. Optimistic fair exchange [35] Ben Fisch. 2019. Tight Proofs of Space and Replication. In EUROCRYPT (2)
of digital signatures. IEEE J. Sel. Areas Commun. 18, 4 (2000), 593–610. (Lecture Notes in Computer Science, Vol. 11477). Springer, 324–348.
[5] Lakshmi N. Bairavasundaram, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci- [36] Ben Fisch, Joseph Bonneau, Nicola Greco, and Juan Benet. 2018. Scaling proof-of-
Dusseau, Garth R. Goodson, and Bianca Schroeder. 2008. An analysis of data replication for Filecoin mining. Technical Report. Protocol Labs.
corruption in the storage stack. ACM Trans. Storage 4, 3 (2008), 8:1–8:28. [37] Pierre-Alain Fouque and Jacques Stern. 2001. One Round Threshold Discrete-Log
[6] Waclaw Banasik, Stefan Dziembowski, and Daniel Malinowski. 2016. Efficient Key Generation without Private Channels. In Public Key Cryptography (Lecture
Zero-Knowledge Contingent Payments in Cryptocurrencies Without Scripts. In Notes in Computer Science, Vol. 1992). Springer, 300–316.
ESORICS (2) (Lecture Notes in Computer Science, Vol. 9879). Springer, 261–280. [38] Georg Fuchsbauer. 2019. WI Is Not Enough: Zero-Knowledge Contingent (Ser-
[7] Eli Ben-Sasson, Alessandro Chiesa, Matthew Green, Eran Tromer, and Madars vice) Payments Revisited. In CCS. ACM, 49–62.
Virza. 2015. Secure Sampling of Public Parameters for Succinct Zero Knowledge [39] Georg Fuchsbauer, Eike Kiltz, and Julian Loss. 2018. The Algebraic Group Model
Proofs. In IEEE Symposium on Security and Privacy. IEEE Computer Society, and its Applications. In CRYPTO (2) (Lecture Notes in Computer Science, Vol. 10992).
287–304. Springer, 33–62.
[8] Daniel J. Bernstein, Mike Hamburg, Anna Krasnova, and Tanja Lange. 2013. [40] Ariel Gabizon, Zachary J. Williamson, and Oana Ciobotaru. 2019. PLONK:
Elligator: elliptic-curve points indistinguishable from uniform random strings. Permutations over Lagrange-bases for Oecumenical Noninteractive arguments
In CCS. ACM, 967–980. of Knowledge. IACR Cryptol. ePrint Arch. (2019), 953.
[9] Bitcoin Fee Calculator 2024. Bitcoin Fee Calculator. https://bitcoinjobs.com/fee- [41] Jens Groth. 2016. On the Size of Pairing-Based Non-interactive Arguments. In
calculator EUROCRYPT (2) (Lecture Notes in Computer Science, Vol. 9666). Springer, 305–326.
[10] Dan Boneh, Justin Drake, Ben Fisch, and Ariel Gabizon. 2020. Efficient polynomial [42] Mathias Hall-Andersen, Mark Simkin, and Benedikt Wagner. 2023. Foundations
commitment schemes for multiple points and polynomials. IACR Cryptol. ePrint of Data Availability Sampling. IACR Cryptol. ePrint Arch. (2023), 1079.
Arch. (2020), 81. [43] Mathias Hall-Andersen, Mark Simkin, and Benedikt Wagner. 2024. FRIDA: Data
[11] Dan Boneh and Victor Shoup. 2023. A graduate course in applied cryptography. Availability Sampling from FRI. Cryptology ePrint Archive (2024).
Draft 0.6 (2023). [44] Songlin He, Yuan Lu, Qiang Tang, Guiling Wang, and Chase Qishi Wu. 2021. Fair
[12] Sean Bowe, Ariel Gabizon, and Ian Miers. 2017. Scalable Multi-party Computation Peer-to-Peer Content Delivery via Blockchain. In ESORICS (1) (Lecture Notes in
for zk-SNARK Parameters in the Random Beacon Model. IACR Cryptol. ePrint Computer Science, Vol. 12972). Springer, 348–369.
Arch. (2017), 1050.
16
Atomic and Fair Data Exchange via Blockchain

[45] Economist Impact. 2022. The future of Europe’s data economy. following holds for the group G output by 𝐺𝐺𝑒𝑛(·):
https://impact.economist.com/perspectives/sites/default/files/ei233_msft_
futuredata_report_-_v7.pdf. | Pr[A (𝑔, 𝑔𝑎 , 𝑔𝑏 , 𝑔𝑎𝑏 ) = 1] − Pr[A (𝑔, 𝑔𝑎 , 𝑔𝑏 , 𝑔𝑟 ) = 1]| ≤ negl(𝜆).
[46] Simon Janin, Kaihua Qin, Akaki Mamageishvili, and Arthur Gervais. 2020. File-
Bounty: Fair Data Exchange. In EuroS&P Workshops. IEEE, 357–366. (A.1)
[47] Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg. 2010. Constant-Size The probability is over the random choice of 𝑔, G according to the
Commitments to Polynomials and Their Applications. In ASIACRYPT (Lecture distribution induced by 𝐺𝐺𝑒𝑛(·), the random choice of 𝑎, 𝑏, 𝑟 ∈ F𝑝 ,
Notes in Computer Science, Vol. 6477). Springer, 177–194.
[48] Jiwon Lee, Jaekyoung Choi, Jihye Kim, and Hyunok Oh. 2019. SAVER: Snark- and the random bits used by A. The group family G satisfies the DDH
friendly, Additively-homomorphic, and Verifiable Encryption and decryption assumption if there is no DDH algorithm for G.
with Rerandomization. IACR Cryptol. ePrint Arch. (2019), 1270. Financial Crypto
2024. A.1.2 The DCR assumption.
[49] Robin Linus. 2023. BitStream: Decentralized File Hosting Incentivised via Bitcoin
Payments. https://robinlinus.com/bitstream.pdf
[50] Markets and Markets. 2023. Cloud Storage Market. https://www.
Definition A.2. Given the security parameter 𝜆, the set 𝑆 (𝑝)
marketsandmarkets.com/Market-Reports/cloud-storage-market-902.html. of 𝑝 bit primes such that 𝑝 = 2𝑝 ′ + 1 for some prime 𝑝 ′ and some
[51] Gregory Maxwell. 2011. Zero Knowledge Contingent Payment. https://en.bitcoin. 𝜒 = poly(𝑝), the decisional composite residuosity (DCR) assump-
it/wiki/Zero_Knowledge_Contingent_Payment.
[52] Satoshi Nakamoto. 2008. Bitcoin: A peer-to-peer electronic cash system. Decen- tion states that the tuples (𝑁 , 𝑢) and (𝑁 , 𝑣) are computationally indis-
tralized business review (2008). tinguishable for 𝑁 = 𝑝 ′𝑞 ′ , where 𝑝 ′, 𝑞 ′ ←𝑅 𝑆 (𝑝), 𝑢 ←𝑅 QR𝑁 𝜒 +1 =
{𝑎 2 |𝑎 ∈ Z∗𝑁 𝜒 +1 } and 𝑣 ←𝑅 HC𝑁 𝜒 +1 = {𝑎 2𝑁 |𝑎 ∈ Z∗𝑁 𝜒 +1 }. Here,
[53] Valeria Nikolaenko, Sam Ragsdale, Joseph Bonneau, and Dan Boneh. 2024. 𝜒
Powers-of-Tau to the People: Decentralizing Setup Ceremonies. 14585 (2024),
105–134. QR𝑁 𝜒 +1 denotes the subgroup of quadratic residues and HC𝑁 𝜒 +1 de-
[54] Henning Pagnia and Felix C Gärtner. 1999. On the impossibility of fair exchange notes the subgroup of 𝑁 𝜒 -th residues modulo 𝑁 𝜒+1 .
without a trusted third party. Technical Report. Citeseer.
[55] Pascal Paillier. 1999. Public-key cryptosystems based on composite degree
residuosity classes. In International conference on the theory and applications of
A.1.3 The algebraic group model (AGM).
cryptographic techniques. Springer, 223–238.
[56] The European Parliament and the Council of the European Union. 2024. Data We prove the security of our schemes in the algebraic group
Act. https://digital-strategy.ec.europa.eu/en/policies/data-act.
[57] Olivier Pereira. 2014. Verifiable Elections with Commitment Consistent Encryp- model introduced by Fuchsbauer, Kiltz, and Loss [39]. The algebraic
tion - A Primer. CoRR abs/1412.7358 (2014). group model is an abstraction of an adversary that can only use
[58] John M Pollard. 1978. Monte Carlo methods for index computation. Mathematics algebraic algorithms in its attacks.
of computation 32, 143 (1978), 918–924.
[59] Guillaume Poupard and Jacques Stern. 2000. Fair Encryption of RSA Keys. In
EUROCRYPT (Lecture Notes in Computer Science, Vol. 1807). Springer, 172–189. Definition A.3 (Algebraic algorithm [39]). An algorithm A
[60] Irving S Reed and Gustave Solomon. 1960. Polynomial codes over certain finite is algebraic if ∀𝑧 ∈ G that is output by A (either as returned by A or
fields. Journal of the society for industrial and applied mathematics 8, 2 (1960), by invoking an oracle), A also provides the representation of 𝑧 with
300–304.
[61] David Reinsel-John Gantz-John Rydning, John Reinsel, and John Gantz. 2018. respect to previously received group elements from G. More formally,
The digitization of the world from edge to core. Framingham: International Data if elems ∈ G𝑛 a vector of previously received group elements, then A
Corporation 16 (2018), 1–28.
[62] Claus-Peter Schnorr. 1991. Efficient signature generation by smart cards. Journal
must be able to provide a vector r representing z in the group, i.e., it
of cryptology 4 (1991), 161–174. holds that 𝑧 = ⟨elems, r⟩.
[63] Scroll 2024. Scroll. https://scroll.io/
[64] Daniel Shanks. 1971. Class number, a theory of factorization, and genera. In Proc.
Symp. Math. Soc., 1971, Vol. 20. 415–440. A.2 Applied Sigma-protocols and proof systems
[65] Ludwig Siegele. 2020. A deluge of data is giving rise to a new economy. The In this section we state all the Σ-protocols used in our construc-
Economist 5 (2020), 2–7.
[66] Markus Stadler. 1996. Publicly Verifiable Secret Sharing. In EUROCRYPT (Lecture tions. We remind that a Sigma protocol for a relation R ⊆ X × W
Notes in Computer Science, Vol. 1070). Springer, 190–199. (X are the statements and W are the witnesses) is a three-move
[67] Starkware 2024. Starkware. https://starkware.co/
[68] Elias Strehle and Fred Steinmetz. 2020. Dominating OP Returns: The Impact of
protocol, where the prover 𝑃 holds (𝑥, 𝑤) and starts the protocol,
Omni and Veriblock on Bitcoin. J. Grid Comput. 18, 4 (2020), 575–592. the verifier 𝑉 holds 𝑥 and responds with a random message from
[69] Ertem Nusret Tas and Dan Boneh. 2023. Cryptoeconomic Security for Data the challenge space 𝑐 ←𝑅 C, and after 𝑃’s response, 𝑉 accepts or
Availability Committees. In FC (Lecture Notes in Computer Science, Vol. 13951).
Springer, 310–326. rejects. Although we describe interactive variants, in our protocols,
[70] Gavin Wood et al. 2014. Ethereum: A secure decentralised generalised transaction we use their non-interactive counterparts that can be obtained via a
ledger. Ethereum project yellow paper 151, 2014 (2014), 1–32. standard Fiat-Shamir transformation, where the verifier’s challenge
[71] zkSync 2024. zkSync. https://zksync.io/
is replaced with a hash of the prover’s first message.

A EXTENDED PRELIMINARIES We first introduce a protocol of Schnorr [62] as an identification

A.1 Cryptographic assumptions and models scheme to prove the knowledge of a discrete logarithm in a prime-
For the sake of completeness, we enclose the definitions of the order group where the discrete logarithm problem is hard. More
applied cryptographic assumptions. formally, Schnorr is a protocol with special soundness and special
HVZK for the following relation in a group G (|G| = 𝑝) with group
A.1.1 The DDH assumption. generator 𝑔 ←𝑅 G.
Definition A.1. The Decisional Diffie-Hellman (DDH) assump-
tion holds for the group generator 𝐺𝐺𝑒𝑛(·) that outputs groups of R DL := {(ℎ, 𝑥)|ℎ = 𝑔𝑥 }. (A.2)
order 𝑝 if there is no efficient adversary A that can distinguish The proof system proceeds as follows.
the ensembles (𝑔, 𝑔𝑎 , 𝑔𝑏 , 𝑔𝑎𝑏 ) and (𝑔, 𝑔𝑎 , 𝑔𝑏 , 𝑔𝑟 ), for group genera- • The prover samples 𝑟 ←𝑅 F𝑝 , and sends 𝑅 := 𝑔𝑟 ∈ G to the
tor 𝑔 ←𝑅 G, and 𝑎, 𝑏, 𝑟 ←𝑅 F𝑝 . More formally, we require that the verifier.
17
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

• The verifier samples a random challenge 𝑐 ←𝑅 F𝑝 , and (i) for all inputs (𝑥, 𝑐) ∈ X × C, algorithm Sim always outputs
sends it to the prover. a pair (𝑡, 𝑧) such that (𝑡, 𝑐, 𝑧) is an accepting conversation for
• The prover replies with 𝑧 = 𝑐𝑥 + 𝑟 ∈ F𝑝 . 𝑥;
The proof 𝜋 DL consists of 𝜋DL = (𝑅, 𝑧). The verifier accepts the (ii) for all (𝑥, 𝑤) ∈ R, if we compute
proof if 𝑅ℎ𝑐 = 𝑔𝑧 holds. It can be shown that this proof system
𝑐 ←𝑅 C, (𝑡, 𝑧) ← Sim(𝑥, 𝑐),
satisfies correctness, (knowledge) soundness, and zero-knowledge.
Naturally, this proof system can be made non-interactive using the then (𝑡, 𝑐, 𝑧) has the same distribution as that of a transcript
Fiat-Shamir transformation [33]. of a conversation between 𝑃 (𝑥, 𝑤) and 𝑉 (𝑥).
The word "special" in the definition means that (i) the simulator
The following protocol is used to prove that two group elements may simulate around a given challenge 𝑐, and (ii) the simulator
have the same discrete logarithm with respect to different bases produces an accepting conversation even when the statement 𝑥
𝑔 and ℎ [22]. We use the following protocol that satisfies special does not have a witness.
soundness and special HVZK: In Figure 3, we created a VECK protocol with the exponential
ElGamal and the KZG commitment scheme that could support ar-
R DLeq := {((𝑔, ℎ, 𝑎, 𝑏), 𝑥)|𝑎 = 𝑔𝑥 ∧ 𝑏 = ℎ𝑥 }. (A.3) bitrary, i.e., high-entropy data, by using range proofs. Next, we for-
mulate the range-proof relation, necessary to support high-entropy
The proof system proceeds as follows. The prover holds 𝑃 (𝑔, ℎ, 𝑎, 𝑏, 𝑥)
data.
and the verifier holds 𝑉 (𝑔, ℎ, 𝑎, 𝑏).
• The prover samples 𝑟 ←𝑅 F𝑝 , and sends the group elements R range := {(𝑔1, ℎ, {ℎ𝑖 }, {ct𝑖,𝑗 }, ℎ𝑠 ); ({𝜙𝑖,𝑗 }, 𝑠)) |
(A.5)
(𝑅, 𝑅 ′ ) := (𝑔𝑟 , ℎ𝑟 ) ∈ G2 to the verifier. 𝜙
∀𝑖 ∈ [ℓ], 𝑗 ∈ [𝑘] : ct𝑖,𝑗 = ℎ𝑠𝑖 𝑔1 𝑖,𝑗 ∧ 0 ≤ 𝜙𝑖,𝑗 < B},
• The verifier samples a random challenge 𝑐 ←𝑅 F𝑝 , and
sends it to the prover. where B ∈ F𝑝 is a predefined bound. An HVZK instantiation
• The prover replies with 𝑧 = 𝑐𝑥 + 𝑟 ∈ F𝑝 . of this proof system can be found in [10] that we apply in our
The proof 𝜋 DLeq consists of (𝑅, 𝑅 ′, 𝑧) ∈ G2 ×F𝑝 . The verifier accepts implementation, cf. Section 6.
the proof if 𝑔𝑧 = 𝑅𝑎𝑐 ∧ ℎ𝑧 = 𝑅 ′𝑏𝑐 holds.
A.3 Danksharding
We also use a generalization of the protocol above for proving Danksharding is a scaling solution for the data posted to Ethereum.
linear relations [11] (Section 19.5.3) with special soundness and It enables each Ethereum block to have a capacity of up to 256
special HVZK: data blobs, each blob consisting of a vector of 4096 elements in
Î𝑛 𝑥 𝑗 F𝑝 . The data availability sampling (DAS) method employed by
𝑗=1 𝑔1,𝑗 = 𝑢 1 ∧  danksharding sets each row of 16 field elements as a single sample.

 



 

R LIN := ({𝑔𝑖,𝑗 , 𝑢𝑖 }𝑖 ∈ [𝑚] 𝑗 ∈ [𝑛] ; {𝑥 𝑗 } 𝑗 ∈ [𝑛] ) . . . This data is organized into a 256 × 4096 data matrix 𝐵.
𝑥
Danksharding uses a technique called data availability sampling
Î
∧ 𝑛𝑗=1 𝑔𝑚,𝑗 = 𝑢𝑚 
𝑗

 


(DAS) [42], where no Ethereum validator downloads all of a pro-
 
(A.4)
• The prover samples 𝛼 𝑗 ←𝑅 F𝑝 for 𝑗 ∈ [𝑛], sets 𝑣𝑖 := posed block but instead verifies its availability by sampling pieces of
Î𝑛 𝛼 𝑗 the data matrix. To ensure that the received samples can be verified
𝑗=1 𝑔𝑖 𝑗 for 𝑖 ∈ [𝑚] and sends the elements {𝑣𝑖 }𝑖 ∈ [𝑚] to
and the block can be recovered when a sufficient fraction of the
the verifier.
validators receive samples, DAS methods require encoding the data
• The verifier samples a random challenge 𝑐 ←𝑅 F𝑝 , and
with erasure-code and publishing commitments to the coded data.
sends it to the prover.
Towards this goal, the block builder fits a degree (𝑑𝑥 , 𝑑 𝑦 ) bivariate
• The prover computes 𝛽 𝑗 = 𝛼 𝑗 + 𝑥 𝑗 · 𝑐 for 𝑗 ∈ [𝑛] and sends
polynomial 𝑓 (𝑋, 𝑌 ) to the data matrix such that 𝑓 (𝑖, 𝑗) = 𝐵 [𝑖, 𝑗]
{𝛽 𝑗 } 𝑗 ∈ [𝑛] to the verifier.
for 𝑖 = 0, . . . , 255 and 𝑗 = 0, . . . , 4095 for 𝑑𝑥 < 256 and 𝑑 𝑦 < 4096. It
• The verifier checks that ∀𝑖 ∈ [𝑚], the following equations
Î 𝛽 then expands the matrix 𝐵 towards the bottom and right to form
hold: 𝑛𝑗=1 𝑔𝑖 𝑗𝑗 = 𝑣𝑖 · 𝑢𝑖𝑐 . an extended 512 × 8192 data matrix 𝐸 of field elements, where
𝐸 [𝑖, 𝑗] = 𝑓 (𝑖, 𝑗) for 𝑖 = 0, . . . , 511 and 𝑗 = 0, . . . , 8191. Finally,
Definition A.4 (Special soundness ([11], Definition 19.4)). .
it publishes KZG commitments 𝐶𝑖 to the univariate polynomials
Let (𝑃, 𝑉 ) be a Sigma protocol for R ⊆ X×W. We say that (𝑃, 𝑉 ) pro-
𝑓𝑖 (𝑌 ) = 𝑓 (𝑖, 𝑌 ), for all 𝑖 = 0, . . . , 255. These commitments are global
vides special soundness if there is an efficient deterministic algorithm
knowledge across all Ethereum clients.
Ext, called a witness extractor, with the following property: on input
Since 𝑑𝑥 < 256, for any given 𝑥 ≥ 256, there are constants
𝑥 ∈ X and two accepting conversations (𝑡, 𝑐, 𝑧) and (𝑡, 𝑐 ′, 𝑧 ′ ) with
𝜆0 (𝑥), . . . , 𝜆255 (𝑥) depending only on 𝑥 such that the KZG commit-
𝑐 ≠ 𝑐 ′ , algorithm Ext always outputs 𝑤 ∈ W such that (𝑥, 𝑤) ∈ R. Í255
ment to 𝑓𝑥 (𝑌 ), namely 𝐶𝑥 , can be computed as 𝐶𝑥 = 𝑖=0 𝜆𝑖 (𝑥)𝐶𝑖 .
Definition A.5 (Special Honest Verifier Zero Knowledge Hence, the block builder can publish 𝐶 = (𝐶 0, . . . , 𝐶 255 ) as the
(HVZK) ([11], Definition 19.5)). Let (𝑃, 𝑉 ) be a Sigma protocol for commitment to all of the extended data matrix 𝐸.
R ⊆ X × W with challenge space C. We say that (𝑃, 𝑉 ) is special The DAS method employed by danksharding sets each row of
honest verifier zero knowledge, or special HVZK, if there exists an 16 field elements as a single sample. Thus, the matrix 𝐸 consists
efficient probabilistic algorithm Sim that takes as input (𝑥, 𝑐) ∈ X×C, of 512 × 512 samples arranged as a square matrix. To distribute
and satisfies the following properties: the block data to the validators, the builder splits the matrix 𝐸
18
Atomic and Fair Data Exchange via Blockchain

into multiple groups (𝑃𝑖 )𝑖 , containing exactly two rows and two 𝑦 ← Extract(𝜎, 𝜎, ˆ 𝑌 ) : The extract algorithm is a deterministic
columns of samples from 𝐸. Each group is sent to a distinct validator, algorithm that takes an adapted signature 𝜎, a pre-signature 𝜎ˆ and
and upon receiving the assigned rows and columns, the validator the statement 𝑌 , and returns the witness 𝑦 such that (𝑌, 𝑦) ∈ R or ⊥.
acts as a data provider to the Ethereum clients.

An adaptor signature scheme must fulfill the following security

A.4 Paillier Encryption
and privacy requirements:
In this section, we review the additively homomorphic Paillier
public-key encryption scheme [55]. In our application, a distin-
guishing feature of the Paillier scheme is that it has a low ciphertext Definition A.7. (Security and Privacy for Adaptor Signatures) An
expansion, i.e., |ct| = 2|𝑚|, in contrast to the Exponential Elgamal adaptor signature scheme Ξ𝑅,Σ = (pSign, Adapt, pVerify, Extract)
encryption scheme, which for parameters of interest has |ct| ≈ 8|𝑚|. for a relation R and signature scheme Σ satisfies these properties:
Paillier’s public key encryption scheme [55] consists of the fol- • Pre-signature correctness: For ∀𝑚 ∈ {0, 1}∗, ∀(𝑌 , 𝑦) ∈ R;
lowing three efficient algorithms:
Gen(1ℓ ) : Generates two ℓ-bits safe primes 𝑝 ′ and 𝑞 ′ , and sets the
RSA modulus as 𝑁 = 𝑝 ′𝑞 ′ . Samples a uniformly random h
pVrfy(pk𝜎 ,𝑚,𝑌 ,𝜎ˆ )=1∧ (sk,pk𝜎 ) ←−Gen(1𝜆 ),𝜎ˆ ← −pSign(sk,𝑚,𝑌 ) = 1
i
Pr Vrfy(pk ,𝑚,𝜎 )=1∧(𝑌 ′ ) ∈𝑅 ′
𝑥 ←𝑅 Z𝑁 , and sets 𝐺 := (𝑁 + 1) · 𝑥 mod 𝑁 2 (𝐺 has order 𝜎 ,𝑦 ˆ
𝜎:=Adapt(pk𝜎 ,𝜎,𝑦),𝑦 ˆ )
:=Ext(pk𝜎 ,𝜎,𝜎,𝑌
𝑁 in Z∗𝑁 2 , i.e., 𝐺 𝑁 = 1 mod 𝑁 2 ). Sets 𝜆 to be Carmichael’s
lambda function: 𝜙 = lcm(𝑝 ′ − 1, 𝑞 ′ − 1). Outputs the public
key pk = (𝑁 , 𝐺) and the secret key sk = 𝜆. • Existential unforgeability: The scheme Ξ𝑅,Σ is aEUF-CMA
Enc(pk, 𝑚) : To encrypt a message 𝑚 ∈ Z𝑁 , randomly chooses secure if for all PPT adversaries A = (A1, A2 ), it holds that
𝑈 ←𝑅 Z∗𝑁 and outputs the ciphertext 𝑐 = 𝐺 𝑚𝑈 𝑁 mod 𝑁 2 . Pr[aSigForge A,Ξ𝑅,Σ (𝜆) = 1] ≤ 𝜎 (𝜆), where the experiment
𝐿 (𝑐 𝜆 mod 𝑁 2 )
Dec(sk, 𝑐) : To decrypt 𝑐 ∈ Z∗𝑁 2 , computes 𝑚 = 𝐿 (𝐺 𝜆 mod 𝑁 2 ) aSigForge A,Ξ𝑅,Σ is defined as follows:
mod 𝑁 , where 𝐿(𝑥) takes input from 𝑆 = {𝑥 < 𝑁 2 |𝑥 = 1 1 aSigForgeA,Ξ
𝑅,Σ
(𝜆)
mod 𝑁 } and 𝐿(𝑥) = 𝑥𝑁−1 . 2 Q := ∅, (sk𝜎 , pk𝜎 ) ←
− Gen (𝜆), (𝑌 , 𝑦) ←
− RelationGen (𝜆)
O𝑆 (·),O𝑝𝑆 (·,·)
3 (𝑚, st) ←
− A1 (pk𝜎 , 𝑌 )
Correctness: The following holds for any 𝑤 ∈ Z∗𝑁 2 : 𝑤𝜆 = 1 4 𝜎ˆ ←
− pSign (sk, 𝑚, 𝑌 )
O𝑆 (·),O𝑝𝑆 (·,·)
mod 𝑁 and thus 𝑤 𝜆𝑁 = 1 mod 𝑁 2 . Hence, (𝑐 𝜆 mod 𝑁 2 ) and 5 𝜎← − A2 (𝜎,
ˆ st)
(𝐺 𝜆 mod 𝑁 2 ) are equal to 1 when they are raised to the power 6 return (𝑚 ∉ Q ∧ Vrfy(pk𝜎 ,𝑚, 𝜎 ) )
𝑁 ; so they are 𝑁 -th roots of unity, and each of them can be repre- 1 O𝑆 (𝑚) 1 O𝑝𝑆 (𝑚, 𝑌 )
sented as 1 + 𝛽𝑁 mod 𝑁 2 . Then, the function 𝐿 outputs the value 2 𝜎← − Sign (sk, 𝑚) 2 𝜎ˆ ←
− pSign (sk, 𝑚, 𝑌 )
(𝛽 mod 𝑁 ). Therefore 𝐿((𝐺 𝑚 ) 𝜆 mod 𝑁 2 ) = 𝑚 · 𝐿(𝐺 𝜆 mod 𝑁 2 ) 3 Q := Q ∪ {𝑚} 3 Q := Q ∪ {𝑚}
4 return 𝜎 4 return 𝜎ˆ
mod 𝑁 . Note that 𝐿(𝐺 𝜆 mod 𝑁 2 ) ≠ 0 mod 𝑁 as otherwise the
order of 𝐺 would be 𝜆 which is smaller than 𝑁 , and this would • Pre-signature adaptability: For ∀𝑚 ∈ {0, 1}∗, ∀(𝑌 , 𝑦) ∈
contradict the way 𝐺 is chosen in the construction. R, ∀pk𝜎 , ∀𝜎ˆ ∈ {0, 1}∗ the following probability is 1:

Security: The scheme is semantically secure based on the hardness

of breaking the DCR assumption.
Pr[Vrfy(pk𝜎 , 𝑚, Adapt(pk𝜎 , 𝜎,
ˆ 𝑦)) = 1|pVerify(pk𝜎 , 𝑚, 𝑌 , 𝜎)
ˆ = 1]
A.5 Adaptor Signatures
Definition A.6 (Adaptor Signatures). Consider a signature
scheme Σ = (KeyGen, Sign, Verify) and a hard relation R. Let • Witness extractability: The scheme Ξ𝑅,Σ is witness ex-
(pk𝜎 , sk𝜎 ) ← KeyGen(1𝜆 ) and (𝑌, 𝑦) ∈ R. An adaptor signature tractable if for all PPT adversaries A = (A1, A2 ),
Sig scheme with respect to Σ and 𝑌 consists of the following four Pr[aWitExt A,Ξ𝑅,Σ (𝜆) = 1] ≤ 𝜎 (𝜆), where the experiment
algorithms (cf. [27]): aWitExt A,Ξ𝑅,Σ is defined as follows:
𝜎ˆ ← pSign(sk𝜎 , 𝑚, 𝑌 ) : The pre-signing algorithm is a PPT algo- 1 aWitExtA,Ξ𝑅,Σ (𝜆)
rithm that takes sk𝜎 , a message 𝑚 ∈ {0, 1}ℓ and a statement 𝑌 , and 2 Q := ∅, (sk𝜎 , pk𝜎 ) ←
− Gen(𝜆)
O𝑆 (·),O𝑝𝑆 (·,·)
generates a pre-signature 𝜎.
ˆ 3 (𝑚, 𝑌 , st) ←
− A1 (pk𝜎 )
4 𝜎ˆ ←
− pSign (sk, 𝑚, 𝑌 )
𝑏 ← pVerify(pk𝜎 , 𝑚, 𝜎,
ˆ 𝑌 ) : The pre-verification algorithm is a de- O𝑆 (·),O𝑝𝑆 (·,·)
5 𝜎← − A2 (𝜎,
ˆ st)
terministic algorithm that takes pk𝜎 , a message 𝑚 ∈ {0, 1}ℓ , a pre- 6 return ( (𝑌 , Ext(pk𝜎 , 𝜎, 𝜎,
ˆ 𝑌 ) ) ∉ 𝑅 ∧ 𝑚 ∉ Q ∧ Vrfy(pk𝜎 , 𝑚, 𝜎 ) )
signature 𝜎,
ˆ a statement 𝑌 , and returns 0/1.
1 O𝑆 (𝑚) 1 O𝑝𝑆 (𝑚, 𝑌 )
𝜎 ← Adapt(pk𝜎 , 𝜎, ˆ 𝑦) : The adapt algorithm is a PPT algorithm 2 𝜎← − Sign(sk, 𝑚) 2 𝜎ˆ ←
− pSign (sk, 𝑚, 𝑌 )
that takes pk𝜎 , a pre-signature 𝜎ˆ and the witness 𝑦 for the statement 3 Q := Q ∪ {𝑚} 3 Q := Q ∪ {𝑚}
𝑌 in R, and generates an adapted signature 𝜎. 4 return 𝜎 4 return 𝜎ˆ
19
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

B THE SCRIPTS OF OUR ON-CHAIN BONDING 22

23 // Events
CONTRACTS 24 event BroadcastPubKey ( address indexed _seller ,
B.1 Bitcoin Script address indexed _buyer , uint256 _pubKeyX ,
uint256 _timeOut , uint256 _agreedPrice );
25 event BroadcastSecKey ( address indexed _seller ,
Algorithm 1 The bonding contract. Here, ⟨client_public_key⟩, address indexed _buyer , uint256 _secKey );
26
⟨server_public_key⟩ and ⟨adaptor_signature_public_key⟩ denote the
27 constructor (
client’s public key pkC , the server’s public key pkS and the adaptor
28 ) {
signature’s public key pk𝜎 · vk respectively. Before the timelock expires 29 }
(set to 1 month here), it allows spending of the funds by any transaction 30
with two signatures that verify with respect to pkS and pk𝜎 · vk. After the 31 // Agreed price could be set by the contract akin to
timelock expires, it allows spending of the funds by any transaction with a Uniswap whereby price would be dynamically
signature that verifies with respect to pkC . changing
32 // according to a constant product formula given the
OP_IF current number of sellers and buyers ( assuming
<1 month> 33 // that each tx in the orderBook has the same volume )
OP_CHECKLOCKTIMEVERIFY OP_DROP 34 function sellerSendsPubKey (
<client_public_key> 35 uint256 _timeOut ,
OP_CHECKSIGVERIFY 36 uint256 _agreedPrice ,
OP_ELSE 37 uint256 _pubKeyX ,
<server_public_key> 38 uint256 _pubKeyY ,
39 address _buyer
OP_CHECKSIGVERIFY
40 ) public {
<adaptor_signature_public_key>
41 require (! orderBook [ msg . sender ][ _buyer ].
OP_CHECKSIGVERIFY ongoingPurchase , " There can only be one
OP_ENDIF purchase per buyer - seller pair ! " ) ;
42 orderBook [ msg . sender ][ _buyer ]. timeOut = _timeOut ;
43 orderBook [ msg . sender ][ _buyer ]. agreedPrice =
B.2 Solidity smart contract _agreedPrice ;
44 Types . G1Point memory _sellerPubKey = Types .
Our Ethereum-based protocols, cf. Section 4.2, use smart contracts G1Point ( _pubKeyX , _pubKeyY ) ;
to achieve fairness and atomicity. We enclose below our smart con- 45 orderBook [ msg . sender ][ _buyer ]. sellerPubKey =
tract code developed in Solidity for the Ethereum Virtual Machine. _sellerPubKey ;
The following contract is written for the protocol in Section 5.1. 46 orderBook [ msg . sender ][ _buyer ]. ongoingPurchase =
true ;
A very similar contract works also for the Paillier-based protocol, 47
cf. Section 5.2. For brevity, we omit the elliptic curve cryptography 48 emit BroadcastPubKey ( msg . sender , _buyer , _pubKeyX
libraries, i.e., BN254 curve arithmetic, from the contract code. , _timeOut , _agreedPrice ) ;
49 }
1 // SPDX - License - Identifier : MIT
50
2 pragma solidity ^0.8.13;
51 // If buyer agrees to the details of the purchase ,
3
then it locks the corresponding amount of money .
4 import { BN254 } from " ./ BN254 . sol " ;
52 function buyerLockPayment (
5 import { Types } from " ./ Types . sol " ;
53 address _seller
6 import { Constants } from " ./ Constants . sol " ;
54 ) public payable {
7
55 require (! orderBook [ _seller ][ msg . sender ].
8 contract FDE is BN254 {
secretKeySent , " Secret keys have been
9
already revealed ! " ) ;
10 struct agreedPurchase {
56 require ( msg . value == orderBook [ _seller ][ msg .
11 uint256 timeOut ; // The protocol after this
sender ]. agreedPrice , " The transferred money
timestamp , simply aborts and returns funds .
does not match the agreed price ! " );
12 uint256 agreedPrice ;
57 }
13 Types . G1Point sellerPubKey ;
58
14 bool secretKeySent ;
59 function sellerSendsSecKey (
15 bool ongoingPurchase ;
60 uint256 _secKey ,
16 }
61 address _buyer
17
62 ) public {
18 // We assume that for a given seller - buyer pair ,
63 require (! orderBook [ msg . sender ][ _buyer ].
there is only a single purchase at any given
secretKeySent , " Secret key has been already
time
revealed . " ) ;
19 // Maps seller ( server addresses ) to buyer ( client
64 require ( mul ( P1 () , _secKey ) . x == orderBook [ msg .
addresses ) which in turn are mapped to tx
sender ][ _buyer ]. sellerPubKey .x , " Invalid
details
secret key has been provided by the seller !"
20 mapping ( address = > mapping ( address = > agreedPurchase )
);
) public orderBook ; // Privacy is out of scope
65 orderBook [ msg . sender ][ _buyer ]. secretKeySent =
for now
true ;
21 mapping ( address = > uint256 ) balances ; // stores the
Eth balances of sellers
20
 Atomic and Fair Data Exchange via Blockchain

66 balances [ msg . sender ]+= orderBook [ msg . sender ][ the timelock has not expired yet. Finally, C reads sk either from
_buyer ]. agreedPrice ; the bonding contract, or from the adaptor signature (by witness
67 orderBook [ msg . sender ][ _buyer ]. ongoingPurchase =
extractibility), decrypts ct using sk and obtains the data. Thus, with
false ;
68 // There is no need to store the secret key in probability 1, C receives the data, and S receives tk tokens.
storage We next show client-fairness (Def. 4.3). Consider an FDE pro-
69 emit BroadcastSecKey ( msg . sender , _buyer , _secKey ) tocol instance between an honest client C and a PPT server S ∗ ,
; ⟨C(data′ ), S(tk′ )⟩ ← FDE.Exc⟨C(𝐶𝜙 , 𝑝), S ∗ (𝐶𝜙 , data)⟩ such that
70 }
71
tk′ > 0. Since S ∗ receives a positive payment tk′ > 0, in the
72 // This function allocates funds to the server from case of Ethereum, C must have posted tk tokens to the bond-
previous accrued purchase incomes ing contract. Thus, by the existential unforgeability of C’s sig-
73 function withdrawPayment ( natures, C must have verified the proof 𝜋 returned by S ∗ , i.e.,
74
Verct (𝐶𝜙 , vk, ct, 𝜋) = 1, except with negligible probability. Simi-
75 ) public {
76 payable ( msg . sender ) . transfer ( balances [ msg . sender larly, in the case of Bitcoin, by the existential unforgeability of
]) ; the adaptor signatures, C must have sent a presignature to S ∗ , i.e.,
77 Verct (𝐶𝜙 , vk, ct, 𝜋) = 1, except with negligible probability. Since
78 balances [ msg . sender ]=0;
the bonding contract allows S ∗ to receive positive amount of tokens,
79 }
80 Bitcoin and Ethereum are safe and live, and the adaptor signatures
81 // Buyer can withdraw its money if seller does not satisfy existential unforgeability, S ∗ must have posted a decryption
reveal the correct secret key . key sk or a signature adapted with sk, to the bonding contract such
82 function withdrawPaymentAfterTimout ( that Verkey (vk, sk) = 1.
83 address _seller
84 ) public {
Now, for contradiction, assume that given an honest client C,
85 require (! orderBook [ _seller ][ msg . sender ]. there exists a PPT S ∗ such that the following probability is not
secretKeySent , " The encryption secret key negligible in 𝜆:
has already been sent by the seller ! " ) ;
86 require ( block . timestamp >= orderBook [ _seller ][ msg  pp←FDE.Setup(1𝜆 ) 
 ′ ⟨ C (com),S (data) ⟩←FDE.Com⟨ C (data),S () ⟩ 

. sender ]. timeOut , " The seller has still time Pr FDE.Vrfy(data ∧,com)=0
tk′ >0 Inputs: C (com,tk),S ∗ (com,data) 
to provide the encryption secret key ! " ) ;
⟨ C (data′ ),S ∗ (tk′ ) ⟩←FDE.Exc⟨ C,S ∗ ⟩ 
 
87 orderBook [ _seller ][ msg . sender ]. ongoingPurchase = 
false ;
88 payable ( msg . sender ) . transfer ( orderBook [ _seller ][
However, FDE.Vrfy(data′, com) = 0 implies that Dec(sk, ct) = 𝑦 ≠
msg . sender ]. agreedPrice ) ; data = 𝐹 (𝜙 (·)) = 𝐹 (𝑤), where the witness 𝑤 is the polynomial
89 } 𝜙 (·) and 𝐹 (.) outputs the sequence of its evaluations. Consequently,
90 } the following probability is not negligible in 𝜆 either:
 crs ← Setup(1𝜆 ) 
C PROOFS 
 Verct (𝐶 𝑤 , vk, ct, 𝜋) = 1 ∧ 𝐶 𝑤 ← Commit(crs, 𝑤)


 
C.1 Proof of security of BDE based on VECK’s Pr  Verkey (vk, sk) = 1 ∧ pp ← Gen(crs) 

security, Theorem 4.1 
 𝑦 ≠ 𝐹 (𝑤) (sk, vk, ct, 𝜋) ← A (pp, 𝐶 𝑤 ) 

 𝑦 ← Dec(sk, ct) 
Proof of Theorem 4.1. Throughout the proof, we assume that  
FDE.Setup(1𝜆 ) →
− pp and However, this contradicts the security of the VECK protocol (Defi-
FDE.Com⟨C(data), S()⟩ →
− ⟨C(𝐶𝜙 ), S(data)⟩. nition 3.1).
We last show server-fairness (Def. 4.4). Consider an FDE pro-
We first show correctness (Definition 4.2). When both client tocol instance between an honest server S and a PPT client C ∗ ,
C and server S are honest, S runs Enc(𝐶𝜙 , data) to generate ⟨C(data′ ), S(tk′ )⟩ ← FDE.Exc⟨C(𝐶𝜙 , tk), S(𝐶𝜙 , data)⟩ such that
(vk, sk, ct, 𝜋). By the correctness of the VECK protocol (Defini- tk′ < tk. Note that the server S posts sk to the bonding contract
tion 3.1), with probability 1, it holds that Verct (𝐶𝜙 , vk, ct, 𝜋) = 1 only if C ∗ locks tk tokens, in which case it would have received
and Verkey (vk, sk) = 1. Then, before the timelock expires, C locks tk tokens. As S receives only tk′ < tk, it must be that S has not
tk tokens in the bonding contract on Ethereum, and in the case of posted sk. Similarly, in the case of Bitcoin, it would have posted tx
Bitcoin, creates a bonding contract and sends a pre-signature to S. with an adapted signature and its signature, only if C ∗ has created
By the pre-signature correctness of the adaptor signature scheme, a bonding contract that allows the spending of tk tokens by a trans-
C’s signature is verified by S. Afterwards, S posts the decryption action with the adaptor and the server’s signature. In this case, S
key sk to the bonding contract on Ethereum, upon which the con- would have received tk tokens by the existential unforgeability of
tract sends tk tokens to S within finite time, as Ethereum is safe its signature scheme. Consequently, as S receives only tk′ < tk, it
and live, Verkey (vk, sk) = 1, and the timelock has not expired yet. must be that it has not sent an adapted signature. This implies that
Similarly, S adapts the pre-signature with sk and posts the signed the only information sent by S consists of a verification key (vk),
spending transaction tx to Bitcoin, after which it receives tk tokens the ciphertexts (ct) and a proof (𝜋) that verifies.
within finite time, as Bitcoin is safe and live, the adaptor signature Now, by the computational zero-knowledge property of the
scheme satisfies pre-signature adaptability, Verkey (vk, sk) = 1, and VECK scheme (Definition 3.1), for any PPT C ∗ , there exists a PPT
21
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

simulator Sim C∗ with oracle access to C ∗ such that there is a negli- key verification Verkey implies that for sk = 𝑠, vk = ℎ𝑠 . Further-
gible function 𝜇 (·) for which the following probability is less than more, since the ciphertext verification Verct also holds, we have:
1 + 𝜇 (𝜆):
2
𝑒 (C𝜙 /C𝛼 , 𝑔2 ) = 𝑒 (𝜋𝛼 , 𝑔𝜏2 −𝛼 ) (C.1)
 crs ← Setup(1𝜆 )  ℓ  ℓ
𝐿 (𝛼 ) 𝑠

𝐿 (𝛼 )
 
−𝑠 (𝜏 −𝛼 )
Ö Ö

 𝐶 𝑤 ← Commit(crs, 𝑤) 
 ℎ𝑖 𝑖,ℓ · 𝑔1 = ct𝑖 𝑖,ℓ /C𝛼 (C.2)

 pp ← Gen(crs) 
 𝑖=0 𝑖=0
Pr A (pp, 𝐶 𝑤 , vk𝑏 , ct𝑏 , 𝜋𝑏 ) = 𝑏 (vk0, sk0, ct0, 𝜋0 ) 


↱

 Enc(pp, 𝐶 𝑤 , 𝑤) 
 Since 𝜋𝐿𝐼 𝑁 is valid, the adversary must know some value 𝑤 such

 (vk1, ct1, 𝜋1 ) ← Sim C∗ (pp, 𝐶 𝑤 ) 
 that 𝐶𝛼 = 𝑔1
𝑤+(𝜏 −𝛼 )𝑠
(this helps guarantee that 𝑤 does not depend

 𝑏 ←𝑅 {0, 1} 
 on 𝜏). Furthermore, in the algebraic group model (AGM), without
𝑢 (𝜏 )
loss of generality, we can assume that 𝜋𝛼 = 𝑔1 , where 𝑢 (𝜏) is a
Finally, consider the PPT simulator Sim with oracle access to C ∗
polynomial of degree at most ℓ over the 𝜏. Therefore, equation C.1
that simulates vk, ct, and 𝜋 using the simulator Sim C∗ above and
becomes:
equipped with them, simulates a trace 𝛼 1 for the interaction of C ∗
and S with tk′ < tk. Then, using the bound on the probability above 𝜙 (𝜏 ) −𝑤−𝑠 (𝜏 −𝛼 ) 𝑢 (𝜏 )
𝑒 (𝑔1 , 𝑔2 ) = 𝑒 (𝑔1 , 𝑔𝜏2 −𝛼 ) (C.3)
and the fact that S only sends a verification key vk, ciphertexts ct
and a verifying proof 𝜋 when tk′ < tk, we can conclude that the
following probability is less than 12 +𝜇 (𝜆) (otherwise, the probability Assuming AGM, we must then have the following identity:
above would not be less than 12 + 𝜇 (𝜆), implying a contradiction):
𝜙 (𝑥) − 𝑤 − 𝑠 (𝑥 − 𝛼) = 𝑢 (𝑥) · (𝑥 − 𝛼) (C.4)
 pp←FDE.Setup(1𝜆 ) 
 ⟨ C (com),S (data) ⟩←FDE.Com⟨ C (data),S () ⟩  𝜙 (𝛼 )+(𝜏 −𝛼 )𝑠

 Inputs: C ∗ (com,tk),S (com,data)  We thus deduce that 𝑤 = 𝜙 (𝛼), and C𝛼 = 𝑔1 . Therefore,
Pr C ∗ (com, 𝛼𝑏 ) = 𝑏
 𝛼0 ←−tr(⟨ C ∗ ,S⟩ ←
−FDE.Exc⟨ C ∗ ,S⟩ )  if 𝜙 (𝑋 ) is of degree ℓ, equation C.2 becomes:
 Outputs: C ∗ (data′ ),S (tk′ ) s.t. tk′ <tk
 −SimC∗ (pp,com,tk) 
𝛼1 ←
 ℓ  ℓ
𝑅
𝐿 (𝛼 ) 𝑠
  
−𝑠 (𝜏 −𝛼 ) 𝐿 (𝛼 ) (𝜏 −𝛼 )𝑠 𝜙 (𝛼 )
Ö Ö
𝑏← − {0,1} 
 
 ℎ𝑖 𝑖,ℓ · 𝑔1 = ct𝑖 𝑖,ℓ / 𝑔1 · 𝑔1 ⇔
𝑖=0 𝑖=0
Since this holds for any honest server S and all PPT C ∗ , this con- ℓ
□ 𝜙 (𝛼 )
Ö
cludes the proof of server-fairness. 𝑔1 = (ct𝑖 /ℎ𝑠𝑖 ) 𝐿𝑖,ℓ (𝛼 ) (C.5)
𝑖=0
C.2 Proof of security for ElGamal-based VECK,
Theorem 5.1 Finally, we show that 𝜙 (𝑋 ) is of degree ℓ. Let’s denote by Φ𝑖 =
ct𝑖 /ℎ𝑠𝑖 ∈ 𝐺 1 , and define the degree ℓ polynomial Φ(𝑥) ∈ 𝐺 1 [𝑥],
In Section 5.1, we gave the intuition behind the proofs; here, we
where Φ(𝑖) = Φ𝑖 for 𝑖 ∈ [0, ℓ]. Rewriting Equation (C.5), we have
elaborate and give more details. 𝜙 (𝛼 ) 𝜙 (𝑥 )
𝑔1 = Φ(𝛼). Since the polynomials 𝑔1 and Φ(𝑥) agree on a
𝜙 (𝑥 )
random point 𝛼, and the degree of 𝑔1 , Φ(𝑥) is at most max(𝑛, ℓ) =
Proof. Correctness. The proof 𝜋𝛼 verifies correctly due to the
𝑛, by Schwartz-Zippel lemma, if the two polynomials are not the
correctness of the KZG commitment scheme. The Chaum-Pedersen
same, then they agree at a random point with all but 𝑛/𝑝 probability.
discrete logarithm equality proof [22] 𝜋DLEq for the quadruple
Therefore if the verifier accepts with probability greater than 1−𝑛/𝑝,
(𝑄, 𝑄 ∗, 𝑔1, vk) verifies correctly since vk = 𝑔𝑠 , and the following 𝜙 (𝑥 )
holds we must have that 𝑔1 , Φ(𝑥) are the same polynomial. As a result,
𝜙 (𝑖 )
we have Φ(𝑖) = 𝑔1 for all 𝑖 ∈ [0, ℓ], and both polynomials have
ℓ 𝐿 (𝛼 ) ℓ ℓ
𝜙 (𝑖 )
(ℎ𝑠𝑖 · 𝑔𝜙 (𝑖 ) ) 𝐿𝑖,ℓ (𝛼 ) 𝑔𝜙 (𝑖 )𝐿𝑖,ℓ (𝛼 )
Î Î Î
ct𝑖 𝑖,𝑆 𝑄𝑠 degree exactly ℓ. This implies ct𝑖 = 𝑔1 · ℎ𝑠𝑖 is indeed the correct
𝑄∗ =
𝑖=0 𝑖=0 𝑖=0
= = = 𝑄𝑠 . encryption for the full evaluations of 𝜙 (𝑥) over full evaluation
𝐶𝛼 𝐶𝛼 𝑔𝜙 (𝛼 ) domain 𝑖 ∈ [0, ℓ].
Computational Zero-Knowledge We build an efficient simu-
 the linear relation verifies correctly since 𝐶𝛼 =
The 𝜋LIN proof for
lator that takes as input: (ℎ, {ℎ𝑖 }, 𝐶𝜙 , 𝛼, crs) and outputs indistin-
(𝜏 −𝛼 ) 𝑠
(𝑔1 )𝜙 (𝛼 ) 𝑔1 and vk = (1)𝜙 (𝛼 ) · (ℎ)𝑠 . It is easy to see that guishably distributed tuple (vk, {ct𝑖 }, 𝜋 = (𝐶𝛼 , 𝜋𝛼 , 𝜋DLeq, 𝜋LIN ))
Verkey would trivially accept and Dec would output 𝜙 (𝑖) as ex- without the knowledge of 𝜙. We start by sampling ℓ random co-
pected. 𝛽
efficients 𝛽 1, . . . , 𝛽 ℓ ←𝑅 F𝑝 , and ∀𝑖 ∈ [ℓ], we set 𝐵𝑖 := 𝑔1 𝑖 . We
Soundness. Let C𝜙 be a commitment to polynomial 𝜙 (𝑋 ) ∈ 𝑠
sample a random 𝑠 ←𝑅 F𝑝 and set vk := ℎ . We generate the
F𝑝 [𝑋 ] of degree ℓ. Suppose there is a PPT adversary A that breaks proofs in a way similar to honest execution, but for a polynomial
the security, i.e., with non-negligible probability, the adversary 𝛽
𝜙e(𝑥) = 𝛽 ℓ 𝑥 ℓ + . . . 𝛽 1𝑥 + 𝛽 0 , where we only know 𝐵 0 = 𝑔1 0 and not
generates (sk, vk, ct = [ct0, . . . , ctℓ ], 𝜋 = (C𝛼 , 𝜋𝛼 , 𝜋LIN, 𝜋DLEQ )), s.t.
the key and ciphertext verifications are successful, yet the decryp- the value in the exponent (𝛽 0 ); 𝐵 0 is generated so that 𝜙e commits
𝜙e(𝜏 )
tion of ct with sk outputs (𝑦0, . . . 𝑦ℓ ) ≠ (𝜙 (0), . . . , 𝜙 (ℓ)). Successful to the same value as given to the simulator: 𝑔1 = 𝐶𝜙 , for which
22
Atomic and Fair Data Exchange via Blockchain

𝛽 𝜏 ℓ +...+𝛽 1𝜏
we set 𝐵 0 := 𝐶𝜙 /𝑔1 ℓ . For all 𝑖 ∈ [ℓ], we compute with non-negligible probability. We then obtain the following equa-
tions:
′ ′
ct𝑖 :=ℎ𝑠𝑖 · 𝐶𝜙 · 𝑔1 ℓ
𝛽 (𝑖 ℓ −𝜏 ℓ )+...+𝛽 (𝑖 −𝜏 )
1
= ℎ𝑠𝑖 · 𝑔1
𝜙e(𝑖 ) 1 = (𝑁 + 1)𝑧𝑖 −𝑧𝑖 (𝑊𝑖 /𝑊𝑖′ ) 𝑁 ct𝑖−𝑐+𝑐 =
′ ′ ′
𝛽 (𝛼 ℓ −𝜏 ℓ )+...+𝛽 1 (𝛼 −𝜏 ) 𝜙e(𝛼 )+𝑠 (𝜏 −𝛼 ) = (𝑁 + 1) (𝑧𝑖 −𝑧𝑖 ) − (𝑐 −𝑐 )𝑥𝑖 (𝑈𝑖−𝑐+𝑐 𝑊𝑖 /𝑊𝑖′ ) 𝑁 mod 𝑁 2
𝐶𝛼 := 𝑔𝜏1 −𝛼 · 𝐶𝜙 · 𝑔1 ℓ

𝑠
= 𝑔1 Ö 𝑧 −𝑧 ′ ′
Ö (𝑧 −𝑧 ′ ) −𝜙 (𝑖 ) (𝑐 −𝑐 ′ )
(𝛽 ℓ (𝜏 ℓ −𝛼 ℓ )+...+𝛽 1 (𝜏 −𝛼 ) )/(𝜏 −𝛼 ) (𝜙e(𝜏 ) −𝜙e(𝛼 ) )/(𝜏 −𝛼 ) 1= crs𝑖 𝑖 𝑖 /𝐶𝜙𝑐 −𝑐 = crs𝑖 𝑖 𝑖 ∈ G1
𝜋𝛼 :=𝑔1−𝑠 · 𝑔1 = 𝑔1−𝑠 · 𝑔1 𝑖 ∈ [ℓ ] 𝑖 ∈ [ℓ ]
In the AGM, it follows that the equations below must hold for some
The verification equations are satisfied. Note that the values that
Δ𝑧𝑖 = 𝑧𝑖 − 𝑧𝑖′ , Δ𝑧𝑖 ∈ [−𝐴, 𝐴) and Δ𝑐𝑖 = 𝑐 − 𝑐 ′ , Δ𝑐𝑖 ∈ [−𝐵, 𝐵):
involve 𝜏 are computed using the group elements in the crs, since
the simulator does not know the trapdoor 𝜏. The 𝜋 DLeq proof is Δ𝑧𝑖 = Δ𝑐𝑖 · 𝑥𝑖 mod 𝑁 (C.6)
computed the same way as in the honest execution. The proof 𝜋LIN Δ𝑧𝑖 = Δ𝑐𝑖 · 𝜙 (𝑖) mod 𝑝 (C.7)
is simulated since we do not know the witness, yet the respec-
tive statement is in the language (has the witness). Therefore, its By construction, if 𝑥𝑖 ≠ 𝜙 (𝑖) for some 𝑖 (which is checked by recom-
distribution is indistinguishable from the real one. We note that mitting to the decrypted vector), the lattice reduction algorithm is
− (𝜏 −𝛼 ) run for each 𝑖 ∈ [ℓ] to find (𝜎𝑖 , 𝜈𝑖 ) – the shortest vector in the inte-
𝐶 𝛼 = 𝐶𝜙 · 𝜋 𝛼 is uniquely determined by 𝜋𝛼 in both the real
ger lattice with basis ((𝑁 , 0), (𝑥𝑖 , 1)), and the decryption outputs
and our simulated executions. Hence, the correct distribution of 𝜋𝛼
𝑥𝑖′ = 𝜎𝑖 /𝜈𝑖 mod 𝑝. We now argue why 𝜎𝑖 /𝜈𝑖 = Δ𝑧𝑖 /Δ𝑐𝑖 mod 𝑝,
implies the correct distribution for 𝐶𝛼 . Next, the DDH assumption
and hence why the decryption procedure outputs the correct eval-
in G1 guarantees that given the generators (ℎ, {ℎ𝑖 }, 𝑔1 ), the distri-
uations: 𝑥𝑖′ = 𝜙 (𝑖). We follow Poupard and Stern [59] approach
bution of (ℎ𝑠 , {(ℎ𝑖 )𝑠 }, 𝑔𝑠1 ) is indistinguishable from random both in
(see proof of Theorem 1), where the inner product for the Gauss
the simulated and in the real executions, even given 𝜋 DLeq which
algorithm is defined to be (𝑥, 𝑦) · (𝑥 ′, 𝑦 ′ ) ⇋ 𝑥𝑥 ′ + 𝐴2√︁/𝐵 2 × 𝑦𝑦 ′ , the
could be simulated and would verify correctly even when there is
norm is defined in the standard manner: ||(𝑥, 𝑦)|| = (𝑥, 𝑦) · (𝑥, 𝑦).
no witness 𝑠 (which is due to its special-HVZK property).
The unknown vector (Δ𝑧𝑖 , Δ𝑐𝑖 ) is also in the lattice according to
□
equation Equation (C.6), therefore, √︁ since it might not be√the short-
est, ||(𝜎𝑖 , 𝜈𝑖 )|| ≤ ||(Δ𝑧𝑖 , Δ𝑐𝑖 )|| < 𝐴2 + 𝐴2 /𝐵 2 × 𝐵 2 = 2𝐴. From √
C.3 Proof of security for Paillier-based VECK, the definition of inner product, |𝜎𝑖 | ≤ ||(𝜎𝑖 , 𝜈𝑖 )||, hence |𝜎𝑖 | <√ 2𝐴.
Theorem 5.2 Also from the definition |𝜈𝑖 | ≤ 𝐴 𝐵 ||(𝜎 , 𝜈 )||, therefore |𝜈 | < 2𝐵.
𝑖 𝑖 𝑖
Proof of Theorem 5.2. We show that the protocol described Δ𝑐𝑖 · 𝑥𝑖 − Δ𝑧𝑖 = 0 mod 𝑁 and 𝜈𝑖 · 𝑥𝑖 − 𝜎𝑖 = 0 mod 𝑁 , therefore
in Figure 4 satisfies correctness, security and zero-knowledge as 𝜈𝑖 · Δ𝑧𝑖 = Δ𝑐√ 𝑖 · 𝜎𝑖 mod 𝑁 . Since √ |𝜈𝑖 · Δ𝑧𝑖 − Δ𝑐𝑖 · 𝜎𝑖 | ≤ |𝜈𝑖 ||Δ𝑧𝑖 | +
defined in Definition 3.1. |Δ𝑐𝑖 ||𝜎𝑖 | < 2 2𝐴𝐵 and 𝑁 ≥ 2 2𝐴𝐵, then the equation must hold
Correctness. Correctness of decryption and key verification is over integers: 𝜈𝑖 · Δ𝑧𝑖 = Δ𝑐𝑖 · 𝜎𝑖 in Z. The since 𝑝 is prime, the
due to the correctness of the Paillier cryptosystem. The ciphertext equation must also hold modulo 𝑝: 𝜈𝑖 · Δ𝑧𝑖 = Δ𝑐𝑖 · 𝜎𝑖 mod 𝑝.
verification could fail when either of the 𝑧 values fall out of the Therefore 𝜎𝑖 /𝜈𝑖 = Δ𝑧𝑖 /Δ𝑐𝑖 = 𝜙 (𝑖) mod 𝑝. Hence the decryption
range [0, 𝐴). For our protocol, the probability that a single 𝑧𝑖 falls would correctly output committed values.
out of the range [0, 𝐴) is smaller than (𝑝 ·𝐵/𝐴). Then, the probability Statistical Zero-knowledge. We build a simulator that takes
of failure due to at least one 𝑧𝑖 ≥ 𝐴 being out of range is smaller as input the commitment 𝐶𝜙 and the public parameter crs. The sim-
ℓ ·𝑝 ·𝐵
than 1 − (1 − (𝑝 · 𝐵/𝐴)) ℓ ≤ 𝐴 ≤ 21𝜆 , which is negligible in 𝜆. ulator produces the transcript of the interaction by first generating
Soundness. Suppose there is a PPT adversary A that breaks a correct Paillier public key vk, then choosing random 𝑐 ←𝑅 [0, 𝐵),
the security, i.e., with non-negligible probability, the adversary gen- ct𝑖 ←𝑅 𝑁 2 , 𝑧𝑖 ←𝑅 [0, 𝐴) and 𝑊𝑖 ←𝑅 Z∗𝑁 for all 𝑖 ∈ [ℓ], and
finally programming the random oracle as H(vk, {ct𝑖 }𝑖=1 ℓ , {(𝑁 +
erates (sk, vk, ct = (ct0, . . . , ctℓ ), 𝜋 = (𝑐,𝑊0, . . . ,𝑊ℓ , 𝑧 0, . . . , 𝑧 ℓ )), s.t.
the key and ciphertext verifications are successful, yet the decryp- 1)𝑧𝑖 𝑊𝑖𝑁 ct𝑖−𝑐 }𝑖=1ℓ , C𝑐 /Îℓ crs[𝑖] 𝑧𝑖 ) := 𝑐. The simulator outputs
𝑖=1
tion outputs an invalid witness. Successful key verification Verkey vk as the verification key, ct𝑖 , 𝑖 ∈ [𝑛], as the ciphertexts and 𝜋 =
implies that for sk = (𝑝 ′, 𝑞 ′, 𝜇), vk = 𝑁 = 𝑝 ′𝑞 ′ . 𝑝𝐵ℓ
(𝑐,𝑊1, . . . ,𝑊ℓ , 𝑧 1, . . . , 𝑧 ℓ ) as the simulated proof. For 𝐴 < negl(𝜆),
For any value of 𝑔 ∈ Z∗𝑁 2 whose order is a non-zero multiple the distribution of this transcript is statistically indistinguishable
of 𝑁 the following function is bijective (see Lemma 1, [55]) E𝑔 : from the real transcript (since the probability that any 𝑧𝑖 is not in
Z𝑁 × Z∗𝑁 → Z∗𝑁 2 , defined as E𝑔 : (𝑥, 𝑦) → 𝑔𝑥 𝑦 𝑁 mod 𝑁 2 . We use [0, 𝐴) in the real execution is negligible in 𝜆).
𝑔 = (𝑁 + 1), since (𝑁 + 1) 𝑁 = 1 mod 𝑁 2 . Given a factorization □
of 𝑁 = 𝑝 ′ · 𝑞 ′ or given a Carmichael’s lambda function of 𝑁 : 𝜇 =
lcm(𝑝 ′, 𝑞 ′ ), it is easy to invert E𝑔 to recover 𝑥. C.4 Proof of security of VECK for subsets,
We will now show that if the ciphertext verification Verct holds, Theorem 5.3
the decryption procedure will recover correct values of 𝜙 (𝑖) of the Correctness holds by construction.
committed polynomial 𝐶𝜙 . Without loss of generality we can as- Soundness. Let 𝐶𝜙 be the commitment to polynomial 𝜙 (𝑋 ) ∈
sume that there exists 𝑥𝑖 ∈ Z𝑁 , 𝑈𝑖 ∈ Z∗𝑁 , s.t. ct𝑖 = (𝑁 + 1)𝑥𝑖 𝑈𝑖𝑁 . We F𝑝 [𝑋 ] of degree ℓ and let 𝑆 ⊆ F𝑝 and |𝑆 | ≤ ℓ + 1. Suppose there is a
run the adversary twice in order to obtain two proofs (𝑐,𝑊0, . . . ,𝑊ℓ , PPT adversary A that breaks the security, i.e., with non-negligible
𝑧 0, . . . , 𝑧 ℓ ) and (𝑐 ′,𝑊0′, . . . ,𝑊ℓ′, 𝑧 0′ , . . . , 𝑧 ℓ′ ) that pass the verification probability, the adversary generates (sk, vk, ct, 𝜋 = (𝐶𝑆 , 𝜋𝑆 , 𝜋 ′ )), s.t.
23
 Ertem Nusret Tas, István András Seres, Yinuo Zhang, Márk Melczer, Mahimna Kelkar, Joseph Bonneau, and Valeria Nikolaenko

the key and ciphertext verifications are successful, yet the decryp- Verct (𝐹, 𝐶𝜙 , vk C /𝐷 C , ct, 𝜋) = 1. Then, by (i) and the security of
tion outputs an invalid value. Here, (sk, vk, ct, 𝜋 ′ ) correspond to the scheme in [22],
the output of Enc(𝐹𝑆full-eval, 𝐶𝑆 , 𝜙𝑆 (𝑋 )). Since the ciphertext verifi- Ö Ö
𝛿 𝑒
ℎ𝑒C,𝑖
𝑖
= ℎ𝑖 C 𝑖
cation Verct holds, we have:
𝑖 ∈ [𝑛] 𝑖 ∈𝑛
𝑉 (𝜏 )
𝑒 (𝐶𝜙 /𝐶𝑆 , 𝑔2 ) = 𝑒 (𝜋𝑆 , 𝑔2 𝑆 ) (C.8) for (𝑒𝑖 )𝑖 ∈ [𝑛] = (𝐻 (𝐷 C , 𝑖))𝑖 ∈ [𝑛] , where 𝐻 (.) is modelled as a ran-
dom oracle. In the Random Oracle model, this equality must hold
In the algebraic group model, without loss of generality, we
𝑢 (𝜏 ) 𝜙 (𝜏 ) 𝑣 (𝜏 ) for a random (𝑒𝑖 )𝑖 ∈ [𝑛] ←𝑅 Z𝑛𝑝 , with all but 1/𝑝 probability, and
can assume that 𝜋𝑆 = 𝑔1 , 𝐶𝜙 = 𝑔1 and 𝐶𝑆 = 𝑔1 , where
we must have ℎ C,𝑖 = ℎ𝑖 C for all 𝑖 ∈ [𝑛]. Since vk C = ℎ sk+𝛿 C ,
𝛿
𝑢 (𝑥), 𝜙 (𝑥), 𝑣 (𝑥) are polynomials of degree at most 𝑛. Therefore, Equa-
tion (C.8) becomes: Verkey (vk C , sk C ) = 1 implies sk C = sk + 𝛿 C mod 𝑝. Therefore, if
Dec(sk C , (ct𝑖 , ℎ C,𝑖 )𝑖 ∈ [𝑛] ) succeeds, it outputs (𝑚𝑖 )𝑖 ∈ [𝑛] such that
𝜙 (𝜏 ) −𝑣 (𝜏 ) 𝑢 (𝜏 ) 𝑉 (𝜏 )
𝑒 (𝑔1 , 𝑔2 ) = 𝑒 (𝑔1 , 𝑔2 𝑆 ) (C.9) sk+𝛿 sk+𝛿
= ct𝑖 · ℎ𝑖 C /ℎ𝑖 C = ct𝑖 /ℎ𝑖sk,
𝛿
𝑔𝑚1 = ct𝑖 · ℎ C,𝑖 /ℎ𝑖
𝑖 C

Assuming AGM, and the fact that the adversary has to satisfy Equa-
which implies Dec(sk C , ct C ) = Dec(sk, ct). As 𝐹 (𝜙) ≠ Dec(sk C , ct),
tion (C.9) without knowing 𝜏, we must have the following identity:
Ö it holds that 𝐹 (𝜙) ≠ Dec(sk, ct).
𝜙 (𝑥) − 𝑣 (𝑥) = 𝑢 (𝑥) · (𝑥 − 𝑖) (C.10) Finally, for contradiction, suppose the following probability is
𝑖 ∈𝑆 not negligible for the MC-VECK protocol:
Therefore, ∀𝑖 ∈ 𝑆 : 𝑣 (𝑖) = 𝜙 (𝑖). Finally, since we apply a full-  crs ← Setup(1𝜆 ) 
𝑣 (𝜏 )
 
opening VECK on the commitment 𝐶𝑆 = 𝑔1 , we must have the 
 Verct (𝐹, 𝐶𝜙 , vk C , ct, 𝜋 C ) = 1 ∧ 𝐶 𝑤 ← Commit(crs, 𝜙) 

encryptions correctly encrypt the values 𝜙 (𝑖) over the subset 𝑆.  pp ← Gen(crs) 
Pr  Verkey (vk C , sk C ) = 1 ∧ 
Computational Zero-Knowledge. We build an efficient simula- (sk C , vk C , ct, 𝜋 C ) 
 𝑦 ≠ 𝐹 (𝜙) 
A (pp, )

↱
tor that takes as input pp and outputs indistinguishably distributed 
 𝐹, 𝐶 𝜙


tuple (vk, ct, 𝜋) without the knowledge of 𝜙 (𝑋 ). We simulate by 
 𝑦 ← Dec(sk, ct) 

𝑦𝑉 (𝜏 )
sampling a random 𝑦 ←𝑅 F𝑝 and setting 𝐶𝜙𝑆 := 𝐶𝜙 /𝑔1 𝑆 and Then, for (sk, vk, ct, 𝜋) ← A ′ (𝐶𝜙 ) that outputs a subset of A’s out-
𝑦
𝜋𝑆 := 𝑔1 . Note that there is a one-to-one relationship between put, it holds that Verct (𝐹, 𝐶𝜙 , vk, ct, 𝜋) = 1, Verkey (vk, sk) = 1 and
𝐶𝜙𝑆 and 𝜋𝑆 that guarantees acceptance by the verifier: 𝐶𝜙𝑆 = 𝐹 (𝜙) ≠ Dec(sk, ct) with non-negligible probability in 𝜆. However,
−𝑉 (𝜏 ) this conflicts with the security of the VECK protocol of Section 5.1.
𝐶𝜙 𝜋𝑆 𝑆 , so the correct distribution on 𝜋𝑆 implies correct dis-
tribution on 𝐶𝜙𝑆 . We note that in the honest execution 𝜋𝑆 = 𝑔𝑡1 · Computational L-bits zero-knowledge: To prove computational
(𝜙 (𝜏 ) −
Í
𝑖 ∈𝑆 𝜙 (𝑖 )𝐿
𝑖,𝑆 𝑆 (𝜏 ) )/𝑉 (𝜏 ) L-bits zero-knowledge for the MC-VECK protocol, we first observe
𝑔1 , and in here in the simulated execu- that the distributions
𝑦
tion 𝜋𝑆 = 𝑔1 . Since both 𝑡 and 𝑦 are sampled uniformly at random,
{(aux, msk)|(aux, msk) ←
− Prep(𝐹, 𝐶 𝑤 , 𝑤)}
the distributions are equivalent.
{(vk, ct, 𝜋, sk)|(vk∗, sk∗, ct∗, 𝜋∗ ) ← Enc(𝐹, aux, msk)}
C.5 Proof of security of Multi-Client VECK, are statistically indistinguishable. Thus, computational L-bits zero-
Theorem 7.1 knowledge for the original VECK protocol (defined below) implies
Proof of Theorem 7.1. We prove correctness, soundness and computational L-bits zero-knowledge for the MC-VECK protocols:
computational L-bits zero-knowledge for the MC-VECK protocol Computational L-bits zero-knowledge for the VECK protocols: Con-
in Section 7.3, Figure 7. sider a normal VECK protocol Π ′ = (Gen, Enc′, Verct, Verkey, Dec).
Correctness: When Prep(𝐶𝜙 , 𝜙) = Enc(𝐶𝜙 , 𝜙) → − (sk, vk, ct, 𝜋) We say that it satisfies computational L-bits zero-knowledge, if
for any PPT algorithms A1 and A2 , there exists a PPT simula-
and 𝐷 C = ℎ𝛿 C , Verct (𝐹, 𝐶𝜙 , vk C /𝐷 C , ct, 𝜋) returns 1 by the correct-
tor Π · Sim such that there is a negligible function 𝜇 (·), s.t. for all
ness of the VECK protocol of Section 5.1, and vk C = ℎ sk+𝛿 C = ℎ skC . 𝑤 ∈ W, ∀𝐹 ∈ F the following probability is less than 1/2 + 𝜇 (𝜆):
𝛿
Moreover, given ℎ C,𝑖 = (ℎ𝑖 C )𝑖 ∈ [𝑛] , the discrete logarithm equality  crs ← Setup(1𝜆 ) 
proof 𝜋DLEq verifies for (𝑄 := 𝑖 ∈ [𝑛] ℎ𝑖𝑒𝑖 , 𝑄 ∗ := 𝑖 ∈ [𝑛] ℎ𝑒C,𝑖
Î Î 𝑖
, ℎ, 𝐷 C )  
𝑛
 𝐶 𝑤 ← Commit(crs, 𝑤) 
for any (𝑒𝑖 )𝑖 ∈ [𝑛] ∈ Z𝑝 by the correctness of [22]. Therefore, veri- 
 pp ← Gen(crs)


fication for honestly generated keys and ciphertexts will always  
 (vk ∗ , sk∗ , ct ∗ , 𝜋 ∗ ) 
Π · Enc (pp, 𝐹, 𝐶 𝑤 , 𝑤)
′ ′
 
succeed.
↱

 
 A2 (pp, 𝐹, 𝐶 𝑤 ,
Soundness: Consider an adversary A (𝐶𝜙 ) → − (sk C , vk C , ct, 𝜋 C )

Pr  hint ← A1 (vk∗, sk∗, ct∗, 𝜋∗ ) 
for which Verct (𝐹, 𝐶𝜙 , vk C , ct, 𝜋 C ) = 1 and Verkey (vk C , sk C ) = 1,  hint, aux𝑏 ) = 𝑏 (aux0 = (vk0, ct0, 𝜋0 ), msk0 = sk0 ) 

 
yet 𝐹 (𝜙) ≠ Dec(sk C , ct) for 𝐹 := 𝐹 [𝑛] full-eval . Let 𝜋 = (𝜋, 𝐷 , 𝜋
Π ′ · Enc′ (pp, 𝐹, 𝐶 𝑤 , 𝑤)
↱

C C DLEq 



, (ℎ C,𝑖 )𝑖 ∈ [𝑛] ). Let sk denote the discrete logarithm between vk C /𝐷 C 
 aux 1 = (vk , ct
1 1 1 , 𝜋 ) 

and ℎ (thus, by definition, Verkey (vk C /𝐷 C , sk) = 1), and 𝛿 C the dis- Π ′ · Sim(pp, 𝐹, 𝐶 , hint)
↱

 
 𝑤 
crete logarithm between 𝐷 C and ℎ. Note that Verct (𝐹, 𝐶𝜙 , vk C , ct, 𝜋 C ) 
 𝑏 ←𝑅 {0, 1} 

Î 𝑒𝑖
= 1 implies (i) 𝜋DLEq verifies against (𝑄 := 𝑖 ∈ [𝑛] ℎ𝑖 , Note that no PPT adversary would be able to distinguish the encryp-
∗ Î 𝑒𝑖
𝑄 := 𝑖 ∈ [𝑛] ℎ C,𝑖 , ℎ, 𝐷 C ) for (𝑒𝑖 )𝑖 ∈ [𝑛] = (𝐻 (𝐷 C , 𝑖))𝑖 ∈ [𝑛] , and (ii) tions of any two values 𝑤 0 ≠ 𝑤 1 with the same commitment 𝐶 𝑤 by
24
Atomic and Fair Data Exchange via Blockchain

the computational zero-knowledge property of the original VECK Π · Sim be simply the PPT simulator of the original VECK protocol
protocol Π ′ . Although many such values exist, given an honestly Π ′ (cf. computational zero-knowledge definition, Definition 3.1). By
generated crs, no PPT algorithm can break binding and actually find the argument above, given any hint generated by the PPT adversary
them. Then, even if the adversary knows the value 𝑤 0 , it would not (A1 ) based on 𝑤, the output (vk1, ct1, 𝜋1 ) generated by the simula-
be able to distinguish the encryption of 𝐹 (𝑤 0 ) from the encryption tor cannot be distinguished from a correctly generated output by
of 𝐹 (𝑤 1 ) until the decryption keys for the ciphertexts of 𝐹 (𝑤 0 ) and any PPT distinguisher (A2 ) except with negligible probability. This
𝐹 (𝑤 1 ) are revealed. Since this is true for the adversary that might implies 𝐿-bits zero-knowledge for the VECK protocol Π ′ as well as
know 𝑤 0 , it is also true for the adversary that holds partial infor- the MC-VECK protocols above.
mation about 𝐹 (𝑤 0 ) or 𝑤 0 itself, e.g., a hint based on 𝑤 0 . Now, let □

25