# Cross-Blockchain Communication Using Oracles With an Off-Chain Aggregation
Mechanism Based on zk-SNARKs

Michael Sober<EMAIL_ADDRESS>0000-0002-9612-9022 Hamburg University of
TechnologyBlohmstr. 15HamburgGermany21079 Christian Doppler Laboratory for
Blockchain Technologies for the Internet of ThingsBlohmstr.
15HamburgGermany21079 ,  Giulia Scaffino<EMAIL_ADDRESS>0000-0001-5680-3003 TU WienFavoritenstr. 9ViennaAustria1040 Christian Doppler
Laboratory for Blockchain Technologies for the Internet of ThingsBlohmstr.
15HamburgGermany21079 and  Stefan Schulte<EMAIL_ADDRESS>0000-0001-6828-9945 Hamburg University of TechnologyBlohmstr.
15HamburgGermany21079 Christian Doppler Laboratory for Blockchain Technologies
for the Internet of ThingsBlohmstr. 15HamburgGermany21079

(2024; 20 February 2007; 12 March 2009; 5 June 2009)

###### Abstract.

The closed architecture of prevailing blockchain systems renders the usage of
this technology mostly infeasible for a wide range of real-world problems.
Most blockchains trap users and applications in their isolated space without
the possibility of cooperating or switching to other blockchains. Therefore,
blockchains need additional mechanisms for seamless communication and
arbitrary data exchange between each other and external systems.
Unfortunately, current approaches for cross-blockchain communication are
resource-intensive or require additional blockchains or tailored solutions
depending on the applied consensus mechanisms of the connected blockchains.
Therefore, we propose an oracle with an off-chain aggregation mechanism based
on Zero-Knowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs)
to facilitate cross-blockchain communication. The oracle queries data from
another blockchain and applies a rollup-like mechanism to move state and
computation off-chain. The zkOracle contract only expects the transferred
data, an updated state root, and proof of the correct execution of the
aggregation mechanism. The proposed solution only requires constant 378 kgas
to submit data on the Ethereum blockchain and is primarily independent of the
underlying technology of the queried blockchains.

blockchain, smart contracts, blockchain interoperability, blockchain oracles,
cross-blockchain communication, zero-knowledge proofs

††copyright: acmcopyright††journalyear: 2024††doi: XXXXXXX.XXXXXXX††ccs:
Computer systems organization Distributed architectures††ccs: Computing
methodologies Distributed algorithms††ccs: Security and privacy Cryptography

EVM

    Ethereum Virtual Machine
ZKP

    Zero-Knowledge Proof
DKG

    Distributed Key Generation
VSS

    Verifiable Secret Sharing
PVSS

    Publicly Verifiable Secret Sharing
zk-SNARK

    Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
zk-SNARKs

    Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
zk-STARKs

    Zero-Knowledge Succinct (Scalable) Transparent Arguments of Knowledge
R1CS

    Rank-1 Constraint-System
QAP

    Quadratic Arithmetic Program
VOC

    Verifiable Off-Chain Computation
EVM

    Ethereum Virtual Machine
NIZK

    Non-interactive Zero-Knowledge Proof
TID

    Threshold Information Disclosure
CP-ABE

    Ciphertext-Policy Attribute-Based Encryption
PoS

    Proof of Stake
DPoS

    Delegated Proof of Stake
PoW

    Proof of Work
MPC

    Multiparty Computation
DSL

    Domain-Specific Language
CRS

    Common Reference String
IBC

    Inter-blockchain Communication Protocol
XCM

    Cross-Consensus Message Format
CCIP

    Cross-Chain Interoperability Protocol
OCR

    Off-chain Reporting
dApp

    Decentralized Application
SPV

    Simplified Payment Verification
EdDSA

    Edwards-curve Digital Signature Algorithm
ETH

    Ether
OCR

    Off-Chain Reporting
EUF-CMA

    Existential Unforgeability under Chosen Message Attack

##  1\. Introduction

Blockchains provide a distributed ledger of transactions while ensuring the
integrity, consistency, and immutability of the transactions. Blockchain
technology has been first introduced with Bitcoin (Nakamoto, 2008) and is now
considered the main backing technology of cryptocurrencies. However, it also
found application in various other application areas like healthcare (Agbo et
al., 2019), supply chain management (Saberi et al., 2019), and others (Dai et
al., 2019; Xie et al., 2019; Demestichas et al., 2020). The second generation
of blockchains, like Ethereum (Wood et al., 2014), provides smart contracts,
which are deterministic programs stored on the blockchain executed by every
node of the network. The application of smart contracts allows the creation of
decentralized applications (Cai et al., 2018), opening an even wider range of
possible application areas.

Different application domains of blockchain technology come with different
challenges and requirements. A single blockchain can only fulfill some
criteria, which results in a wide range of solutions tailored to particular
application domains. These development efforts lead to a highly fragmented and
heterogenous blockchain space (Schulte et al., 2019), as different blockchains
often have unique consensus mechanisms, token standards, or smart contract
capabilities. These broad differences make it difficult for different
blockchains to work together and require special attention during development
to ensure an interoperable blockchain landscape. Unfortunately, blockchain
interoperability is a major issue often overseen and hinders blockchain
technology from developing its full potential. Blockchains are usually
considered closed systems that can not interact with external systems. While
exceptions exist, e.g., Hyperledger Cacti (Foundation, 2022), Cosmos (Kwon and
Buchman, 2020), Polkadot (Wood, 2016), and others (Ellul and Pace, 2022),
missing interoperability is still a widespread problem. Amongst other things,
missing interoperability between blockchains leads to vendor lock-in, i.e.,
users can not easily migrate to other blockchains (Belchior et al., 2023).

Further, smart contracts can only manipulate their state on the hosting
blockchain and can not interact with smart contracts deployed on other
blockchains or external systems. Therefore, there is a strong need for
blockchain interoperability solutions to break the barrier between
heterogeneous blockchain systems and enable cross-blockchain communication to
securely transfer arbitrary state information between blockchains in a
decentralized way. The possibility to transfer arbitrary information between
blockchains enables the creation of decentralized cross-blockchain
applications and protocols (Nissl et al., 2021; Robinson and Ramesh, 2021;
Scaffino et al., 2024).

There is an ongoing effort in research and industry to create blockchain
interoperability solutions (Belchior et al., 2021; Wang et al., 2023).
However, current solutions, like blockchain relays, are often very complex to
implement since they depend on the source blockchains’ consensus mechanism. A
blockchain of blockchains solution has even more technical complexity,
requiring an additional blockchain for cross-blockchain communication. On the
other hand, notary schemes offer great flexibility and are mostly independent
of the connected blockchains. Unfortunately, notary schemes exhibit a lower
degree of decentralization (Wang et al., 2023). Many notary schemes follow a
decentralized approach where $n$ out $m$ parties must collaborate to
distribute trust among multiple parties and reach an agreement, e.g., by
applying a voting mechanism. These voting mechanisms require costly on-chain
interactions since the smart contract has to process many votes to determine
the outcome. More cost-efficient solutions use complex off-chain voting
mechanisms, e.g., by applying threshold signatures, to submit an aggregated
result (Sober et al., 2021). However, these solutions require the additional
execution of Distributed Key Generation (DKG) protocols which introduce
additional complexity and security risks (Sober et al., 2023).

Therefore, we propose a solution for cross-blockchain communication by using a
decentralized oracle, i.e., a bridge to an external data source, with an off-
chain aggregation mechanism based on zk-SNARKs. The oracle allows its clients
to query arbitrary information from other blockchains independent of the inner
workings of the source blockchain. A committee of oracle nodes, divided into a
single aggregator and multiple validators, executes an off-chain aggregation
mechanism to attest to the correctness of the retrieved information. The
validators query the source blockchain for the requested information and send
the signed result to the current aggregator. The aggregator combines the
results by generating a Zero-Knowledge Succinct Non-interactive Arguments of
Knowledge (zk-SNARK) to verify the signatures and distribute the rewards off-
chain. Afterward, the aggregator submits the proof, the updated state, and the
queried information to the smart contract. The smart contract must only verify
the proof, update the state, and store the retrieved data. Further, we provide
a prototypical implementation for Ethereum-based blockchains and evaluate it
concerning costs, memory, and performance. The results show that our oracle
only requires 378 kgas to submit data on Ethereum-based blockchains.
Furthermore, oracle nodes without many resources can also use the system and
efficiently support a committee size of 256.

The remainder of this paper is structured as follows: Section 2 provides
general information about the applied concepts. Afterward, Section 3
introduces the design of the oracle with its off-chain aggregation mechanism,
and Section 4 follows with a security analysis. Section 5 provides
implementation details, and Section 6 evaluates the proposed solution
concerning costs, memory, and performance. After that, Section 7 follows with
a discussion of related work. Finally, Section 8 concludes the paper.

##  2\. Background

This section discusses the underlying concepts of the proposed solution. We
provide the basics of cross-blockchain communication and follow with an
explanation of Zero-Knowledge Proofs and rollups.

###  2.1. Cross-Blockchain Communication

Cross-blockchain communication refers to the ability of two blockchains to
reach a consistent state across both blockchains by synchronizing transaction
execution (Wang et al., 2023). Hence, cross-blockchain communication allows
distinct blockchains to transfer arbitrary information, query the state of
another blockchain (Sober et al., 2021) or allow more specific use cases such
as atomic swaps (Herlihy, 2018) and cross-blockchain smart contract calls
(Nissl et al., 2021). Unfortunately, cross-blockchain communication requires a
trusted third party (Zamyatin et al., 2021) since it is otherwise infeasible
for two blockchains to verify each other’s state. However, the ability to
verify the state of other blockchains is a requirement to allow for
interoperable blockchains to exist (Lafourcade and Lombard-Platet, 2020). The
trusted third party must attest to the correct execution of a transaction to
another blockchain, allowing the interdependent execution of transactions on
multiple blockchains. These trusted third parties can both be centralized or
decentralized and most prominently include blockchain relays, notary schemes,
and blockchains of blockchains (Belchior et al., 2021).

A blockchain relay is a smart contract deployed on a target blockchain to
replicate the source blockchain (Belchior et al., 2021). Off-chain clients
continuously relay block headers from the source blockchain to the target
blockchain while the smart contract enforces the consensus rules of the source
blockchain to rebuild the chain. The off-chain clients relaying the block
headers do not need to be trusted since the smart contract enforces the
correct behavior. Further, the smart contract offers light client
functionalities on the target blockchain, allowing smart contracts to query
the state of the source blockchain. Typically, blockchains store a Merkle root
of a block’s transactions in the block header. Hence, the smart contract
allows the execution of Simplified Payment Verification (SPV), which allows
checking if a particular transaction is part of a block while only having the
block header. For that, clients submit a Merkle proof of inclusion to the
relay contract to show that a transaction is part of a specific block.
Further, the relay contract checks that the block containing the transaction
is included in the source blockchain and considered final. Blockchain relays
have a high degree of decentralization but are costly since on-chain block
header verification and storage consume many resources. Additionally, off-
chain clients must always keep the relay in sync with the source blockchain
requiring considerable maintenance effort. However, novel relay solutions
already apply techniques to move computation off-chain by either
optimistically accepting new block headers (Frauenthaler et al., 2020) or
using ZKPs (Xie et al., 2022; Westerkamp and Eberhardt, 2020) to achieve
better cost efficiency.

Another technique for cross-blockchain communication is through the
application of notary schemes (Buterin, 2016). A notary is a trusted entity or
group responsible for executing certain operations across the boundaries of
blockchains. The notary can monitor the involved blockchains, read the
blockchains’ state, and publish new transactions. Therefore, the notary can
function as an oracle to query state information or publish new transactions
on behalf of another blockchain. The blockchains interacting with the notary
must only authenticate the notary to verify the integrity and authenticity of
the executed operations. Notary schemes are a relatively simple solution for
cross-blockchain communication since they are independent of the underlying
blockchains and offer great flexibility. However, notary schemes exhibit a
lower degree of decentralization. Trusting only a single entity leads to a
single point of failure, which can compromise the whole system. Therefore,
many solutions require that $n$ out of $m$ entities agree by executing a
voting mechanism, either on-chain or off-chain, to distribute the trust among
multiple entities (Sober et al., 2021). Further, these approaches require
additional mechanisms to form a committee of trustworthy entities and reach an
agreement.

Multiple blockchains can also communicate by following a blockchain of
blockchains approach (Wang et al., 2023). A blockchain of blockchains provides
a platform of independent subchains to communicate with each other through a
central relay chain. The main chain is responsible for recording the connected
subchains’ actions. Every subchain can access the main chain to verify the
activities of other subchains to implement cross-blockchain communication. The
subchains can work independently of the main chain (Kwon and Buchman, 2020) or
adopt a shared security approach where validators of the main chain also
validate the subchains (Wood, 2016). The main chain is, to a certain extent, a
notary scheme with the properties of a blockchain, as it attests to the
actions of the subchains. However, in many cases, it also fulfills other
purposes besides cross-blockchain communication. Unfortunately, there is also
a considerable overhead to using an additional blockchain to keep track of all
connected chains.

###  2.2. Zero-Knowledge Proofs

ZKPs were first introduced by Goldwasser et al. (Goldwasser et al., 2019) to
enable a prover to convince a verifier that the prover knows a witness to a
particular statement without revealing any additional knowledge. For that, a
ZKP system has to satisfy the following three properties (Groth, 2016):

  1. (1)

Completeness: An honest prover can always convince an honest verifier that the
prover knows a witness to a true statement.

  2. (2)

Soundness: A malicious prover can not convince an honest verifier about the
knowledge of a witness to a false statement.

  3. (3)

Zero-knowledge: A verifier does not learn additional information besides the
statement’s validity.

However, these proof systems require multiple interactions between the prover
and the verifier to communicate the proof and convince the verifier.
Therefore, Blum et al. (Blum et al., 2019) introduced non-interactive ZKP
systems as an alternative to interactive proof systems. These non-interactive
proof systems require an initial setup phase in which a prover and a verifier
generate and share a common reference string that replaces the previously
necessary interactions. After that, a prover can generate a Non-interactive
Zero-Knowledge Proof (NIZK) to convince the verifier, while the verifier does
not have to send any messages to the prover. Further, Goldreich et al.
(Goldreich et al., 1991) showed that all statements in $\mathcal{NP}$ have
ZKPs, enabling the possibility of verifying arbitrary computations. Verifying
computational integrity allows a verifier to check whether the output of a
given program, given its inputs, is correct without re-executing the program
itself (Gennaro et al., 2010; Parno et al., 2012). These properties are
particularly advantageous in decentralized systems (e.g., blockchains) where
provers cannot directly communicate with verifiers (e.g., smart contracts) or
want to convince several verifiers.

Nowadays, ZKPs are heavily applied in blockchain technology to create scalable
(Thibault et al., 2022) and privacy-aware solutions (Almashaqbeh and Solomon,
2022). Blockchains require every node in the network to execute and verify
transactions which constitutes a major scalability issue. However, applying
ZKPs makes it possible to move computations off-chain such that nodes only
need to verify small proofs, reducing the overall network load and increasing
throughput (see Section 2.3). Further, most blockchains only provide
pseudonymity instead of anonymity, allowing anyone to link multiple addresses
to the same identity by applying heuristics for address clustering (Zhang et
al., 2020). With the application of ZKPs, it is possible to break the link
between multiple addresses and create privacy-preserving blockchains (Ben-
Sasson et al., 2014a; Hopwood et al., 2016).

The main ZKP proof systems applied are zk-SNARKs (Ben-Sasson et al., 2014b),
Zero-Knowledge Succinct (Scalable) Transparent Arguments of Knowledge (zk-
STARKs) (Ben-Sasson et al., 2019), and Bulletproofs (Bünz et al., 2018). These
proof systems differ in their underlying cryptographic assumptions,
complexity, and the necessity of a trusted setup. The basic cryptographic
assumptions behind zk-SNARKs are the hardness assumption of the elliptic curve
discrete logarithm problem and the existence of secure bi-linear pairings.
While the proving complexity of zk-SNARKs is quasi-linear, the verification
and communication complexity is constant. Unfortunately, zk-SNARKs require a
trusted setup phase to generate a Common Reference String (CRS). The
construction of zk-STARKs, on the other hand, is based upon collision-
resistant hash functions, requiring no trusted setup and having quasi-linear
proving complexity but a poly-logarithmic verification and communication
complexity. Finally, Bulletproofs rely on the discrete log assumption and
require no trusted setup but have quasi-linear proving complexity, linear
verification complexity, and logarithmic communication complexity. In the work
at hand, we use zk-SNARKs to take advantage of the constant verification and
communication complexity, which is particularly beneficial for verifying
proofs with smart contracts.

The first protocol enabling efficient zk-SNARK constructions was the Pinocchio
protocol (Parno et al., 2016; Ben-Sasson et al., 2014b). After that, protocols
like Gepetto (Costello et al., 2015) and Groth16 (Groth, 2016) further
improved the efficiency of zk-SNARKs, and recent works introduced zk-SNARKs
with a universal setup (Gabizon et al., 2019; Maller et al., 2019; Chiesa et
al., 2020). However, Groth16 is still heavily used in blockchain technology
due to its small proof size and low verification complexity. Hence, we apply
Groth16 to create the off-chain aggregation mechanism. The protocol allows the
creation of zk-SNARKs for arithmetic circuits. For that, a program is
translated into an arithmetic circuit, which is converted to a Rank-1
Constraint-System (R1CS). Finally, the R1CS is converted to a Quadratic
Arithmetic Program (QAP), representing the program in a different format to
generate the proof. The input to the program also yields the corresponding
witness to the QAP. After that, the setup produces a CRS and a simulation
trapdoor. The simulation trapdoor needs to be forgotten because it allows the
creation of fake proofs. However, by using Multiparty Computation (MPC), it is
possible to distribute the trust among multiple parties (Bowe et al., 2017).
Finally, the algorithm can use the CRS to create pairing-based zk-SNARKs for
the witness to the QAP.

###  2.3. Rollups

Blockchain technology faces a considerable scalability issue since blockchains
can not cope with the growing amount of work (Zhou et al., 2020). Research has
already come up with various solutions, including improvements to Layer-1,
i.e., the base layer of the protocol, and Layer-2 protocols which build on top
of a blockchain (Hafid et al., 2020). Rollups are a Layer-2 blockchain scaling
solution to increase the throughput of blockchains by moving transaction
computation and state off-chain (Thibault et al., 2022). Aggregators execute
multiple transactions off-chain and only submit state changes and a bundle of
compressed transaction data to the blockchain, i.e., the nodes on Layer-1
solely need to execute a single transaction. A smart contract manages the
state root of the rollup and allows anyone to submit a bundle of compressed
transactions, the previous and the new state root. The corresponding Merkle
tree to the state root contains the account data (e.g., balance, nonce) of the
different accounts which are part of the rollup. Users can deposit and
withdraw funds directly by interacting with the smart contract.

Rollups have to enact specific rules to determine the validity of the
submitted transaction data and the according state changes. Currently, two
main types of rollups exist: optimistic and zk-rollups (Buterin, 2021).
Optimistic rollups (Kalodner et al., 2018) assume that transactions are valid
and allow users to submit fraud proofs (Al-Bassam et al., 2018) during a
dispute period to prove a transaction is invalid. The smart contract verifies
the proof and reverts the rollup to its previous state. With zk-rollups, on
the other hand, users submit validity proofs (e.g., zk-SNARKs) to prove the
correctness of the new state root resulting from the execution of the
transactions in the bundle. Therefore, zk-rollups do not require a dispute
period and enable instant transaction finality.

The availability of the compressed transaction data on Layer-1 ensures that
anyone can recompute and verify the state of the rollup. While zk-rollups only
require minimal transaction data on Layer-1 to ensure that anyone can
recompute and verify the state, optimistic rollups require additional data to
enable the verification of fraud proofs. Therefore, even with malicious actors
in the system, rollups can provide censorship resistance and liveness.

Moving transaction computation and state off-chain is a promising approach to
improve aggregation mechanisms that require many interactions with a smart
contract or other tools (e.g., threshold signatures) to reduce on-chain
computation. Hence, in the following, we apply the concept behind zk-rollups
to create an off-chain aggregation mechanism.

##  3\. System Design

In this section, we propose a cross-blockchain communication mechanism using
oracles with an off-chain aggregation mechanism based on zk-SNARKs. Initially,
we provide a short overview of the system. Afterward, we discuss dynamic
participation and the applied incentive mechanism. Finally, we define the off-
chain aggregation mechanism.

###  3.1. Overview

Figure 1. Overview of the system

An oracle is a bridge between a blockchain and an external data source. The
typical architecture for an oracle system consists of an on-chain component,
e.g., a smart contract, and an off-chain component. The off-chain component
retrieves data from external data sources, e.g., another blockchain, ensures
the data’s integrity, and submits the data to the oracle contract (Heiss et
al., 2019). The oracle contract receives the data and serves it to data
consumers. There are different types of oracles based on the data source,
trust level, communication direction, and data type (Al-Breiki et al., 2020).
However, this work focuses on cross-chain oracles to enable blockchain
interoperability and data transfer between distinct blockchains. These oracles
represent a flexible and lightweight solution for cross-blockchain
communication as they do not depend on the source blockchain’s consensus
mechanism and require no additional blockchain. Hence, the proposed oracle
solution is compatible with different blockchains, assuming the connected
blockchains support smart contracts.

The oracle (see Fig. 1) allows arbitrary data transfer between two blockchains
by enabling the oracle’s clients to issue requests to query data from another
blockchain. The system consists of the zkOracle contract deployed on a target
blockchain and off-chain oracle nodes, which query data from a source
blockchain and attest to the data’s integrity. The zkOracle contract offers a
mechanism for dynamic participation (see Section 3.2) that allows anyone to
register and join a committee of oracle nodes. This committee collectively
responds to requests by querying another blockchain and executing an off-chain
aggregation mechanism (see Section 3.4) before returning the data. The oracle
selects a single aggregator responsible for aggregating the results from the
committee members. The other committee members act as validators by querying
the data from the source blockchain and attesting to the correctness. The
aggregator collects a majority of answers with the same result and creates an
aggregated result in a rollup-like fashion. For that, the aggregator generates
a zk-SNARK proving that the majority voted for a specific answer and that the
rewards are distributed correctly. By generating this proof, the oracle can
execute the voting mechanism and reward distribution off-chain, while the
smart contract only needs to verify the proof to ensure the correctness of
these computations.

Additionally, the oracle applies an incentive mechanism (see Section 3.3) to
reward honest behavior and punish misbehavior. While honest nodes
participating in the aggregation protocol receive a constant reward to
compensate them for providing resources, misbehaving nodes may get slashed and
lose part or all of their deposited collateral. The aggregator slashes
misbehaving oracle nodes by generating a zk-SNARK that the oracle node in
question provided an answer that differs from the majority. Upon receiving the
aggregated result, the zkOracle contract only verifies the zk-SNARK, stores
the result, and updates the Merkle root containing the state of all oracle
nodes. Afterward, any other smart contract can access the data retrieved from
the source blockchain by calling the zkOracle contract.

###  3.2. Dynamic Participation

The oracle relies on a committee of oracle nodes with a maximum size of $n$
nodes to collectively return the result to a query. However, the oracle can
already operate with less than $n$ nodes as long as $\frac{n}{2}+1$ nodes are
honest. For that, the system provides a mechanism for dynamic participation,
allowing anyone to register oracle nodes and participate in transferring data
between two blockchains. The mechanism enables any oracle node to join or
leave the system by calling the zkOracle contract deployed on the target
blockchain. Further, the mechanism provides high Sybil resistance by following
a Proof of Stake (PoS) mechanism to select the committee. While other
mechanisms like using a pre-defined set of participants or a first come, first
served approach are also possible, they suffer from Sybil attacks (Douceur,
2002) and a lower degree of decentralization.

Initially, the zkOracle contract has no registered oracle nodes. Anyone can
call the zkOracle contract and register an oracle node providing a public key,
IP address, and stake in the blockchain’s native currency. The zkOracle
contract uses a Merkle Tree to store the accounts of registered oracle nodes
consisting of an address, index, public key, and the stake balance. Therefore,
the zkOracle contract does not store raw account data, and the off-chain
aggregation protocol can update the Merkle root to apply state changes
resulting in considerable cost savings. The zkOracle contract only allows up
to $n$ oracle nodes providing a minimum stake to register. After the
registration of $n$ oracle nodes, it is only possible for a new oracle node to
join if it provides a higher stake than the oracle node it wishes to replace.
The zkOracle contract enables anyone to provide a public key, a higher stake
than a specific oracle node, and the respective Merkle proof to replace the
node. With this approach, the zkOracle contract ensures that the committee of
oracle nodes always consists of the $n$ nodes with the highest deposited
stake.

Additionally, registered oracle nodes can also leave the system. Leaving the
system requires two steps: exit and withdraw. First, an oracle node calls the
zkOracle contract to announce that it wants to exit the system by providing
the necessary account details with the respective Merkle proof. The zkOracle
contract ensures that the caller is the rightful owner of the account, the
validity of the Merkle proof, and computes the time an oracle node has to wait
until it is allowed to withdraw. The exit time ensures that users with a high
enough stake can not repeatedly remove other oracle nodes with a lower stake
from the system by replacing the node and immediately leaving the system to
replace other nodes. Without the exit time, anyone with a high enough stake
could remove all nodes with a lower stake and replace these oracle nodes with
new oracle nodes that do not require a high stake. After reaching the exit
time, an oracle node can provide its account details with the corresponding
Merkle proof to withdraw its stake from the zkOracle contract. Finally, the
zkOracle contract transfers the stake and replaces the account in the Merkle
tree with an empty account.

###  3.3. Incentive Mechanism

The proposed oracle solution is a public system allowing anyone to register
oracle nodes cooperating to transfer data between blockchains. However,
without an incentive, there is no reason for anyone to participate in the
system since participation requires resources. Therefore, the oracle applies
an incentive mechanism that encourages participation and honest behavior and
discourages malicious behavior. For that, every oracle node, whether acting as
an aggregator or a validator, receives a monetary reward for submitting a
result to the zkOracle contract. On the other hand, the zkOracle contract
punishes misbehaving nodes by slashing the deposited stake.

The aggregator and validators receive a monetary reward for each submission.
This reward can be constant, or the zkOracle contract can dynamically define
the amount. However, dynamically determining the reward requires additional
public inputs to the aggregation circuit, which increases the verification
costs. The oracle distributes these rewards during the off-chain aggregation
mechanism. The aggregator increases its balance and the balance of every
validator submitting a valid result and signature by the defined reward. The
rewards of the aggregator need to be higher than the validator rewards since
the aggregator has to provide a lot more computational power to generate the
zk-SNARK during the execution of the off-chain aggregation mechanism and also
has to pay the transaction fees for submitting the final result to the
zkOracle contract.

The aggregator assigns the rewards during off-chain aggregation and proves
that it assigned the correct rewards to the involved participants with the
generated zk-SNARK. The zkOracle contract only needs to verify the proof and
store the updated Merkle root, which contains the account information with the
updated balances. Therefore, the system provides a fair and cost-efficient
approach to reward every participant without relying on multiple on-chain
interactions or relying on game theoretical approaches to distribute the
rewards.

An aggregator selects only a majority of responses to create aggregated
results. This selection process allows it to potentially exclude a minority of
validators from receiving rewards. As a result, resources are wasted even
though the validators’ tasks are not very resource-intensive. Nevertheless,
the oracle eventually appoints each validator as an aggregator, enabling them
to earn rewards. This mechanism results in a trade-off between the fees
clients pay to use the oracle and the fair distribution of rewards among
validators since clients must pay for each validator submitting an answer.

###  3.4. Off-Chain Aggregation

Figure 2. Sequence of interactions for retrieving data

The off-chain aggregation mechanism (see Fig. 2) allows the oracle nodes to
return aggregated results to the zkOracle contract while reducing the number
of on-chain operations to a minimum. During the execution of this mechanism, a
majority of oracle nodes query data from another blockchain and have to agree
on the result. The system follows the same principle as blockchain rollups by
moving computation and state storage off-chain. However, instead of rolling up
transactions, the system bundles votes on queried data from another
blockchain. The aggregator verifies the votes and changes the balances of
committee members based on their participation during the execution of the
aggregation mechanism. The aggregator only submits a zk-SNARK, the query
result, and the updated Merkle tree with the account information to the
zkOracle contract. Hence, the aggregation mechanism requires only minimal
computational and storage resources from the blockchain reducing the overall
costs while maintaining decentralization.

Initially, a client of the zkOracle contract has to issue a request by calling
the getBlockByNumber function of the zkOracle contract (Step 1) providing the
block number of a requested block and the necessary rewards for the oracle
nodes executing this request. The zkOracle contract assigns the request a
unique ID and stores it. Depending on the blockchain, the oracle nodes have to
query the blockchain to check for any pending requests continuously, or the
blockchain emits an event to notify the oracle nodes (Step 2).

After getting the information about a pending request, the oracle nodes use
the getAggregator function of the zkOracle contract to determine their current
role. The zkOracle contract supports different approaches for selecting the
current aggregator. An efficient strategy is to adopt a round-robin method for
organizing each oracle node to serve as an aggregator for a specific time
interval until switching to the next aggregator. This approach prevents races
between multiple aggregators for aggregating results, which wastes resources
and incurs additional costs for interacting with the zkOracle contract since
only one submission would be successful. Another possibility would be for the
zkOracle contract to randomly choose the next aggregator, making it harder for
adversaries to attack specific aggregators upfront. However, this approach
requires the computation of a random seed using an additional secret input for
the aggregation mechanism and a timeout to account for malicious aggregators
not providing an answer. In this case, the aggregator rotates after every
block submission or after reaching the timeout.

The validators query the source blockchain (Steps 3 and 4) to retrieve the
block with the specified number and check if the block is final. Therefore,
the validators need to check that such a block exists and that at least $n$
blocks confirm it in the case of blockchains with probabilistic finality. For
blockchains with immediate finality, waiting for $n$ confirmations is
unnecessary. Ignoring the finality of blocks can result in validators
returning a wrong result due to possible forks in the source blockchain. If a
validator determines that such a block does not exist or is not final, it
responds with a zero value as the block hash. A validator creates a vote
consisting of the validator’s ID, the request number, and the hash of the
retrieved block. After that, a validator signs the vote using its private key
and retrieves the current aggregator’s IP address from the zkOracle contract.
Hence, an aggregator can not forge an invalid vote. A validator establishes a
direct channel with the aggregator and sends the vote with the according
signature to the aggregator (Step 5).

Upon receiving a vote from a validator, the aggregator verifies the vote and
stores it in the aggregator’s mempool. The aggregator considers a vote to be
valid if the signature is valid. After receiving a majority of valid votes
with the same result for a specific request, the aggregator starts the
aggregation process. During this process, the aggregator has to execute the
aggregation mechanism locally and construct the witness for the aggregation
circuit to generate the zk-SNARK, proving that the submitted result and
applied state changes are correct (Step 6). The zk-SNARK ensures that an
aggregator can only perform the correct aggregation algorithm based on the
votes received from the validators and submit the majority answer.

Algorithm 1 Aggregation Circuit

1:function aggregate($preStateRoot$, $postStateRoot$, $blockHash$, $request$,
$validatorBits$, $a$, $validators$)

2: for $i<numAccounts$ do

3: for $j<numAccounts$ do

4: if $i=j$ then

5: continue

6: end if

7: $assert(validators[i].index\neq validators[j].index)$

8: end for

9: end for

10: $verifyMerkleProof(preStateRoot,a.MerkleProof)$

11: $a.balance\leftarrow a.balance+reward$

12: $a.MerkleProof[0]\leftarrow
hash(a.index,a.publicKeyX,a.publicKeyY,a.balance)$

13: $intermediateRoot\leftarrow computeRootFromPath(a.MerkleProof)$

14: $actualValidatorBits\leftarrow 0$

15: for all $v\in validators$ do

16: $verifyMerkleProof(intermediateRoot,v.MerkleProof)$

17: $msg\leftarrow hash(v.index,request,blockHash)$

18: $verifySignature(v.signature,v.publicKey,msg)$

19: $assert(v.blockHash==blockHash)$

20: $v.balance\leftarrow v.balance+reward$

21: $actualValidatorBits\leftarrow actualValidatorBits+2^{v.index}$

22: $v.MerkleProof[0]\leftarrow
hash(v.index,v.publicKeyX,v.publicKeyY,v.balance)$

23: $intermediateRoot\leftarrow computeRootFromPath(v.MerkleProof)$

24: end for

25: $assert(actualValidatorBits=validatorBits)$

26: $assert(intermediateRoot=postStateRoot)$

27:end function

The aggregator executes a program (see Alg. 1) compiled into an arithmetic
circuit for zk-SNARK construction to aggregate the votes. The aggregation
circuit expects the previous state root, the resulting state root, the
expected block hash, the request number, and the validator bit vector as
public inputs. The aggregation circuit also requires private inputs, including
the account information of the aggregator and validators with the respective
Merkle proofs. Additionally, the private inputs contain the signatures and
returned block hashes from the validators.

Initially, the aggregator must ensure no multiple votes from the same
validator. For each request, a validator only has one vote. For that, the
aggregator iterates over all submitted votes and checks that the validator
index does not match another vote’s validator index (Lines 2-9). After that,
the aggregator checks that the Merkle tree includes the account of the
aggregator (Line 10) and increases its balance by the specified reward (Line
11). After increasing the balance, the aggregator computes an intermediate
state root reflecting the change in the aggregator’s balance (Lines 12-13).
Subsequently, the aggregator processes the submitted votes from the
validators. For each vote, the aggregator checks if the Merkle tree includes
the validator’s account (Line 16) and hashes the vote to construct the message
(Line 17). Then, the aggregator verifies the signature provided by the
validator by using the validator’s public key and the message (Line 18). After
verifying that the validator is part of the system and provided an
authenticated vote, the aggregator checks if the block hash provided by the
validator matches the expected block hash provided by the majority of
validators (Line 19).

The aggregator also adds the reward to the validator’s balance (Line 20) and
updates a bit vector indicating which validators voted for the result to
ensure data availability. A bit value of 1 at a specific position shows that
the validator with this index contributed to the result. In contrast, a bit
value of 0 shows that the respective validator did not participate. The
aggregator flips the bits at the respective position by adding $2^{v.index}$
to the validatorBits (Line 21). Otherwise, the other oracle nodes cannot
synchronize the state without knowing which state changes are necessary since
the aggregator only submits the updated Merkle root. Then, the aggregator
computes a new intermediate root reflecting the state changes for the
validator’s account (Lines 22-23). Finally, after repeating this process for
each validator, the aggregator checks if the validatorBits match the provided
validatorBits (Line 25) and if the intermediate root equals the provided post-
state root (Line 26).

After creating the witness and the public inputs for the aggregation circuit,
the aggregator generates the zk-SNARK to submit the aggregated result. The
aggregator calls the $submitBlock$ function of the zkOracle contract (Step 7),
providing the request number, block hash, validators bit vector, updated state
root, and zk-SNARK. Initially, the zkOracle contract verifies that the
transaction sender is the current aggregator, and the request is still
pending. After that, the zkOracle contract verifies the submitted zk-SNARK
(Step 8), updates the state root, and stores the block hash. Finally, the
zkOracle contract notifies the client about the submission (Step 9), and
clients can query the zkOracle contract for the block hash to use it for SPV.

After successfully submitting an aggregated result to the zkOracle contract,
the aggregator executes a program (see Alg. 2) to process invalid votes and
slash misbehaving validators (Step 10). The aggregator considers a vote
invalid if the hash of the retrieved block differs from the majority answer to
a certain request of the other validators. The slashing circuit expects the
same inputs as the aggregation circuit, except that the slashing circuit only
expects a single validator account with the submitted signature and block
hash. Further, the indices of the aggregator and the validator need to be
public inputs to ensure data availability.

Initially, the aggregator verifies the inclusion of the validator’s account in
the Merkle tree (Line 2). After that, the aggregator computes the message
(Line 3) and verifies the signature provided by the validator (Line 4). In the
next step, the aggregator sets the validator’s balance to 0 (Line 5) and
computes the new state root (Lines 6-7). The aggregator verifies the inclusion
of the aggregator’s account in the Merkle tree (Line 8), adds the deducted
balance to its account (Line 9), and also computes the new state root (Lines
10-11). Further, the aggregator checks that the block hash provided by the
validator is different from the block hash provided by the majority of
validators (Line 12) and that the computed state root matches the provided
post-state root (Line 13). Finally, the aggregator calls the $slash$ function
of the zkOracle contract (Step 11) and provides the proof, the aggregator and
validator indices, the request number, and the post-state root. The zkOracle
contract verifies that the request is not pending, verifies the proof, and
stores the updated state root (Step 12).

Algorithm 2 Slashing Circuit

1:function slash($preStateRoot$, $postStateRoot$, $blockHash$, $request$, $a$,
$v$)

2: $verifyMerkleProof(preStateRoot,v.MerkleProof)$

3: $msg\leftarrow hash(v.index,request,blockHash)$

4: $verifySignature(v.signature,v.publicKey,msg)$

5: $v.balance\leftarrow 0$

6: $v.MerkleProof[0]\leftarrow
hash(v.index,v.publicKeyX,v.publicKeyY,v.balance)$

7: $intermediateRoot\leftarrow computeRootFromPath(v.MerkleProof)$

8: $verifyMerkleProof(intermediateRoot,a.MerkleProof)$

9: $a.balance\leftarrow a.balance+v.balance$

10: $a.MerkleProof[0]\leftarrow
hash(a.index,a.publicKeyX,a.publicKeyY,a.balance)$

11: $intermediateRoot\leftarrow computeRootFromPath(a.MerkleProof)$

12: $assert(blockHash\neq v.blockHash)$

13: $assert(postStateRoot=intermediateRoot)$

14:end function

##  4\. Security Analysis

This section provides a security analysis of our oracle solution. Initially,
we clarify assumptions and the adversarial model. Then, we define the required
security properties and show that our solution fulfills all these properties.
Finally, we discuss Sybil-resistance and the adversarial bound.

#### Cryptographic Assumptions

We assume that zk-SNARKs have perfect completeness, soundness, and zero-
knowledge (Groth, 2016). Further, we consider hash functions modeled as random
oracles (Bellare and Rogaway, 1993) and digital signature schemes having
Existential Unforgeability under Chosen Message Attack (EUF-CMA) security
(Goldwasser et al., 1988).

#### System Assumptions

We assume that, at any point in time, there is an honest majority of oracle
nodes. Further, we assume that the communicating blockchains provide safety
and liveness guarantees.

#### Adversarial Model and Security Properties

We assume a computationally-bound static adversary $\mathcal{A}$ that can
corrupt a fixed number of oracle nodes prior to the execution of the protocol.
However, depending on the committee’s maximum size, $\mathcal{A}$ can only
corrupt a minority of oracle nodes. The oracle possesses the following
security properties:

###### Definition 0 (Oracle Safety).

An oracle is safe if, for any request made on a destination chain $bc_{dest}$
by a client $c$ with respect to a source chain $bc_{src}$, it provides a
correct answer to $bc_{dest}$. A correct answer to $bc_{dest}$ includes the
requested data included and confirmed with overwhelming probability in
$bc_{src}$.

###### Definition 0 (Oracle Liveness).

An oracle is live if, for any request made on a destination chain $bc_{dest}$
by a client $c$ with respect to a source chain $bc_{src}$, it eventually
provides an answer to $bc_{dest}$.

###### Theorem 4.3.

Our zkOracle is secure, i.e., it is safe and live.

###### Proof.

Towards contradiction, suppose our zkOracle is not secure. For this to happen,
it means that there was a point in time where (i) the oracle provided
$bc_{dest}$ with an incorrect answer, or (ii) the oracle did not provide an
answer to a request.

In case (i), for the oracle to provide an incorrect answer, it means that
either a majority of nodes were adversarial, i.e., they voted on an incorrect
answer, or that the properties of the cryptographic primitives used by the
oracle have been broken, i.e., the aggregator successfully forged an invalid
proof or validator signatures, or that either $bc_{src}$ or $bc_{dest}$ are
not secure. This contradicts our cryptographic and system assumptions.

In case (ii), for the oracle to not provide an answer, it means that either
none of the aggregators ever submits a valid answer, not enough signatures are
produced by the nodes in the committee, or that either $bc_{src}$ or
$bc_{dest}$ are not secure. This contradicts our system assumptions. ∎

#### Sybil-Resistance and Adversarial Bound

We note that the staking requirement for nodes joining the oracle provides
sybil-resistance as well as the lower bound on the stake for the adversary to
pull an attack against the oracle successfully.

The oracle requires each oracle node $o_{i}$ joining the committee $C$ with a
maximum size of $n$ nodes to deposit a stake $s_{i}\geq s_{min}$ where
$s_{min}$ is the configurable minimum stake required to join $C$. The amount
depends on the number of registered oracle nodes $|C|$. Hence, if $|C|<n$, the
committee is not full and $s_{i}\geq s_{min}$. However, if $|C|=n$, i.e., the
committee is already full, $o_{i}$ can only join $C$ by replacing another node
$o_{j}\in C$ if $s_{i}>s_{j}$. For the oracle to submit an answer, it requires
a majority $t=\frac{n}{2}+1$ of oracle nodes to attest to the correctness of
the transferred data and generate a valid proof. Hence, an adversary
$\mathcal{A}$ needs to have more stake than the majority of registered oracle
nodes with the lowest deposited stake $C_{P}=min_{t}(C)$ which have a
cumulative stake $s_{P}=\sum_{o_{i}\in C_{P}}s_{i}$. Therefore, $s_{P}$ is a
lower bound on the required adversary’s stake $s_{\mathcal{A}}$, i.e.,
$s_{\mathcal{A}}>s_{P}$ to break the oracle’s security successfully.

The requirement for oracle nodes to deposit a substantial stake not only
increases their investment in the system’s integrity but also elevates the
economic cost of attempting to join $C$ with multiple identities. This
requirement ensures nodes are incentivized to maintain their position within
the committee, as losing their place means forfeiting potential future
rewards. Hence, this mechanism effectively raises the barriers against Sybil
attacks, safeguarding the system’s decentralization and security.

##  5\. Implementation

In this section, we discuss the implementation details of the different smart
contracts and the node software. Further, we provide the prototypical
implementation as open-source software directly available on
GitHub111https://github.com/soberm/zkOracle.

###  5.1. Smart Contracts

We implemented the smart contracts for the Ethereum smart contract and
Decentralized Application (dApp) platform using Solidity. There are several
reasons for using Ethereum to host the smart contracts of the proposed
solution. Ethereum is currently the largest smart contract platform and,
therefore, also comes with a rich ecosystem and huge community. Further,
Ethereum provides the necessary smart contract capabilities and pre-compiled
contracts, i.e., more efficient contracts, since they do not incur additional
overhead using the Ethereum Virtual Machine (EVM). These pre-compiled
contracts are part of the Ethereum client software and allow, among other
things, the efficient verification of zk-SNARKs using the altbn128 curve,
which is a necessary prerequisite to implement the proposed solution. Many
blockchains also use the EVM and support the implemented smart contracts
without requiring changes. These reasons render Ethereum the most viable
solution for implementing the prototype. Further, porting or implementing the
solution to other smart contract platforms that do not use the EVM is also
possible. However, these platforms must bring the necessary smart contract
capabilities and allow efficient elliptic curve pairing checks.

The zkOracle contract inherits an additional smart contract implementing a
sparse Merkle tree to store the accounts since inserting new data is easier.
The zkOracle contract applies MiMC (Albrecht et al., 2016) for hashing the
data, an arithmetization-friendly hash function optimized for modular
arithmetic in a finite field. Therefore, the oracle nodes can efficiently
compute all operations regarding the Merkle tree inside an arithmetic circuit.
Using arithmetization-friendly hash functions is necessary to minimize
resource consumption during proof generation. Further, the oracle randomly
chooses the next aggregator by adding a random elliptic curve point as an
additional public input to the aggregation circuit. The aggregator computes
the next seed during the aggregation mechanism by multiplying the seed with
its private key. The zkOracle contract uses an exit time of seven days to
ensure misbehaving clients can not arbitrarily remove other oracle nodes from
the committee. For that, the zkOracle contract retrieves the current block
time stamp and adds a seven-day delay. For the verification of the zk-SNARKs,
we use two additional verifier contracts, which are automatically generated
with the help of the gnark zk-SNARK library (Botrel et al., 2023), also used
by the provided client software. These generated contracts use a pre-compiled
contract by Ethereum to compute elliptic curve pairings to verify the
submitted proofs.

###  5.2. Client

We implemented the client software for the oracle nodes using the
Go222https://go.dev/ programming language. The client software uses
automatically generated contract bindings to interact with the smart contracts
to avoid boilerplate code and to enable seamless interaction. For
communication, the oracle nodes use gRPC333https://grpc.io/ to establish
point-to-point channels, with the current aggregator offering an RPC API for
validators to submit their votes. The client software allows each oracle node
to act as an aggregator and a validator.

Each oracle node has to store and continuously synchronize the state of the
zkOracle contract. For that, an oracle node stores the raw state in memory and
listens to all events which indicate state changes, i.e., changes to the
accounts stored in the Merkle tree. These events include registering,
replacing, and withdrawing oracle nodes and submitting results or validator
slashing. The oracle node needs to execute the state changes in the correct
order and to update its locally stored state. Newly joined oracle nodes
synchronize their state by starting from the beginning, i.e., the deployment
time of the zkOracle contract and executing all state changes based on the
persisted events. Further, oracle nodes that went offline must synchronize
their state from the last known state change. Optimizations are still
possible, whereby oracle nodes download the state of already synchronized
oracle nodes and verify that the root matches the root of the zkOracle
contract.

The validators listen for BlockRequested events on the target blockchain to
start the validation process. These events include a request number and the
corresponding block number. After receiving a BlockRequested event, a
validator uses the JSON-RPC client to connect to an Ethereum node and retrieve
the block with the given block number. Then, a validator uses a predefined
threshold to determine the finality of the retrieved block. Afterward, a
validator creates the vote and signs it using Edwards-curve Digital Signature
Algorithm (EdDSA). The applied EdDSA does not use Curve25519 (Bernstein, 2006)
as the aggregator verifies the signature in an arithmetic circuit using
modular arithmetic over a different field. Therefore, the validator uses EdDSA
with a twisted Edwards curve defined over the same field as the arithmetic
circuit (Bellés-Muñoz et al., 2021). Further, a validator uses the MiMC hash
function to create the message to be signed. Finally, the validator calls the
zkOracle contract to retrieve the current aggregator with its IP address and
sends the signed vote to the current aggregator using gRPC. While this
implementation only supports Ethereum-based source blockchains, it is easily
possible to support other blockchains by simply switching the client of the
source blockchain and defining a new strategy to determine the finality of a
block.

The aggregator receives votes from the validators and stores the votes in its
in-memory mempool until reaching a majority of votes with the same result.
Afterward, the aggregator fetches the state and constructs the witness for the
aggregation circuit created with the gnark zk-SNARKs library. For generating
the proof, the aggregator uses the Groth16 proving scheme and transforms the
proof to the respective format for the verifier contract.

##  6\. Evaluation

After providing the implementation details, we use the prototypical
implementation to evaluate the proposed solution. Initially, we conduct
several experiments to measure the costs of using smart contracts. Afterward,
we examine the performance and memory requirements for generating the proofs.

###  6.1. Experimental Setup

We perform the experiments on a machine equipped with an Intel Core i7-10510U
CPU running Ubuntu 20.04.6 using 8 cores with a clock speed of 1.80 GHz. The
machine has 16GB LPDDR3 RAM with a frequency of 2133 MHz and a 2 TB SSD. We
deploy the smart contracts on a local Ethereum blockchain using HardHat
Network 2.11.1. After deploying the smart contracts, we execute each function
of the zkOracle contract to measure the gas costs. To measure the proof
generation time and memory consumption, we simulate a committee of oracle
nodes responding to requests. After every 50th measurement, we double the
committee size and repeat the experiment until the committee size is 256. The
program’s source code for simulating the oracle nodes and measuring the proof
generation time and memory consumption is again available on GitHub.

###  6.2. Costs

48163264128256$0$$0.5$$1$$\cdot 10^{6}$Committee
SizeGasgetBlockByNumbersubmitBlockslashregisterreplaceexitwithdraw

Figure 3. Gas consumption of the zkOracle contract’s functions

The Ethereum network uses gas as a unit of measurement to quantify the
computational effort and storage space for executing transactions. Every user
issuing a transaction has to pay transaction fees using Ether (ETH) based on
the amount of gas spent to execute the transaction. This mechanism serves as
the basis for incentivizing block producers and validators to spend resources
on operating and securing the network. It also helps to manage and protect the
network’s resources from misuse. The costs are an essential aspect to pay
attention to when designing and developing decentralized applications since
the costs determine a considerable part of the practical applicability of a
solution since users have to pay for every interaction and reason whether the
benefits outweigh the costs. Therefore, we examine the gas consumption of the
register, replace, exit, withdraw, getBlockByNumber, submitBlock, and slash
functions implemented by the zkOracle contract.

The results of our experiments (see Fig. 3) show that the getBlockByNumber,
submitBlock, and slash functions have a constant gas consumption. The
getBlockByNumber function consumes 70,914 gas, the submitBlock function
377,673 gas, and the slash function 305,024 gas. The submitBlock function has
low and constant gas consumption since its only task is to store the request
and notify the oracle nodes. The submitBlock and slash functions consume more
gas since these functions need to verify zk-SNARKs, including the computation
of elliptic curve pairings. However, due to the application of zk-SNARKs, the
gas consumption for verifying the correct execution of the off-chain
aggregation and slashing mechanisms is low and independent of the committee
size.

The remaining functions of the zkOracle contract to manage the committee of
oracle nodes exhibit an increasing gas consumption depending on the height of
the Merkle tree storing the accounts. The gas consumption for these functions
remains nearly constant, with negligible variations due to the EVM’s memory
and storage management, until the height of the Merkle tree increases. The
register function consumes 285,008 gas, the replace function 522,704 gas, the
exit function 233,602, and the withdraw function 524,883 gas considering a
committee size of 4. Increasing the committee size to 256 leads to a gas
consumption of 553,940 for the register function, 1,278,273 for the replace
function, 485,572 for the exit function, and 1,277,974 for the withdraw
function. The replace and withdraw functions have nearly the same gas
consumption, as withdrawing is a replacement with an empty account and an
additional transfer of funds to the account owner. The gas consumption of
these operations can get quite high since the number of expensive hash
operations increases. However, these operations are rarely executed and only
needed to change the committee of oracle nodes.

Compared to another oracle solution, e.g., the oracle in (Sober et al., 2021),
which consumes 257,602 gas $\pm$ 21,671 gas for block submissions, the
proposed solution consumes more gas. However, it does not require executing a
DKG protocol and enables equal reward distribution. Further, the proposed
solution incurs fewer costs than a relay solution, e.g., ETH relay
(Frauenthaler et al., 2020), which consumes 284,041 gas for each block header
submission. The submission costs of ETH relay may be lower, but the relay
requires off-chain clients to relay each block of the source blockchain, while
the proposed oracle solution only retrieves blocks on-demand. The Off-Chain
Reporting (OCR) protocol (Breidenbach et al., 2021b) used by Chainlink’s price
feed oracles consumes around 291 kGas for the first submission using 31 oracle
nodes. However, these costs increase with the number of oracle nodes while our
solution provides constant submission costs. Another comparison with zkBridge
(Xie et al., 2022) shows that while zkBridge only consumes 220 kGas for on-
chain verification, it requires tailored solutions based on the connected
blockchains, while our solution is mostly blockchain agnostic. Further, there
is still the potential to reduce gas consumption by changing the public inputs
to private inputs and only providing a hash of the previously public inputs to
the circuits to check if the inputs are correct. However, this comes at the
cost of higher resource consumption for generating the proofs since most
blockchains do not support arithmetization-friendly hash functions.

###  6.3. Performance

4816326412825625651210242048409681921638432768Committee SizeProof Generation
Time in msaggregateslash

Figure 4. Time to generate the proofs

As has already been discussed before, the execution of smart contracts
introduces additional costs for clients and oracle nodes. Therefore, the
oracle nodes move as much computation and storage off-chain to reduce the
costs. The aggregator executes the aggregation and slashing mechanisms locally
and generates zk-SNARKs to allow the zkOracle contract to verify these
computations on the blockchain. However, in exchange, the current aggregator
must spend a lot of computational resources to generate a zk-SNARK. The
aggregator’s time to generate the proofs is a critical aspect affecting the
system’s throughput. The proof generation time depends mainly on the
complexity of the computations, i.e., the aggregation and slashing algorithms.
The more complex the calculation, the larger the arithmetic circuit and the
longer it takes to generate the proof. Therefore, we examine the influence of
the committee size on the proof generation time.

The results (see Fig. 4) show that the proof generation time for the
aggregation algorithm increases linearly with the committee size. The proof
generation time for the slashing algorithm, on the other hand, is constant in
intervals depending on the height of the Merkle tree. However, the proof
generation time for the aggregation algorithm increases considerably faster
since a bigger committee size requires more votes from the validators and,
therefore, more Merkle proofs, signatures, and value transfers, leading to a
bigger circuit. Generating the proof for the aggregation algorithm takes 787
ms $\pm$ 14 ms with a committee size of 4 up to 35.4 s $\pm$ 137 ms with a
committee size of 256. The proof generation time for the slashing algorithm is
369 ms $\pm$ 12 ms for a committee of size 4 and 428 ms $\pm$ 2 ms for a
committee of size 256. The measured proof generation time allows for the
practical application of the proposed solution since blockchains exhibit block
times in the range of multiple seconds, limiting the overall throughput.

###  6.4. Memory

48163264128256641282565121024204840968192Committee SizeMemory in
MBaggregateslash

Figure 5. Memory usage during proof generation

Memory consumption is another critical aspect to consider for the
applicability of the proposed solution in a real-world scenario. The reason
for this is a higher entry barrier for oracle nodes and, consequently, a
possibly lower degree of decentralization, as oracle nodes require more memory
to execute the aggregation mechanism. Therefore, after examining the proof
generation time, we also inspect the memory consumption. As with the proof
generation time, the memory consumption also depends on the complexity of the
algorithms due to the corresponding larger size of the arithmetic circuit.
Therefore, we also inspect the memory consumption during proof generation for
a varying committee size. For that, we consider the allocated memory for
building the constraint system, the proving key, creating the witness, and
generating the proof.

The results (see Fig. 5) show that memory consumption follows the same
behavior as the proof generation time. The memory consumption increases
linearly for the aggregation algorithm and stepwise for the slashing
algorithm. As with the proving time, the increasing complexity of the
aggregation circuit makes the memory consumption higher and faster growing
than for the slashing circuit. The generation of the aggregation proof
requires 147 MB with a committee size of 4 and 8.5 GB with a committee size of
256. The generation of the slashing proof, on the other hand, only requires 51
MB for a committee size of 4 and 82 MB for a committee size of 256. Therefore,
oracle nodes, which do not have extensive resources, can still join the system
and support fairly large committee sizes.

##  7\. Related Work

In the course of this section, we discuss related work concerning cross-
blockchain communication mechanisms and protocols. Among other things, we
examine blockchain relays, notary schemes, blockchains of blockchains, and
others.

###  7.1. Blockchain Relays

The authors of (Frauenthaler et al., 2020) propose ETH relay, a relay scheme
for Ethereum-based blockchains which use the Proof of Work (PoW) consensus
mechanism. ETH relay applies a validation-on-demand pattern where the relay
contract optimistically accepts new block headers from the source blockchain.
Off-chain clients continuously relay block headers from the source blockchain
to the target blockchain but also monitor the relay contract to detect invalid
block headers. Any off-chain client can trigger the validation of a submitted
block header during a dispute period. If the block is invalid, the relay
contract removes the invalid and all subsequent block headers. The relay
considers a block valid if there is no dispute and the dispute period has
ended. Additionally, the relay applies an incentive mechanism to encourage
honest behavior and reward off-chain clients for block header submissions.
While the solution achieves considerable improvements concerning cost
efficiency, the cost overhead of relaying all block headers remains high.

Scaffino et al. (Scaffino et al., 2023) propose a cross-blockchain
communication mechanism that retrieves on-demand state information about a PoW
source blockchain on a target blockchain. A contract on the target blockchain
can verify constant-sized proofs consisting of $n$ confirmation block headers
showing that certain transactions are part of the source blockchain. The proof
construction is similar to stateless SPV but uses additional mechanisms to
prevent upfront mining attacks and does not require Turing-complete smart
contracts. Further, the authors prove the protocol’s security and show how it
enables several cross-chain applications such as lending, Proofs-of-Burn, and
off-chain betting hubs.

Westerkamp and Eberhardt (Westerkamp and Eberhardt, 2020) propose zkRelay,
another relay solution for PoW blockchains. The relay uses zk-SNARKs to
validate block headers off-chain to reduce the costs of block header
submissions. Off-chain clients generate a zk-SNARK for an off-chain validation
program which takes a block header as input and returns a boolean value
indicating if the block is valid. Further, zkRelay supports batch verification
of block headers, while the relay contract only needs to store the last block
of a batch. The validation program builds a Merkle tree for the intermediary
block headers and returns the root along with the validation result. After
that, the relay allows the submission of intermediary block headers, which
only requires a Merkle proof to show the inclusion of the block. The
application of zk-SNARKs to verify the blocks off-chain leads to better cost-
efficiency. However, off-chain clients need more computing power and memory to
generate the proofs.

Another protocol for cross-blockchain communication based on zk-SNARKs is
Zendoo (Garoffolo et al., 2020). Zendoo allows sidechain constructions for
Bitcoin-like blockchains where sidechains directly monitor their respective
mainchain. However, the mainchain only receives zk-SNARKs to verify the state
of the sidechain. Sidechains can have different internal structures and follow
distinct approaches to create certificates for communicating with the
mainchain as long as they follow the basic verifier interface. Unfortunately,
Zendoo only allows the transfer of assets and not arbitrary data.

Similar to (Garoffolo et al., 2020) and (Westerkamp and Eberhardt, 2020), the
authors of (Xie et al., 2022) propose a trustless blockchain bridge that uses
zk-SNARKs to reduce on-chain costs. The generation of zk-SNARKs requires
expressing the validation rules of the connected blockchains in an arithmetic
circuit which can be too inefficient for certain operations. Therefore, the
authors propose a 2-layer recursive proof system. The first layer applies the
proposed proof system deVirgo, which allows for the parallel generation of the
proof to achieve better performance. The second layer uses Groth16 for
recursively verifying proofs of the first layer to reduce the on-chain
verification costs of the proof. The smart contract checks if the block is
included and verifies the submitted proof against the current state and given
block header. Further, zkBridge also supports batch submissions of block
headers.

Westerkamp and Diez (Westerkamp and Diez, 2022) propose Verilay, a blockchain
relay for PoS blockchains. The relay contract on the target blockchain starts
from a trusted state containing the starting block and the corresponding
validator set. After that, any user can update the relay state by retrieving a
specific block, the current and next validator set, and submitting it to the
relay contract on the target blockchain. The relay contract validates a block
by checking the signatures and replaces the currently stored block if the
signatures are valid. Further, the relay checks whether to transition to a new
validator set. Verilay only requires a single update for each validator set
period since every block contains the history of the whole chain. The authors
implement Verilay for the Ethereum 2.0 beacon chain and show that Verilay is
more cost-efficient than PoW relays. However, the relay only ensures
accountable safety during a trusting period when the validators can not
withdraw the bonded stake. Otherwise, validators can misbehave without
consequences. Further, the complexity of validator set changes can pose a
challenge if it is not efficiently verifiable by the relay contract.

The discussed relay schemes enable cross-blockchain communication with a high
degree of decentralization. However, these solutions heavily depend on the
applied consensus mechanism of the source blockchain, as a smart contract or
arithmetic circuit must be able to express the source blockchain’s consensus
mechanism. As a result, the solutions have a high complexity level and require
many resources. On the other hand, the proposed oracle solution requires
little to no changes depending on the connected blockchains. Therefore, the
complexity is also correspondingly lower, leading to considerable resource
savings. However, the degree of decentralization is lower as the oracle relies
on a fixed-size committee.

###  7.2. Notary Schemes

In (Sober et al., 2021), the authors propose a voting-based oracle solution
for cross-blockchain communication. The oracle applies an off-chain voting
mechanism based on threshold signatures to allow a committee to
collaboratively return information queried from another blockchain while
keeping on-chain computation at a bare minimum. For that, the oracle divides
its participants into an aggregator and multiple validators. The validators
query the source blockchain for the requested data and sign the result with
their private key shares. The aggregator collects results and the
corresponding signature shares from the validators until the aggregator can
create the threshold signature. After that, the aggregator returns the data
and the threshold signature to an oracle contract which only has to verify the
threshold signature to verify the authenticity and integrity of the data.
Further, the oracle applies a crypto-economic incentive mechanism to give
aggregators a fixed reward and the chance to win an additional reward,
increasing over time until an aggregator wins.

The decentralized oracle network Chainlink (Breidenbach et al., 2021a) has
recently introduced the Cross-Chain Interoperability Protocol (CCIP) to allow
cross-chain messages and token transfers. For that, Chainlink extends the
application of its OCR protocol (Breidenbach et al., 2021b) to the domain of
cross-blockchain communication. The OCR protocol allows multiple oracle nodes
to aggregate their results in a single report and only to submit an aggregated
transaction. The protocol’s main purpose is to retrieve data from external
systems. However, it also allows for efficient and secure off-chain
computations enabling cross-chain messaging capabilities. A smart contract can
invoke a Chainlink message router on the source blockchain, which uses the
decentralized oracle network to transport the message to a message router on
the target blockchain. The message router on the target blockchain verifies
the message and forwards the message to another smart contract.

The authors of (Abdullah et al., 2022) propose Chain-net, a blockchain
interoperability framework for cross-blockchain communication. The solution
uses additional gateway nodes for each blockchain network. The gateway nodes
establish the connection between different blockchains and forward cross-chain
transactions. Further, the gateway ensures the atomicity of cross-chain
transactions by waiting for the necessary transaction confirmations of the
involved blockchains. The authors present a possible application in the
healthcare domain and evaluate it against certain criteria. Unfortunately, the
gateway nodes constitute a central entity in the system, contrary to
blockchains’ decentralized nature.

Madine et al. (Madine et al., 2021) propose appXchain, a blockchain
interoperability solution based on a dApp that manages the execution of cross-
blockchain transactions. The dApp communicates with the default APIs of the
underlying blockchain networks and acts as a translation layer between
blockchain networks. The system requires verifier nodes for each blockchain to
retrieve and verify the state from other blockchains and applies a reputation
system to encourage honest behavior. Further, the authors explain the proposed
solution using an example in healthcare to manage patient data.

Robinson and Ramesh (Robinson and Ramesh, 2021) propose a general-purpose
atomic cross-chain transaction protocol. The protocol allows synchronous
cross-blockchain smart contract calls for Ethereum-based blockchains. For the
execution of a function call involving multiple blockchains, the application
needs to simulate the execution of a call graph on all chains to determine the
respective input parameters to the function calls. After that, a cross-chain
control contract manages the execution on each blockchain. Further, each
blockchain requires a registrar contract to determine a set of signers that
attest to the emitted event’s correctness during function calls.

In (Nissl et al., 2021), the authors propose a framework for asynchronous
cross-blockchain smart contract calls. The framework requires intermediaries
which broker information between the source blockchain and the target
blockchain, i.e., relay specific smart contract calls and return the results.
For that, the intermediaries offer to execute cross-blockchain smart contracts
calls for a reward. The framework applies crypto-economic incentives and
relies on a trusted set of validators that vote on the validity of smart
contract invocations. More specifically, the validators check that
intermediaries execute the correct function, return the correct results, and
use the right amount of computation steps.

The above-mentioned solutions allow for cross-blockchain smart contract calls
and general cross-blockchain communication. Unfortunately, some of these
solutions require many on-chain resources, are centralized, or need more
details on the design and implementation. The approach presented in (Sober et
al., 2021) comes closest to the work at hand, whereby our proposed solution
does not require a DKG protocol or a lottery-like mechanism for reward
distribution. Our solution does not require any additional protocols, probably
jeopardizing security. Further, the proposed oracle allows splitting the
reward equally between the participating entities without incurring additional
costs.

###  7.3. Blockchain of Blockchains

The Cosmos (Kwon and Buchman, 2020) network connects multiple independent
blockchains, also called zones, which can seamlessly interoperate with each
other. Cosmos uses an Inter-blockchain Communication Protocol (IBC) (Goes,
2020) to transfer arbitrary data between blockchains. The IBC protocol follows
the basic concepts of TCP/IP. IBC allows modules on different blockchains to
establish channels to transmit packets containing arbitrary data, e.g.,
information about a token transfer. The connected blockchains verify the
transferred data packets by checking the inclusion of the data packet in the
respective blockchain state. Further, off-chain clients with access to both
blockchains handle the actual transmission of the packets between the ledgers.

Another blockchain network aiming for blockchain interoperability is Polkadot
(Wood, 2016). Polkadot connects multiple so-called parachains through a relay
chain, providing shared security and the possibility of trustless
communication between all connected parachains. The main actors of the system
are nominators, validators, and collators. The validators are randomly divided
into subsets for each parachain and add new blocks to the relay chain.
Polkadot uses the Cross-Consensus Message Format (XCM) for cross-blockchain
communication, which defines a communication language for parachains. During
cross-blockchain communication, nodes place cross-chain messages in message
queues and continuously ping other nodes to retrieve new messages. When
assembling a new block, nodes process cross-chain messages and transactions.

In (Liu et al., 2019), the authors propose HyperService, a platform for
blockchain interoperability that allows the execution of cross-blockchain
smart contracts. The platform introduces a new programming language to develop
cross-blockchain applications under a universal state model which abstracts
state transitions across multiple blockchains. HyperService uses a universal
inter-blockchain protocol to ensure the atomic and trustless execution of the
transactions submitted to the underlying blockchains. A blockchain of
blockchains provides a unified view of cross-blockchain applications by
recording the transaction’s status. At the same time, insurance smart
contracts determine the correctness of the execution and revert transactions
in case of exceptions.

Yeh et al. (Yeh et al., 2022) propose a cross-blockchain communication
mechanism based on a relay chain and certificateless signatures. The relay
chain connects two heterogeneous blockchains and applies a Delegated Proof of
Stake (DPoS) consensus mechanism independent of the consensus mechanism of the
connected blockchains. During the execution of a cross-blockchain call, one
party on each of the connected blockchains and a block producer collaborate to
execute a cross-blockchain transaction and create the respective block in the
relay chain. The authors implement the proposed solution for two private
Ethereum-based blockchains and evaluate the solution’s performance and
security.

The systems based on the blockchain of blockchains approach enable cross-
blockchain communication through a central relay chain which records cross-
blockchain transactions and attests to the correctness of the transferred data
between the connected blockchains. However, this approach also entails
considerable overhead, requiring an additional blockchain network to manage
the relay chain with its consensus rules. Therefore, the proposed oracle
solution represents a far more lightweight solution since the oracle builds
upon already existing blockchains.

##  8\. Conclusion

Cross-blockchain communication is one of the most pressing problems in
enabling blockchain interoperability and connecting heterogenous blockchains
to form a unified landscape of blockchain systems. Research has led to
different solutions for achieving blockchain interoperability by proposing
different cross-blockchain communication mechanisms. However, these solutions
are primarily complex based on the connected blockchains, require additional
blockchains, or are very resource intensive.

Therefore, we propose an off-chain communication mechanism based on oracles.
The oracle comprises a committee of oracle nodes that query the source
blockchain for specific data. The zkOracle contract only stores the root of a
Merkle tree, storing the account data of the oracle nodes to move state and
computation off-chain. For each request, the oracle nodes need to execute an
off-chain aggregation mechanism to aggregate the retrieved data from the
oracle nodes and reach a consensus on the returned result. The oracle
schedules one oracle node as an aggregator while the remaining nodes act as
validators. The validators query the source blockchain to retrieve the data
and send the signed result to the aggregator. Then, the aggregator verifies
that the majority returned the same data and distributes the rewards. For this
computation, the aggregator generates a zk-SNARK and only submits the new
state root, result, and proof to the zkOracle contract. The contract must only
verify the proof’s correctness and store the updated state root and result.
Additionally, the aggregator can slash misbehaving validators to ensure
accountability and incentivize honest behavior. The proposed oracle solution
requires minimal computation and storage on the blockchain and offers the
necessary functionality to enable the decentralized transfer of arbitrary data
between blockchains.

In future work, we want to explore possible optimizations through batch
submissions to reduce the costs of the aggregator for submitting an aggregated
result. Further, we want to explore possibilities to move the remaining state
of the zkOracle contract off-chain.

###### Acknowledgements.

The financial support from the Austrian Federal Ministry for Digital and
Economic Affairs, the National Foundation for Research, Technology, and
Development, and the Christian Doppler Research Association is gratefully
acknowledged.

## References

  * (1)
  * Abdullah et al. (2022) Sidrah Abdullah, Junaid Arshad, and Muhammad Alsadi. 2022\.  Chain-Net: An Internet-inspired Framework for Interoperable Blockchains.  _Distributed Ledger Technologies: Research and Practice_ 1, 2 (2022), 1–20.
  * Agbo et al. (2019) Cornelius C Agbo, Qusay H Mahmoud, and J Mikael Eklund. 2019\.  Blockchain technology in healthcare: a systematic review. In _Healthcare_ , Vol. 7. 56\.
  * Al-Bassam et al. (2018) Mustafa Al-Bassam, Alberto Sonnino, and Vitalik Buterin. 2018\.  Fraud proofs: Maximising light client security and scaling blockchains with dishonest majorities.  _arXiv preprint arXiv:1809.09044_ (2018).
  * Al-Breiki et al. (2020) Hamda Al-Breiki, Muhammad Habib Ur Rehman, Khaled Salah, and Davor Svetinovic. 2020.  Trustworthy blockchain oracles: review, comparison, and open research challenges.  _IEEE Access_ 8 (2020), 85675–85685.
  * Albrecht et al. (2016) Martin Albrecht, Lorenzo Grassi, Christian Rechberger, Arnab Roy, and Tyge Tiessen. 2016.  MiMC: Efficient encryption and cryptographic hashing with minimal multiplicative complexity. In _International Conference on the Theory and Application of Cryptology and Information Security_. Springer, 191–219.
  * Almashaqbeh and Solomon (2022) Ghada Almashaqbeh and Ravital Solomon. 2022.  SoK: privacy-preserving computing in the blockchain era. In _2022 IEEE 7th European Symposium on Security and Privacy (EuroS &P)_. IEEE, 124–139.
  * Belchior et al. (2023) Rafael Belchior, Luke Riley, Thomas Hardjono, André Vasconcelos, and Miguel Correia. 2023\.  Do you need a distributed ledger technology interoperability solution?  _Distributed Ledger Technologies: Research and Practice_ 2, 1 (2023), 1–37.
  * Belchior et al. (2021) Rafael Belchior, André Vasconcelos, Sérgio Guerreiro, and Miguel Correia. 2021.  A survey on blockchain interoperability: Past, present, and future trends.  _Comput. Surveys_ 54, 8 (2021), 1–41.
  * Bellare and Rogaway (1993) Mihir Bellare and Phillip Rogaway. 1993.  Random oracles are practical: A paradigm for designing efficient protocols. In _Proceedings of the 1st ACM Conference on Computer and Communications Security_. 62–73.
  * Bellés-Muñoz et al. (2021) Marta Bellés-Muñoz, Barry Whitehat, Jordi Baylina, Vanesa Daza, and Jose Luis Muñoz-Tapia. 2021.  Twisted Edwards elliptic curves for zero-knowledge circuits.  _Mathematics_ 9, 23 (2021).
  * Ben-Sasson et al. (2019) Eli Ben-Sasson, Iddo Bentov, Yinon Horesh, and Michael Riabzev. 2019.  Scalable zero knowledge with no trusted setup. In _39th Annual International Cryptology Conference_. Springer, 701–732.
  * Ben-Sasson et al. (2014a) Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014a.  Zerocash: Decentralized Anonymous Payments from Bitcoin. In _2014 IEEE Symposium on Security and Privacy_. 459–474.
  * Ben-Sasson et al. (2014b) Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. 2014b.  Succinct $\\{$Non-Interactive$\\}$ zero knowledge for a von neumann architecture. In _23rd USENIX Security Symposium_. USENIX Association, 781–796.
  * Bernstein (2006) Daniel J Bernstein. 2006\.  Curve25519: new Diffie-Hellman speed records. In _9th International Conference on Theory and Practice in Public-Key Cryptography_. Springer, 207–228.
  * Blum et al. (2019) Manuel Blum, Paul Feldman, and Silvio Micali. 2019\.  Non-interactive zero-knowledge and its applications.  In _Providing Sound Foundations for Cryptography: On the Work of Shafi Goldwasser and Silvio Micali_ , Oded Goldreich (Ed.). 329–349.
  * Botrel et al. (2023) Gautam Botrel, Thomas Piellard, Youssef El Housni, Ivo Kubjas, and Arya Tabaie. 2023.  _ConsenSys/gnark: v0.8.0_.  https://doi.org/10.5281/zenodo.5819104
  * Bowe et al. (2017) Sean Bowe, Ariel Gabizon, and Ian Miers. 2017.  Scalable multi-party computation for zk-SNARK parameters in the random beacon model.  _Cryptology ePrint Archive_ (2017).
  * Breidenbach et al. (2021a) Lorenz Breidenbach, Christian Cachin, Benedict Chan, Alex Coventry, Steve Ellis, Ari Juels, Farinaz Koushanfar, Andrew Miller, Brendan Magauran, Daniel Moroz, et al. 2021a.  _Chainlink 2.0: Next steps in the evolution of decentralized oracle networks_.  Retrieved 2023-03-16 from https://naorib.ir/white-paper/chinlink-whitepaper.pdf
  * Breidenbach et al. (2021b) Lorenz Breidenbach, Christian Cachin, Alex Coventry, Ari Juels, and Andrew Miller. 2021b.  _Chainlink off-chain reporting protocol_.  Retrieved 2024-03-07 from https://research.chain.link/ocr.pdf
  * Bünz et al. (2018) Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter Wuille, and Greg Maxwell. 2018.  Bulletproofs: Short proofs for confidential transactions and more. In _2018 IEEE Symposium on Security and Privacy_. IEEE, 315–334.
  * Buterin (2016) Vitalik Buterin. 2016\.  Chain interoperability.  _R3 Research Paper_ 9 (2016).
  * Buterin (2021) Vitalik Buterin. 2021\.  _An Incomplete Guide to Rollups_.  Retrieved 2023-03-09 from https://vitalik.ca/general/2021/01/05/rollup.html
  * Cai et al. (2018) Wei Cai, Zehua Wang, Jason B Ernst, Zhen Hong, Chen Feng, and Victor CM Leung. 2018\.  Decentralized applications: The blockchain-empowered software system.  _IEEE access_ 6 (2018), 53019–53033.
  * Chiesa et al. (2020) Alessandro Chiesa, Yuncong Hu, Mary Maller, Pratyush Mishra, Noah Vesely, and Nicholas Ward. 2020\.  Marlin: Preprocessing zkSNARKs with universal and updatable SRS. In _39th Annual International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 738–768.
  * Costello et al. (2015) Craig Costello, Cédric Fournet, Jon Howell, Markulf Kohlweiss, Benjamin Kreuter, Michael Naehrig, Bryan Parno, and Samee Zahur. 2015\.  Geppetto: Versatile verifiable computation. In _2015 IEEE Symposium on Security and Privacy_. IEEE, 253–270.
  * Dai et al. (2019) Hong-Ning Dai, Zibin Zheng, and Yan Zhang. 2019.  Blockchain for Internet of Things: A survey.  _IEEE Internet of Things Journal_ 6, 5 (2019), 8076–8094.
  * Demestichas et al. (2020) Konstantinos Demestichas, Nikolaos Peppes, Theodoros Alexakis, and Evgenia Adamopoulou. 2020\.  Blockchain in agriculture traceability systems: A review.  _Applied Sciences_ 10, 12 (2020), 4113.
  * Douceur (2002) John R Douceur. 2002\.  The sybil attack. In _International Workshop on Peer-to-Peer Systems_. Springer, 251–260.
  * Ellul and Pace (2022) Joshua Ellul and Gordon J Pace. 2022.  Verifiable External Blockchain Calls: Towards Removing Oracle Input Intermediaries. In _International Workshop on Data Privacy Management_. Springer, 317–324.
  * Foundation (2022) Hyperledger Foundation. 2022\.  _Introducing Hyperledger Cacti, a Multi-Faceted Pluggable Interoperability Framework_.  Retrieved 2024-03-07 from https://www.hyperledger.org/blog/2022/11/07/introducing-hyperledger-cacti-a-multi-faceted-pluggable-interoperability-framework
  * Frauenthaler et al. (2020) Philipp Frauenthaler, Marten Sigwart, Christof Spanring, Michael Sober, and Stefan Schulte. 2020\.  ETH relay: A cost-efficient relay for ethereum-based blockchains. In _2020 IEEE International Conference on Blockchain_. IEEE, 204–213.
  * Gabizon et al. (2019) Ariel Gabizon, Zachary J Williamson, and Oana Ciobotaru. 2019\.  Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge.  _Cryptology ePrint Archive_ (2019).
  * Garoffolo et al. (2020) Alberto Garoffolo, Dmytro Kaidalov, and Roman Oliynykov. 2020\.  Zendoo: A zk-SNARK verifiable cross-chain transfer protocol enabling decoupled and decentralized sidechains. In _2020 IEEE 40th International Conference on Distributed Computing Systems (ICDCS)_. IEEE, 1257–1262.
  * Gennaro et al. (2010) Rosario Gennaro, Craig Gentry, and Bryan Parno. 2010\.  Non-interactive verifiable computing: Outsourcing computation to untrusted workers. In _30th Annual Cryptology Conference_. Springer, 465–482.
  * Goes (2020) Christopher Goes. 2020\.  The Interblockchain Communication Protocol: An Overview.  _arXiv preprint arXiv:2006.15918_ (2020).
  * Goldreich et al. (1991) Oded Goldreich, Silvio Micali, and Avi Wigderson. 1991\.  Proofs that yield nothing but their validity or all languages in NP have zero-knowledge proof systems.  _J. ACM_ 38, 3 (1991), 690–728.
  * Goldwasser et al. (2019) Shafi Goldwasser, Silvio Micali, and Chales Rackoff. 2019\.  The knowledge complexity of interactive proof-systems.  In _Providing Sound Foundations for Cryptography: On the Work of Shafi Goldwasser and Silvio Micali_ , Oded Goldreich (Ed.). 203–225.
  * Goldwasser et al. (1988) Shafi Goldwasser, Silvio Micali, and Ronald L Rivest. 1988\.  A digital signature scheme secure against adaptive chosen-message attacks.  _SIAM Journal on computing_ 17, 2 (1988), 281–308.
  * Groth (2016) Jens Groth. 2016\.  On the size of pairing-based non-interactive arguments. In _Annual International Conference on the Theory and Applications of Cryptographic Techniques_. Springer, 305–326.
  * Hafid et al. (2020) Abdelatif Hafid, Abdelhakim Senhaji Hafid, and Mustapha Samih. 2020.  Scaling blockchains: A comprehensive survey.  _IEEE Access_ 8 (2020), 125244–125262.
  * Heiss et al. (2019) Jonathan Heiss, Jacob Eberhardt, and Stefan Tai. 2019\.  From oracles to trustworthy data on-chaining systems. In _2019 IEEE International Conference on Blockchain (Blockchain)_. IEEE, 496–503.
  * Herlihy (2018) Maurice Herlihy. 2018\.  Atomic cross-chain swaps. In _2018 ACM Symposium on Principles of Distributed Computing_. ACM, 245–254.
  * Hopwood et al. (2016) Daira Hopwood, Sean Bowe, Taylor Hornby, and Nathan Wilcox. 2016\.  _Zcash Protocol Specication_.  Retrieved 2022-06-24 from https://raw.githubusercontent.com/zcash/zips/master/protocol/protocol.pdf
  * Kalodner et al. (2018) Harry Kalodner, Steven Goldfeder, Xiaoqi Chen, S Matthew Weinberg, and Edward W Felten. 2018\.  Arbitrum: Scalable, private smart contracts. In _27th USENIX Security Symposium_. USENIX Association, 1353–1370.
  * Kwon and Buchman (2020) Jae Kwon and Ethan Buchman. 2020.  _Cosmos Whitepaper: A Network of Distributed Ledgers_.  Retrieved 2023-03-16 from https://wikibitimg.fx994.com/attach/2020/12/16623142020/WBE16623142020_55300.pdf
  * Lafourcade and Lombard-Platet (2020) Pascal Lafourcade and Marius Lombard-Platet. 2020.  About blockchain interoperability.  _Inform. Process. Lett._ 161 (2020), 105976.
  * Liu et al. (2019) Zhuotao Liu, Yangxi Xiang, Jian Shi, Peng Gao, Haoyu Wang, Xusheng Xiao, Bihan Wen, and Yih-Chun Hu. 2019\.  Hyperservice: Interoperability and programmability across heterogeneous blockchains. In _2019 ACM SIGSAC Conference on Computer and Communications Security_. ACM, 549–566.
  * Madine et al. (2021) Mohammad Madine, Khaled Salah, Raja Jayaraman, Yousof Al-Hammadi, Junaid Arshad, and Ibrar Yaqoob. 2021.  appxchain: Application-level interoperability for blockchain networks.  _IEEE Access_ 9 (2021), 87777–87791.
  * Maller et al. (2019) Mary Maller, Sean Bowe, Markulf Kohlweiss, and Sarah Meiklejohn. 2019.  Sonic: Zero-knowledge SNARKs from linear-size universal and updatable structured reference strings. In _2019 ACM SIGSAC Conference on Computer and Communications Security_. ACM, 2111–2128.
  * Nakamoto (2008) Satoshi Nakamoto. 2008\.  _Bitcoin: A peer-to-peer electronic cash system_.  Retrieved 2022-07-02 from http://www.bitcoin.org/bitcoin.pdf
  * Nissl et al. (2021) Markus Nissl, Emanuel Sallinger, Stefan Schulte, and Michael Borkowski. 2021.  Towards Cross-Blockchain Smart Contracts. In _2021 IEEE International Conference on Decentralized Applications and Infrastructures_. IEEE, 85–94.
  * Parno et al. (2016) Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. 2016\.  Pinocchio: Nearly practical verifiable computation.  _Commun. ACM_ 59, 2 (2016), 103–112.
  * Parno et al. (2012) Bryan Parno, Mariana Raykova, and Vinod Vaikuntanathan. 2012\.  How to delegate and verify in public: Verifiable computation from attribute-based encryption. In _9th Theory of Cryptography Conference_. Springer, 422–439.
  * Robinson and Ramesh (2021) Peter Robinson and Raghavendra Ramesh. 2021.  General Purpose Atomic Crosschain Transactions. In _2021 3rd Conference on Blockchain Research Applications for Innovative Networks and Services_. IEEE, 61–68.
  * Saberi et al. (2019) Sara Saberi, Mahtab Kouhizadeh, Joseph Sarkis, and Lejia Shen. 2019.  Blockchain technology and its relationships to sustainable supply chain management.  _International Journal of Production Research_ 57, 7 (2019), 2117–2135.
  * Scaffino et al. (2023) Giulia Scaffino, Lukas Aumayr, Zeta Avarikioti, and Matteo Maffei. 2023.  Glimpse: On-Demand PoW Light Client with Constant-Size Storage for DeFi. In _32nd USENIX Security Symposium (USENIX Security 23)_. USENIX Association.
  * Scaffino et al. (2024) Giulia Scaffino, Lukas Aumayr, Mahsa Bastankhah, Zeta Avarikioti, and Matteo Maffei. 2024\.  Alba: The Dawn of Scalable Bridges for Blockchains.  Cryptology ePrint Archive, Paper 2024/197.  https://eprint.iacr.org/2024/197
  * Schulte et al. (2019) Stefan Schulte, Marten Sigwart, Philipp Frauenthaler, and Michael Borkowski. 2019.  Towards blockchain interoperability. In _Business Process Management: Blockchain and Central and Eastern Europe Forum: BPM 2019 Blockchain and CEE Forum_. Springer, 3–10.
  * Sober et al. (2023) Michael Sober, Max Kobelt, Giulia Scaffino, Dominik Kaaser, and Stefan Schulte. 2023.  Distributed Key Generation with Smart Contracts using zk-SNARKs. In _38th ACM/SIGAPP Symposium on Applied Computing (SAC ’23)_. ACM.  In Press.
  * Sober et al. (2021) Michael Sober, Giulia Scaffino, Christof Spanring, and Stefan Schulte. 2021.  A voting-based blockchain interoperability oracle. In _2021 IEEE International Conference on Blockchain_. IEEE, 160–169.
  * Thibault et al. (2022) Louis Tremblay Thibault, Tom Sarry, and Abdelhakim Senhaji Hafid. 2022.  Blockchain Scaling Using Rollups: A Comprehensive Survey.  _IEEE Access_ 10 (2022), 93039–93054.
  * Wang et al. (2023) Gang Wang, Qin Wang, and Shiping Chen. 2023.  Exploring Blockchains Interoperability: A Systematic Survey.  _ACM Comput. Surv._ (2023).
  * Westerkamp and Diez (2022) Martin Westerkamp and Maximilian Diez. 2022.  Verilay: A verifiable proof of stake chain relay. In _2022 IEEE International Conference on Blockchain and Cryptocurrency_. IEEE, 1–9.
  * Westerkamp and Eberhardt (2020) Martin Westerkamp and Jacob Eberhardt. 2020.  zkrelay: Facilitating sidechains using zksnark-based chain-relays. In _2020 IEEE European Symposium on Security and Privacy Workshops_. IEEE, 378–386.
  * Wood (2016) Gavin Wood. 2016\.  _Polkadot: Vision for a heterogeneous multi-chain framework_.  Retrieved 2023-03-16 from https://www.win.tue.nl/~mholende/seminar/references/ethereum_polkadot.pdf
  * Wood et al. (2014) Gavin Wood et al. 2014\.  Ethereum: A secure decentralised generalised transaction ledger.  _Ethereum project yellow paper_ 151, 2014 (2014), 1–32.
  * Xie et al. (2019) Junfeng Xie, Helen Tang, Tao Huang, F Richard Yu, Renchao Xie, Jiang Liu, and Yunjie Liu. 2019.  A survey of blockchain technology applied to smart cities: Research issues and challenges.  _IEEE Communications Surveys & Tutorials_ 21, 3 (2019), 2794–2830.
  * Xie et al. (2022) Tiancheng Xie, Jiaheng Zhang, Zerui Cheng, Fan Zhang, Yupeng Zhang, Yongzheng Jia, Dan Boneh, and Dawn Song. 2022\.  zkbridge: Trustless cross-chain bridges made practical.  _arXiv preprint arXiv:2210.00264_ (2022).
  * Yeh et al. (2022) Kuo-Hui Yeh, Guan-Yan Yang, Chanapha Butpheng, Lin-Fa Lee, and Ying-Ho Liu. 2022.  A Secure Interoperability Management Scheme for Cross-Blockchain Transactions.  _Symmetry_ 14, 12 (2022), 2473.
  * Zamyatin et al. (2021) Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias, and William J Knottenbelt. 2021.  SoK: Communication across distributed ledgers. In _25th International Conference on Financial Cryptography and Data Security, Revised Selected Papers, Part II_. Springer, 3–36.
  * Zhang et al. (2020) Yuhang Zhang, Jun Wang, and Jie Luo. 2020.  Heuristic-based address clustering in bitcoin.  _IEEE Access_ 8 (2020), 210582–210591.
  * Zhou et al. (2020) Qiheng Zhou, Huawei Huang, Zibin Zheng, and Jing Bian. 2020\.  Solutions to scalability of blockchain: A survey.  _Ieee Access_ 8 (2020), 16440–16455.

  *[zk-SNARKs]: Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
  *[DKG]: Distributed Key Generation
  *[zk-SNARK]: Zero-Knowledge Succinct Non-interactive Arguments of Knowledge
  *[SPV]: Simplified Payment Verification
  *[ZKPs]: Zero-Knowledge Proof
  *[ZKP]: Zero-Knowledge Proof
  *[NIZK]: Non-interactive Zero-Knowledge Proof
  *[zk-STARKs]: Zero-Knowledge Succinct (Scalable) Transparent Arguments of Knowledge
  *[CRS]: Common Reference String
  *[R1CS]: Rank-1 Constraint-System
  *[QAP]: Quadratic Arithmetic Program
  *[MPC]: Multiparty Computation
  *[PoS]: Proof of Stake
  *[EUF-CMA]: Existential Unforgeability under Chosen Message Attack
  *[dApp]: Decentralized Application
  *[EVM]: Ethereum Virtual Machine
  *[EdDSA]: Edwards-curve Digital Signature Algorithm
  *[ETH]: Ether
  *[OCR]: Off-Chain Reporting
  *[PoW]: Proof of Work
  *[CCIP]: Cross-Chain Interoperability Protocol
  *[IBC]: Inter-blockchain Communication Protocol
  *[XCM]: Cross-Consensus Message Format
  *[DPoS]: Delegated Proof of Stake