2021 IEEE International Conference on Blockchain (Blockchain)

A Voting-Based Blockchain Interoperability Oracle

Michael Sober∗† , Giulia Scaffino∗‡ , Christof Spanring§ , Stefan Schulte∗†
∗ Christian Doppler Laboratory for Blockchain Technologies for the Internet of Things
† Institute of Data Engineering, TU Hamburg, Hamburg, Germany
{michael.sober, stefan.schulte}@tuhh.de
‡ Institute of Logic and Computation, TU Wien, Vienna, Austria
giulia.scaffino@tuwien.ac.at
§ Pantos GmbH, Vienna, Austria
christof.spanring@bitpanda.com
2021 IEEE International Conference on Blockchain (Blockchain) | 978-1-6654-1760-0/21/$31.00 ©2021 IEEE | DOI: 10.1109/BLOCKCHAIN53845.2021.00030

Abstract—Today’s blockchain landscape is severely fragmented to obtain data from the outside world. One can imagine, for
as more and more heterogeneous blockchain platforms have been example, a decentralized application that needs flight data from
developed in recent years. These blockchain platforms are not an airline to determine if a user has the right to compensation
able to interact with each other or with the outside world since
only little emphasis is placed on the interoperability between in case a flight is delayed or a cross-chain token transfer that
them. Already proposed solutions for blockchain interoperability requires the knowledge of whether the tokens were burned on
such as naive relay or oracle solutions are usually not broadly the original blockchain. This problem is also known as the
applicable since they are either too expensive to operate or very blockchain oracle problem [7].
resource-intensive. Many attempts have been made to achieve interoperability
For that reason, we propose a blockchain interoperability
oracle that follows a voting-based approach based on threshold between different blockchain platforms [5] and to solve the
signatures. The oracle nodes generate a distributed private key oracle problem [7], [8]. One possible approach to achieve
to execute an off-chain aggregation mechanism to collectively interoperability between two blockchain platforms is the use
respond to requests. Compared to state-of-the-art relay schemes, of blockchain relays [9]. Such relays are usually provided
our approach does not incur any ongoing costs and since the as smart contracts running on a “target blockchain”, i.e., the
on-chain component only needs to verify a single signature, we
can achieve remarkable cost savings compared to conventional blockchain which needs data from a “source blockchain”. With
oracle solutions. blockchain relays, the state of one blockchain is replicated
Index Terms—blockchain interoperability, blockchain oracles, within another blockchain, which enables callers of the relay
threshold signature, smart contracts contract to verify the existence of a transaction on the source
blockchain.
I. I NTRODUCTION Bitcoin and Ethereum use Merkle trees to store transactions
In recent years, blockchain technology has become increas- in a block, whereby the root of the Merkle tree is stored in the
ingly important not only as the underlying technology for block header. Therefore, a relay contract can use Simplified
cryptocurrencies [1] but also in many other application areas Payment Verification (SPV) which utilizes Merkle proofs to
including supply chain management [2], healthcare [3], and check whether a transaction is included in a block of a source
others. This has led to the development of more and more blockchain [9]. Since block header validation is done by a
heterogeneous blockchain platforms [4], [5]. These are often smart contract on-chain, no trusted intermediary is needed to
tailored to specific requirements, as there is not one blockchain relay the block headers. However, this has the disadvantage
that is capable of fulfilling the (often) disjunctive needs of that such relays also have considerable costs, since on-chain
different application areas. verification is very expensive and blocks have to be relayed
Research and industry tend to not consider the interoper- continuously, even if they are perhaps not needed at all.
ability between different blockchain platforms, turning these Another approach is to make use of blockchain oracles to
platforms into self-contained systems [4]. As a result, these get information from the outside world. Blockchain oracles
platforms are not able to collaborate to benefit from novel are bridges between blockchain platforms and external data
features and properties of other or newly developed blockchain sources. The task of a blockchain oracle is to query data from
platforms. The problem of weak interoperability does not only external data sources and then to pass the data items to a smart
exist within the world of blockchains but generally with sys- contract. The problem here is to ensure the authenticity and
tems that are outside the blockchain platform’s boundaries. As integrity of the data because we have to trust the oracle that
an example, we can use the smart contract and decentralized it behaves honestly [8].
application platform Ethereum [6]. Smart contracts running One can differentiate between oracles that are based on a
in the Ethereum Virtual Machine (EVM) cannot interact with centralized or a decentralized approach [7]. Centralized oracles
the outside world, which means that a smart contract is only represent a single point of failure since trust in a single oracle
able to read and modify the state of the hosting blockchain. node is required. Following the decentralized model, there is
For many applications, however, it is important to be able no single point of failure and the trust assumption moves from

978-1-6654-1760-0/21/$31.00 ©2021 IEEE 160

DOI 10.1109/Blockchain53845.2021.00030
Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
one oracle node to multiple oracle nodes. Many decentralized to create threshold signatures [11] using a secret sharing
oracles follow a voting-based approach to provide data, i.e., scheme (see Section II-B), whereby multiple participants share
the votes are aggregated to determine the overall result. a distributed private key and t out of n signature shares are
Unfortunately, the aggregation mechanism can become very required to create a valid signature.
expensive, if carried out on-chain. Also, it enables the aggregation of multiple signatures [12],
To make a step towards blockchain interoperability and whereby we only need to verify two elliptic curve pairings to
overcome the issues of current relay schemes and oracle solu- verify the aggregate signature. This is particularly interesting
tions, we investigate the application of Boneh-Lynn-Shacham in the area of blockchain technology. For example, one could
(BLS) threshold signatures to create an off-chain aggrega- instead of verifying every single signature of the transactions
tion mechanism to reduce the operating costs of the oracle. in a block, only verify a single aggregate signature.
Further, we examine the use of Distributed Key Generation
(DKG) protocols to generate distributed private keys which B. Verifiable Secret Sharing
are necessary for the creation of the threshold signatures while With the help of a secret sharing scheme, it is possible to
also preserving the decentralized nature of the blockchain. divide a secret S into n shares whereby each party gets a
We provide the system design of a voting-based blockchain different share of S, but at least t shares need to be known to
interoperability oracle that makes use of the aforementioned recover S. Otherwise, it is not possible to get any knowledge
concepts and enables clients to verify that a transaction is about S. These schemes are also known as (t, n) threshold
included in another blockchain. Further, we deliver a prototyp- schemes.
ical implementation and show the applicability of our proposed One of the first secret sharing schemes has been proposed
solution by conducting a security and cost analysis. by Shamir [13] in 1979. Using Shamir’s scheme, a dealer picks
The remainder of this paper is organized as follows: In a polynomial f (x) (see Eq. 2) of degree t − 1 whereby the
Section II, we introduce some basic concepts needed in our constant term a0 of the polynomial is equal to S and the
approach. Subsequently, we present the design of the oracle in coefficients are chosen randomly.
Section III. We follow up with implementation details of the
prototype in Section IV and evaluate our solution in Section V. f (x) = a0 + a1 x + · · · + at−1 xt−1 (2)
Afterward, we discuss related work in Section VI. Finally,
Section VII concludes the paper. The secret can be shared with n different parties by evaluat-
ing the polynomial at the positions xn = 1..n and distributing
II. BACKGROUND
the values for f (xn ) along with xn to the respective parties.
In the course of this section, we explain the basics of Since every polynomial of degree t − 1 is defined by exactly t
BLS signatures, followed by a short description of Verifiable points, we can make use of polynomial interpolation (e.g.,
Secret Sharing (VSS) which leads us to a discussion of DKG using the Lagrange interpolation formula) to recover the
protocols. original polynomial and to evaluate it at position 0 to get the
A. BLS Signatures secret.
One problem with this, however, is that Shamir’s scheme
The BLS signature scheme [10] is based on elliptic curve
does not take into account that a dealer could distribute
pairings (e : G1 × G2 → GT ) respectively bilinear maps.
incorrect or inconsistent shares. Furthermore, the shareholders
Using BLS, a public key P K is generated by multiplying
could also return incorrect shares. We cannot assume that
the selected private key SK with the generator G of a cyclic
the dealer and the shareholders are trustworthy, which is
group. To create a signature σ one has to hash the message
why we need secret sharing schemes that also take this
m on the curve H(m). This can be accomplished by using
kind of behavior into consideration, as is the case with VSS
a hashing algorithm like the Secure Hash Algorithm (SHA)-
schemes. By using such schemes, each party can verify that
256, whereby the resulting hash is used as the x-coordinate of
it has received the correct information from the dealer and
a point on the curve.
that shareholders submitted the correct shares. Hereby, we
If it is not possible to find such a point using this x-
limit ourselves mainly to non-interactive VSS schemes, in
coordinate, it can simply be incremented until a valid point
which only the dealer sends messages and no communication
is found. This is an essential difference from other signature
between the other participants is necessary. This reduces the
schemes in which the hash can be used directly. After that, the
communication overhead.
signature can be calculated by multiplying the point with the
One commonly used example of such a scheme is Feldman’s
private key. To verify the signature, it comes down to checking
VSS [14]. Feldman’s VSS is based on Shamir’s secret sharing
the bilinear pairings as can be seen in Eq. 1.
scheme but additionally makes use of homomorphic encryp-
tion to commit to the secret and coefficients of the random
e(σ, G) = e(H(m), P K) (1)
polynomial. The commitments are broadcast while the shares
This signature scheme has the advantage that it allows are distributed through private channels. Each party can use
to generate particularly short signatures. Another very im- the commitments to verify the validity of its share, due to the
portant aspect especially for this work is that it is possible homomorphic property of the used encryption scheme.

161

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
 A problem with this approach is that the commitment to Oracle

SigShare1

the secret also leaks information about the secret. This is natuurre
SigShare2

where Pedersen’s VSS [15], another very well-known scheme, SigShare3

V
constitutes a more secure solution. Like Feldman’s VSS, it is
also based on Shamir’s secret sharing scheme, but it makes A V
use of a different commitment scheme that ensures that no Sig
information about the secret is leaked unless one can find a V
solution to the discrete logarithm problem.

C. Distributed Key Generation

In the previous section, we discussed VSS, whereby such Fig. 1. Overview of the System
schemes ensure that a dealer distributes the secret correctly
and the shareholders cannot provide incorrect shares of the
respond to requests issued by clients (i.e., parties which are
secret. However, the dealer yet has to be trusted as it still
interested in the verification of a transaction from another
knows the secret. This is, among other things, a big concern
blockchain). For this, the oracle nodes use a DKG protocol
in the area of threshold cryptography, where we want that
to generate a distributed private key (see Section III-D),
only certain subsets of t ≤ n participants can jointly encrypt
whereby each node only knows its private key share and the
data or create a signature. Since the dealer knows about the
shared public key. Validators obtain the data from the other
distributed private key, it has the opportunity to encrypt data
blockchain and sign it with their private key share, while the
or to create signatures without the consent of at least t out of
aggregator collects the data and the signature shares from the
n participants.
validators to recover the final signature to submit it along with
To avoid this, a DKG protocol that allows the generation
the data to the smart contract. If the aggregator is not able
of distributed private keys without the dependency on any
to collect at least the threshold of signature shares with the
trusted third party can be used. In such protocols, no party
same result, it cannot generate a valid signature. To ensure
owns the private key and the private key is never reconstructed.
reliability, the aggregator changes over time so that each oracle
Many such protocols have been proposed over time [16]–[19],
node takes over the task of the aggregator at some point.
whereby we limit ourselves to the first proposed DKG protocol
As an integral part of the system, we also apply an incentive
by Pedersen [16] to describe the basic concept.
mechanism (see Section III-F) to encourage oracle nodes to
In Pedersen’s DKG protocol, every participant acts as a
engage as part of the decentralized oracle and to behave
dealer during one of the n parallel executions of Feldman’s
honestly. For this, the client must provide compensation for
VSS scheme to share a randomly picked secret. Each partic-
the transaction fees that arise from submitting the result using
ipant publishes its commitments using a broadcast channel,
the oracle contract and also offer two additional rewards. These
such as a blockchain. After that, every participant sends the
additional rewards consist of the aggregation reward and the
signed private shares to the other participants through private
validation reward. Without these rewards, the aggregator, as
channels. When receiving a share, each participant verifies the
well as the validators, would have no interest in participating
share by using the previously published commitments. If it
as they would only be providing their resources without getting
is an invalid share, a complaint including the share and the
anything back.
signature is broadcast. Each participant computes its private
share by summing up all shares received from the other parties B. Architecture
which shared their secret correctly and computes the public In our architecture, we can differentiate between the com-
key through the published commitments. ponents that are on the blockchain, i.e., the smart contracts,
and the components that are off-chain, i.e., the oracle nodes.
III. S YSTEM D ESIGN
For the on-chain components, we make use of three different
In this section, we propose the design of a voting-based smart contracts. The first of these is a registry contract, which
blockchain interoperability oracle. Initially, we give a brief is responsible for managing all oracle nodes (see Section III-C)
overview of the basic concept. We follow up with a descrip- and selecting the current aggregator (see Section III-E). Via
tion of the architecture and finally provide a comprehensive this smart contract, an oracle node discovers the other oracle
definition of the functionality. nodes and checks if they got selected as the current aggregator.
The next component is the oracle contract, which receives
A. Overview
requests from clients and sends them to all oracle nodes. Fur-
The proposed design for a voting-based blockchain inter- thermore, the oracle contract is also responsible for receiving
operability oracle (see Figure 1) allows clients to verify that and verifying the responses from the aggregator (see Sec-
a transaction is included in another blockchain. It uses an tion III-E) and transferring the rewards. Further, it also stores
off-chain aggregation mechanism (see Section III-E) based on all responses and makes them available to the clients.
BLS threshold signatures. The oracle nodes are divided into The last smart contract is the key contract, which is respon-
one aggregator and multiple validators which can collectively sible for managing the public key and initiating the generation

162

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
 Aggregator: A0 Aggregator: A1 ... Aggregator: An

...

Fig. 2. Aggregator selection mechanism

of new keys (see Section III-D). The off-chain component i.e., we already have the oracle problem in our proposed
consists of oracle nodes that can take on the tasks of the solution. One possibility of getting the public key into the
aggregator as well as the validator. blockchain is to use an on-chain aggregation mechanism.
However, this approach has the disadvantage that it gets more
C. Oracle Registration
expensive the higher the number of oracle nodes becomes.
The first step of an oracle node to join the decentralized These costs could be neglected if the frequency of generating
oracle is to register using the registry contract. During regis- new keys is very low. The same applies to the possibility of
tration, the oracle nodes must provide their host address and using a dispute mechanism, which is used by our prototype
BLS public key. Furthermore, a stake must be deposited which whereby only one oracle node submits the shared public key
is used as a measure against Sybil attacks (see Section V-A3). and the other oracle nodes can dispute the key. Finally, one
After an oracle node has registered, it is eligible to take part could also assume that several other oracles already exist
in the run of the DKG protocol. that can be used for this task. These could be oracles that
Another important point is that oracle nodes must also may be pursuing a completely different approach, or it is
be able to deregister. Furthermore, oracle nodes can also be already another instance of the proposed oracle solution. With
kicked out through a majority vote if they behave incorrectly the latter, however, we have a bootstrapping problem where
and lose their stake. the first instance cannot call an existing oracle. Therefore,
Particular care is taken to ensure that the system remains one would have to use one of the first two approaches or
fully operational. A distinction is made between the signature a centralized solution and change it later on.
threshold and the threshold of qualified validators. The valida-
tor threshold is required to ensure that the system continues to E. Off-chain Aggregation
work even if several validators fail or are misbehaving. Should
the number of validators fall below the validator threshold, a The task of aggregating the results and the signature shares
new key generation process is triggered. is taken over by an aggregator, which is one of the oracle
nodes. The aggregator changes in a cycle of n blocks based
D. Distributed Key Generation on a round-robin mechanism (see Figure 2). This has several
Each time a new oracle node registers, the registry contract advantages over an approach in which anyone can aggregate
checks whether a new run of the DKG protocol should be and submit the voting results: It prevents multiple simul-
initiated. For this, we set a certain number, which indicates taneous submissions of which only the first one would be
how many new registrations are necessary. Should the number successful, while all the other oracle nodes which also try
be reached, the registry contract calls the key contract to to submit an aggregation result have to pay the costs for the
trigger the start of the DKG protocol. The key contract then failed transaction without getting compensated. This would
broadcasts a generation event containing the threshold which lead to the problem that oracle nodes are not incentivized
should be used. to submit a result for which it is not certain whether the
On receiving the generation event, oracle nodes need to wait submission would be successful or not. Since this is relatively
a certain amount of time (e.g., measured in blocks) to ensure difficult to determine, nodes could become reluctant to act as
that every oracle node had a chance to receive the event since it an aggregator.
can take some time for a block to get propagated through the Another benefit is that this approach also consumes less
network. Then, the oracle nodes execute the DKG protocol bandwidth since not all oracle nodes try to aggregate a result,
with all currently registered oracle nodes. In our approach, which reduces the number of exchanged messages. The fact
we make use of Pedersen’s DKG protocol (see Section II-C). that the aggregator changes over time, still ensures that if an
However, other DKG protocols could also be used, as long as aggregator should fail, the next aggregator will take its place
the run of the protocol is made transparent through the usage and normal operation can be continued.
of blockchain technology. The aggregation mechanism (see Figure 3) starts when
The entire run of the DKG protocol takes place off-chain, a client sends a request to the oracle contract. After that,
which means that we need to get the generated public key as all oracle nodes are notified about the request (Step 1).
well as the number of qualified validators into the blockchain, Subsequently, the aggregator begins to collect results from

163

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
 9. verify result Oracle Nodes
7. recover 5. verifyTransaction

1. notifyRequest 2. getResults 3. getTransaction

Oracle
Aggregator Validators Blockchain B
Contract 8. result 6. resultShares 4. transaction

Blockchain A

Fig. 3. Aggregation mechanism

the validators (Step 2), whereby the request only needs to this would result in very high fees for the client, not only
contain the request number so that the validators know which because the client has to pay each validator individually but
request should be fulfilled. On receiving a request from the also because each transfer causes additional costs during the
aggregator, a validator retrieves the transaction from the target execution of the smart contract.
blockchain (Step 3 and 4), verifies the transaction (Step 5), and Therefore, we propose to only reward the aggregator for
returns the response consisting of the response to the request submitting the result. The aggregator gets compensated for
and the signature share (Step 6). the transaction costs, receives an aggregation reward, and
The aggregator collects results until it has at least threshold additionally has the chance to win the validation reward with
t identical results with valid signature shares. If the aggregator a certain probability. The probability is scaled super-linearly
does not receive at least t results with valid signature shares, it based on the deposited stake to encourage the creation of only
will not be able to recover the signature. This can happen, as one identity [20]. If the aggregator is not lucky and does not
there can be temporary inconsistencies in blockchain systems, win the validation reward, the reward is maintained by the
validators fail or behave incorrectly. oracle contract until an aggregator gets lucky enough to win
Regarding the first problem, however, one can assume that the accumulated validation rewards.
consistency will be achieved at some point (depending on the It is particularly important to ensure that the validators
source blockchain) and that the threshold of the validators are not able to predict whether the aggregator will win the
will agree. This is one of the advantages that is given by the validation reward. Otherwise, validators would benefit from
fact that this oracle is limited to providing data from other not providing the aggregator with an answer to be able to
blockchains. In this case, the aggregator can try again after a increase their own chances of winning when they become
while, or if the aggregator changes in the meantime, the new aggregators themselves (see Section III-E). Therefore, we
aggregator will take over the request and repeat the voting. leverage the unpredictable randomness provided by the signa-
If the aggregator has received enough shares, it recovers ture which is recovered by the aggregator to decide whether
the full BLS signature using Lagrange interpolation (Step 7). the aggregator receives the validation reward. In the case
After recovering the full BLS signature, the aggregator can of the aggregator, it does not matter whether it knows if it
submit the result to the oracle contract by providing the result will receive the validation reward before submitting, since the
and the signature (Step 8). The oracle contract then hashes aggregator is still encouraged to submit the result, as to at
the result to a point on the curve and checks the elliptic curve least receive the aggregation reward. As for the validators, they
pairing (Step 9). If the elliptic curve pairing is successful, are still incentivized to answer the current aggregator with the
the smart contract calculates the reward (see Section III-F) assumption that it will not receive the reward and thus increase
and transfers it to the aggregator. Finally, the oracle contract their winnable reward when it is their turn to be an aggregator.
notifies the client that the result is available. Here, however, Since a round-robin mechanism is used for aggregator
one could also pursue a different approach in which the client selection, care should be taken that the chance of winning the
also defines a callback function which is to be called when validation reward is not too high. Validators who were recently
the result gets submitted. In this case, other problems would selected as the aggregator have a reason to assume that another
have to be considered, such as the costs caused by the callback aggregator will win the validation reward during the time they
function. Furthermore, the result is then not easy to obtain for will have to wait to be selected again. They may be tempted
other clients. to stop validating until they believe otherwise. Therefore, the
F. Incentive Mechanism chance should be small enough such that the validators can
still assume that no one will win the reward in the current
Since the aggregator only submits a response including the
aggregation round.
data and the threshold signature, the oracle contract does not
have any information about the validators who were contacted,
IV. I MPLEMENTATION
which makes it difficult to reward validators directly. We can-
not rely on the aggregator to provide us with this information After defining the system design of our solution, we cre-
either, as it cannot be verified whether it is correct, as the entire ated a prototypical implementation. Our prototype enables
DKG protocol is carried out off-chain. Furthermore, it is not Ethereum-based blockchains to exchange data with each other.
particularly practical to reward each validator individually, as However, the solution can be implemented to work with other

164

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
blockchains. For this, the target blockchain needs to have smart implementation of a DKG protocol which is based on the
contract capabilities and enable elliptic curve pairing checks. protocol proposed by Pedersen (see Section II-C). For the
In this section, we discuss the used technologies as well as DKG protocol, we needed a broadcast channel, for which
the implementation of the smart contracts and the oracle node we opted for the IOTA tangle [21], as it enables fee-less
which is available as open-source software on GitHub1 . and publicly verifiable data exchange. Other broadcast chan-
nels (e.g., Ethereum) can also be used, but they may incur
A. Smart Contracts
additional costs. The oracle nodes use a Go client to create
For the implementation of the prototype, we decided in favor transactions and send them to an IOTA node. These are zero-
of Ethereum because it is one of the most popular second- value transactions that are only used to exchange messages
generation blockchains and accordingly a wide range of tools which are necessary to execute the DKG protocol.
is available. Another important factor was that Ethereum Furthermore, the oracle nodes must be able to communicate
already provides a precompiled contract that enables elliptic directly with one another. The aggregator must be able to
curve pairing checks on the alt bn128 curve. collect the results from the validators and all oracle nodes
The registry contract stores all oracle nodes in an iterable need a private channel to each other to distribute the private
mapping and provides clients with the necessary functions to shares during the execution of the DKG protocol. Therefore,
retrieve them. For the aggregator selection mechanism, we we make use of gRPC Remote Procedure Calls (gRPC) to
defined a threshold of six blocks after which the aggregator connect the oracle nodes.
will be switched. Further, after every third registration, the To interact with the smart contracts and retrieve data from
registry contract calls the key contract to trigger a new an Ethereum blockchain, the oracle nodes need access to an
execution of the DKG protocol. Ethereum node whereby we make use of the Go Ethereum
On receiving the call from the registry contract, the key client to connect to the Remote Procedure Call (RPC) server.
contract calculates the threshold based on the number of Further, we use a Go binding generator to create the coun-
currently registered oracle nodes and emits the key generation terparts of the smart contracts in Go to produce as little
event. For the threshold, we defined that the majority of all boilerplate code as possible.
registered nodes is necessary to produce a valid signature. For
submitting the key, we provide a function in the prototype via V. E VALUATION
which the public key can be set by one of the oracle nodes. In this section, we analyze the security and the costs of the
The public key can be disputed if the majority of oracle nodes proposed solution. This provides insight into if the solution
agree. is applicable, what problems can arise and what needs to be
When implementing the oracle contract, we especially paid considered.
attention to implementing the contract in a gas-efficient way.
Since storage operations are among the most expensive, we A. Security Analysis
have tried to keep the number of these low. If a client sends a To analyze the security of the oracle, we look at various
request to the oracle contract, the request is only emitted as an attack scenarios and the consequences that can result from
event and not saved in storage. This is possible because only them. In particular, we are looking at lazy voting, free loading,
oracle nodes need to be able to read the requests. However, Sybil attacks, and the key submission.
this approach involves more work for the oracle nodes since We can categorize the oracle nodes based on the Byzantine-
they have to filter the blockchain for past events in case they Altruistic-Rational (BAR) model proposed in [22], which has
missed some of them. already found application in other works for security analysis
As has already been mentioned before, we use a precom- in the area of blockchain technology, e.g., [23]: Rational
piled contract that allows pairing checks for the alt bn128 oracle nodes deviate from the protocol as long as they will be
curve to verify the BLS signatures submitted by the aggregator. able to increase their benefits by doing so. Byzantine oracle
These precompiled contracts are already existing contracts nodes, however, can unexpectedly deviate from the protocol
that run outside the EVM and perform more complex tasks. for unknown reasons, whereby it does not matter if it is
One of the advantages of these contracts is that they are intentional or unintentional misbehavior and whether they gain
usually cheaper. Further, we make use of the try and increment a benefit from it. Altruistic oracle nodes will always adhere
approach (see Section II) to hash the response on the curve. to the protocol no matter if the rational choice would provide
B. Oracle Node them with additional benefits.
The proposed oracle solution applies an incentive mecha-
The oracle node is implemented in the Go programming
nism (see Section III-F) to encourage all oracle nodes to follow
language. For the implementation, we used the advanced
the protocol. However, it should be mentioned that even if
crypto library Kyber2 . We adapted the library to work with
all incentives are aligned properly, rational oracle nodes may
the alt bn128 curve used by Ethereum. The library provides
deviate from the protocol. The reason for this is that also
the necessary packages for threshold BLS signatures and the
actors outside the oracle have to be taken into account. Hence,
1 https://github.com/pantos-io/ioporacle it may seem rational for oracle nodes to follow the protocol
2 https://github.com/dedis/kyber solely based on the applied incentive mechanism, but external

165

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
factors can influence their decision by providing better benefits applies to the proposed oracle solution where any number of
for arbitrary reasons. oracle nodes can register.
1) Lazy Voting: In the lazy voting problem, rational oracle We have already mentioned in Section III that oracle nodes
nodes do not deliver the correct result but always provide have to deposit a stake to make Sybil attacks more difficult.
the same response to maximize their benefits. If e.g., it is The intention is to make the creation of new identities expen-
the case that a certain result occurs particularly often, it can sive so that it becomes more difficult to control larger parts of
be more beneficial to always return the same result directly the oracle. On the other hand, we also make it more difficult
instead of executing the request. This could lead to an incorrect for honest oracle nodes to join the oracle. Therefore, the trade-
result being successfully submitted. In our proposed solution, off for a more Sybil-resistant oracle is less decentralization
this would mean that a lazy validator would always respond considering only oracle nodes that can provide the stake can
to the request “Is transaction tx included in blockchain B participate. Nevertheless, an attacker is still able to register
and confirmed by at least n blocks?” with true. Since it is multiple oracle nodes to be able to create more signature
more important for many use cases that a certain transaction shares, which enables the attacker to gain more voting power.
is included and confirmed, it can be assumed that requests In the worst case, an attacker could register threshold t or
will be answered more frequently with true than with f alse. more oracle nodes and decide on the result alone if it can
However, this problem can be circumvented by modifying provide the necessary stake. To provide better Sybil resistance,
the request. We expand the usual request and ask “In which we further encourage the creation of only one identity, by
block on blockchain B is transaction tx included and is it increasing the chance of winning the validation reward super-
confirmed by at least n blocks?” instead. This question forces linearly based on the deposited stake. As a result, it is more
lazy validators to read from blockchain B since otherwise, they beneficial for oracle nodes to create a single identity with a
cannot know in which block the transaction is contained. The higher stake than to split the stake between multiple identities,
lazy voting problem is also discussed in related work (see Sec- as this gives them a greater chance of winning the validation
tion VI-C) about decentralized oracles. reward. Therefore, if one is only interested in gaining more
2) Free Loading: For the creation of a valid signature, the benefits, this approach resembles the rational choice.
aggregator only needs to collect as many valid signature shares 4) Key Submission: The selected key submission mecha-
as the threshold t specifies. This means that in the best case nism also imposes some security risks. As has already been
only t validators have to execute the request. However, all discussed, the public key can be submitted by using an on-
other validators who have not contributed to the creation of chain aggregation mechanism, dispute mechanism, or another
the signature also have the chance to win the validation reward, oracle solution for the key submission (see Section III-D).
when selected as an aggregator. While the use of an oracle solution appears to be more cost-
The problem here is that some validators may never respond effective, we must be aware of the security risks that arise
for the aforementioned reason. Even though rational oracle from this approach.
nodes may be able to increase their benefits by not responding, A central oracle solution represents a single point of failure,
they should still be encouraged to respond. The reason for which can submit arbitrary public keys to then be able to create
this is that they minimize the risk of the aggregator not valid signatures. As a result, a single participant could gain full
being able to get enough responses, which leads to a lower control over the oracle. However, if one uses a decentralized
possible validation reward. Even if more than t validators approach, the risk is lower.
behave altruistically, it may be the case that no signature It must be ensured that both oracles, i.e., the oracle used
can be created due to possible inconsistencies. This indicates for the key submission and the interoperability oracle, are as
that it is more beneficial for the validators to always respond independent of each other as possible. Otherwise, oracle nodes
to requests. Above all, validators do not have to perform that participate in both oracles would be able to change the
any particularly resource-intensive tasks, which means that result in their favor. In the worst case, this would mean that
possible resource savings are low. a certain subset of oracle nodes could have complete control
3) Sybil Attacks: Another important aspect that must be over the oracle used for key submission and can thus select
considered is to what extent Sybil attacks are possible and the public key. This means that even if the attacker is unable
what the consequences are. A Sybil attack describes the threat to create more than threshold t oracle nodes in the interoper-
that single faulty participants can control multiple identities, ability oracle, it can get control over the interoperability oracle
which enables them to compromise larger parts of a system. if it can control the oracle for key submission.
Douceur [24] has shown that it is not possible to prevent such
attacks without a central authority except for conditions that B. Cost Analysis
are not practicable for large-scale distributed systems. Since We analyze the costs of the proposed solution by comparing
we are in the area of blockchain technology where we usually the implemented prototype with two alternative approaches
do not have a central authority, we have to consider such which do not make use of BLS threshold signatures. Ac-
attacks. Further, in permissionless blockchains, everyone is cordingly, we implement two additional oracle contracts (On-
allowed to join the system, whereby it is an easy task to create chain Oracle, ECDSA Oracle) which follow different aggre-
new identities by simply generating a new key pair. The same gation mechanisms. Furthermore, we compare the costs of

166

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
our approach with the costs incurred by ETH Relay [23], a On-chain ECDSA BLS
·105
novel relay scheme (see Section VI-C), to examine how well 5
our approach performs compared to state-of-the-art schemes.
To ensure repeatability, the implementations, as well as the 4

Gas Consumption
evaluation scripts, are also included in the open-source project
on GitHub (see Section IV). 3
The On-chain Oracle implements an on-chain aggregation
mechanism whereas each oracle node calls the oracle contract 2
to submit a result. The ECDSA Oracle makes use of Elliptic
Curve Digital Signature Algorithm (ECDSA) signatures to 1
verify the result. In contrast to our proposed scheme, an 0 5 10 15 20 25 30
aggregator does not submit a single BLS signature but rather # of Oracle Nodes
submits several ECDSA signatures that are verified by the
Fig. 4. Gas consumption of the different aggregation mechanisms
oracle contract. Since there is no reasonable source of ran-
domness for either of these variants, the reward is paid out to ·105
each oracle node that is part of the majority.
For the experiment, we use a private Ethereum blockchain 3.5
based on the Muir Glacier hard fork, on which we deploy all

Gas Consumption
smart contracts. In this experiment, we request the verification
of a transaction with every type of the aforementioned aggre- 3

gation mechanisms. Besides, we are changing the number of

participating oracle nodes to be able to determine how the
2.5
costs develop with an increasing amount of oracle nodes.
By comparing the different mechanisms (see Figure 4),
it can be seen that the costs for the on-chain aggregation BLS Result Submissions

mechanism are considerably higher than those of the other

Fig. 5. Gas consumption of the result submission with BLS signatures
two. This is due to the reason that for the on-chain mechanism
more storage space is needed and each participant has to
create a transaction to submit its vote. In comparison, the gas with a standard deviation of 3,679 gas. As a result,
other mechanism in which an aggregator only submits several submitting 100 block headers consumes around 28,404,100
ECDSA signatures, is more cost-efficient. The problem here, gas. Using our presented approach, we can submit 110 results
however, is that the costs continue to rise with the number that incur roughly the same gas costs as the 100 block header
of oracle nodes, even though the verification of ECDSA submissions of ETH Relay. The costs for the actual request
signatures is a relatively cheap operation on the Ethereum must also be taken into account. In the case of ETH Relay,
platform. the relay contract needs to carry out a SPV and check the
Our proposed solution based on BLS threshold signatures, membership of the block in the longest chain, which means
on the other hand, causes almost constant costs that are that the costs increase as the search depth increases. In the
independent of the number of oracle nodes, since only one case of our oracle-based relay, however, a request only ever
signature has to be verified. The costs are only almost constant consists of an event being emitted, whereby the result can
as the try and increment approach is used for hashing. As simply be accessed directly, which results in constant costs.
can be seen in Figure 5, submitting the result consumes on At the moment, the application of interoperability solutions
average 257,607 gas with a standard deviation of 21,671 gas. is a rather infrequent occurrence, which presumably suggests
Verifying a BLS signature is an expensive operation, but it is that not many requests are made. In the worst case, this could
considerably more cost-efficient as the number of oracle nodes mean that not a single transaction has to be verified for 100
increases. With more than three oracle nodes, it is already blocks. With ETH Relay, the blocks still have to be submitted
cheaper than the on-chain mechanism and with more than and thus the costs must be sustained. Hence, keeping the relay
15 nodes, it is also cheaper than the ECDSA mechanism. alive is a huge burden since these submitted block headers do
Therefore, by using this approach we can achieve a higher not yield any profit for the submitter. In contrast, our presented
degree of decentralization without increasing the costs. oracle-based solution does not incur any costs in this scenario,
Now that we have compared our approach with two dif- as every request is fulfilled on demand. However, if the number
ferent oracle solutions, we examine how the costs differ of requests increases drastically such that it is more than
compared to a relay solution. To conduct this analysis, we 110, ETH Relay would be the more cost-efficient solution.
choose ETH Relay because it is an advanced relay solution One must also note that in this case further adjustments can
that is specifically designed to be more cost-effective. For be made to the oracle such that every request enables the
the comparison, we assume a period of 100 blocks. Every verification of all the transactions within a block, rather than
block header submission in ETH Relay consumes 284,041 a single one, by providing the Merkle root of such a block.

167

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
 VI. R ELATED W ORK features of the underlying Transport Layer Security (TLS)
So far, different blockchain interoperability solutions have protocols 1.0 and 1.1.
been proposed. These include hash-locks, relay solutions, and With Town Crier, the authors of [29] propose another
oracles. In the course of this section, we examine solutions centralized blockchain oracle, which uses the HTTPS/TLS
that are related to our work. protocol and additionally utilizes trusted hardware to ensure
the authenticity of the data. The implementation uses Intel’s
A. Hash-Locks Software Guard Extensions (SGX) which allows the execution
Hash-locks are a well-known technique to enable a basic of a process in a protected address space which guards the
form of blockchain interoperability without oracles and relays, process against malicious software running outside of the
e.g., to realize atomic cross-chain swaps [25]. Atomic swaps enclave but also from various hardware attacks. While both
allow multiple parties to exchange their assets across mul- of the aforementioned oracle services offer a solution to the
tiple blockchains. The involved parties make use of Hashed oracle problem, the high level of centralization poses a major
Timelock Contracts (HTLCs) to escrow their assets with a problem regarding scalability and single points of failure.
hashlock h and timelock t. Ownership of the asset is only In [30], the authors present ChainLink, a decentralized
transferred if the receiver can provide the secret s such that oracle network. ChainLink offers a reputation-based voting
h(s) = h before t expires. However, attention must be system whereby users can issue queries to the ChainLink smart
paid to specify the right timelock values and use the correct contracts. Queries are executed by the selected oracle nodes
deployment order of the contracts. which retrieve the results from different or overlapping sets of
data sources. These results are aggregated by a smart contract
B. Relays which is also responsible for the calculation of the outcome.
Frauenthaler et al. [23] propose ETH Relay, a novel relay Breidenbach et al. [31] further introduce a new off-chain
scheme for Ethereum-based blockchains. A validation-on- reporting protocol for ChainLink, which however follows a
demand pattern is used to keep the operating costs low by re- different approach compared to our solution.
ducing the number of expensive full block header validations. Peterson et al. [32] propose a decentralized oracle and
Instead of validating every block header when it is submitted, prediction market platform called Augur. Within Augur, users
off-chain clients have a certain time frame in which they can can create prediction markets to get information that is
dispute submitted block headers. To make SPVs more efficient, external to the system. Market participants trade shares of
the authors also optimize the traversal of the blockchain, by those markets and reporters can vote by staking their REP
jumping from branching point to branching point instead of tokens (Augur’s native token) on one possible outcome. The
iterating over the whole data structure. While the authors reached consensus of reporters is considered as the outcome.
achieve a remarkable cost reduction over traditional relay Depending on the result, reporters receive a reporting fee
solutions, the costs remain quite high. from the markets. Augur’s incentive mechanism encourages
In [26], the authors present zkRelay, which is a relay participants to behave honestly to maximize their profits, while
solution that utilizes off-chain computations to validate batches misbehaving participants get penalized.
of block headers through the usage of Zero-Knowledge Suc- The authors of [33] propose ASTRAEA, another decentral-
cinct Non-Interactive Argument of Knowledge (zkSNARK) ized voting-based blockchain oracle. Submitters, voters, and
proofs. Since these proofs are generated off-chain, the smart certifiers play a voting game to decide on the truth value
contract only needs to be able to verify the proof, removing of boolean propositions. These propositions are added to the
the necessity of storing and validating every submitted block system by submitters, who pay fees to receive an answer to
header, whereby only the last block header of a batch is stored. the submitted proposition. Voters play a low-risk/low-reward
Although the solution offers improvements in the form of game by depositing a stake to answer a random proposition.
scalability and cost optimization, there are tradeoffs in terms Certifiers on the other hand play a high-risk/high-reward game
of delay and hardware resources. Our solution, however, can whereby they can choose a proposition to certify but have to
immediately retrieve data from the source blockchain and has place a high stake.
no excessive RAM consumption since no complex proofs are Merlini et al. [34] propose an extension to this protocol to
generated. solve the lazy equilibrium problem, whereby all voters report
the same answer on all propositions. The authors describe a
C. Oracles paired-question protocol, in which submitters add queries with
Provable [27] (formerly known as Oraclize) is a centralized two antithetic questions, whereby the oracle additionally needs
oracle service for various blockchain platforms, e.g., Ethereum to check if both answers converge to different outcomes. With
and EOS. The Provable blockchain oracle utilizes TLSnotary this approach, the protocol ensures that honest voters receive
authenticity proofs [28] to attest the authenticity of the data higher rewards than lazy voters.
retrieved from the originating source. Within TLSnotary, an While the approaches discussed above are interesting solu-
auditee can prove to an auditor the authenticity of information tions to the oracle problem, they are not specifically aiming
retrieved from a Web server that is using the Hypertext at providing blockchain interoperability and also implement
Transfer Protocol Secure (HTTPS) protocol, by utilizing the their mechanisms on-chain, which results in high costs.

168

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.
 VII. C ONCLUSION [13] A. Shamir, “How to share a secret,” Communications of the ACM,
vol. 22, no. 11, pp. 612–613, 1979.
Research on closing the gaps between different blockchains [14] P. Feldman, “A practical scheme for non-interactive verifiable secret
has already led to several concepts and solutions. However, sharing,” in 28th Annual Symposium on Foundations of Computer
Science. IEEE, 1987, pp. 427–438.
these are usually too expensive or very resource-intensive. [15] T. P. Pedersen, “Non-interactive and information-theoretic secure ver-
To overcome these issues, we propose a voting-based ifiable secret sharing,” in Annual international cryptology conference.
blockchain interoperability oracle that uses an off-chain ag- Springer, 1991, pp. 129–140.
[16] ——, “A threshold cryptosystem without a trusted party,” in Work-
gregation mechanism based on BLS threshold signatures. The shop on the Theory and Application of of Cryptographic Techniques.
oracle nodes are divided into one aggregator and multiple Springer, 1991, pp. 522–526.
validators and generate a distributed private key to collectively [17] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin, “Secure distributed
key generation for discrete-log based cryptosystems,” in International
decide on the result of a request. Validators read the data from Conference on the Theory and Applications of Cryptographic Tech-
the other blockchain and sign it with their private key share. niques. Springer, 1999, pp. 295–310.
The selected aggregator collects the results and the signature [18] A. Kate and I. Goldberg, “Distributed key generation for the internet,”
in 2009 29th IEEE International Conference on Distributed Computing
shares from the validators to create a valid signature which is Systems. IEEE, 2009, pp. 119–128.
submitted to and verified by the oracle contract. Our evaluation [19] E. Kokoris Kogias, D. Malkhi, and A. Spiegelman, “Asynchronous
shows that the proposed solution is more cost-efficient than distributed key generation for computationally-secure randomness, con-
sensus, and threshold signatures.” in 2020 ACM SIGSAC Conference on
other oracle solutions and also incurs lower costs than state- Computer and Communications Security. ACM, 2020, pp. 1751–1767.
of-the-art relay schemes depending on the request rate. [20] Y. Cai, G. Fragkos, E. E. Tsiropoulou, and A. Veneris, “A truth-inducing
In future work, we will investigate how we can improve sybil resistant decentralized blockchain oracle,” in 2020 2nd Conference
on Blockchain Research Applications for Innovative Networks and
Sybil resistance and the submission of the shared public key. Services (BRAINS). IEEE, 2020, pp. 128–135.
We will also examine if there is still potential to further reduce [21] S. Popov, “The tangle,” White paper, 2018.
the costs by applying other signature schemes and enabling [22] A. S. Aiyer, L. Alvisi, A. Clement, M. Dahlin, J.-P. Martin, and
C. Porth, “Bar fault tolerance for cooperative services,” in Twentieth
requests such that multiple transactions can be verified. ACM Symposium on Operating Systems Principles. ACM, 2005, pp.
45–58.
ACKNOWLEDGMENT [23] P. Frauenthaler, M. Sigwart, C. Spanring, M. Sober, and S. Schulte,
“ETH relay: A cost-efficient relay for ethereum-based blockchains,” in
The financial support by the Austrian Federal Ministry for 2020 IEEE International Conference on Blockchain. IEEE, 2020, pp.
Digital and Economic Affairs, the National Foundation for Re- 204–213.
search, Technology and Development as well as the Christian [24] J. R. Douceur, “The sybil attack,” in International Workshop on Peer-
to-Peer Systems. Springer, 2002, pp. 251–260.
Doppler Research Association is gratefully acknowledged. [25] M. Herlihy, “Atomic cross-chain swaps,” in Proceedings of the 2018
ACM Symposium on Principles of Distributed Computing. Association
R EFERENCES for Computing Machinery, 2018, p. 245–254.
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Decen- [26] M. Westerkamp and J. Eberhardt, “zkRelay: Facilitating Sidechains
tralized Business Review, p. 21260, 2008. using zkSNARK-based Chain-Relays,” in 2020 IEEE European Sym-
[2] S. Saberi, M. Kouhizadeh, J. Sarkis, and L. Shen, “Blockchain tech- posium on Security and Privacy Workshops. IEEE, 2020, pp. 378–386.
nology and its relationships to sustainable supply chain management,” [27] Provable. The provable blockchain oracle for modern dapps. Accessed:
International Journal of Production Research, vol. 57, no. 7, pp. 2117– 2021-02-24. [Online]. Available: https://provable.xyz
2135, 2019. [28] TLSnotary. (2014) Tlsnotary - a mechanism for independently
[3] E. J. De Aguiar, B. S. Faiçal, B. Krishnamachari, and J. Ueyama, “A audited https sessions. Accessed: 2021-03-01. [Online]. Available:
survey of blockchain-based strategies for healthcare,” ACM Computing https://tlsnotary.org/TLSNotary.pdf
Surveys, vol. 53, no. 2, 2020. [29] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier:
[4] S. Schulte, M. Sigwart, P. Frauenthaler, and M. Borkowski, “Towards An authenticated data feed for smart contracts,” in 2016 ACM SIGSAC
blockchain interoperability,” in International Conference on Business Conference on Computer and Communications Security. ACM, 2016,
Process Management. Springer, 2019, pp. 3–10. p. 270–282.
[5] R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia, “A Sur- [30] S. Ellis, A. Juels, and S. Nazarov. (2017) Chainlink: A decentralized
vey on Blockchain Interoperability: Past, Present, and Future Trends,” oracle network. Accessed: 2021-02-24. [Online]. Available: https:
arXiv:2005:14282, 2020. //link.smartcontract.com/whitepaper
[6] G. Wood et al., “Ethereum: A secure decentralised generalised transac- [31] L. Breidenbach, C. Cachin, A. Coventry, A. Juels, and A. Miller.
tion ledger,” Ethereum project yellow paper, vol. 151, 2014. (2021) Chainlink off-chain reporting protocol. Accessed: 2021-07-16.
[Online]. Available: https://research.chain.link/ocr.pdf
[7] H. Al-Breiki, M. H. U. Rehman, K. Salah, and D. Svetinovic, “Trust-
[32] J. Peterson, J. Krug, M. Zoltu, A. K. Williams, and S. Alexander.
worthy blockchain oracles: review, comparison, and open research
(2019) Augur: a decentralized oracle and prediction market platform
challenges,” IEEE Access, vol. 8, pp. 85 675–85 685, 2020.
(v2.0). Accessed: 2021-02-24. [Online]. Available: https://augur.net/
[8] J. Heiss, J. Eberhardt, and S. Tai, “From oracles to trustworthy
whitepaper.pdf
data on-chaining systems,” in 2019 IEEE International Conference on
[33] J. Adler, R. Berryhill, A. Veneris, Z. Poulos, N. Veira, and A. Kastania,
Blockchain. IEEE, 2019, pp. 496–503.
“Astraea: A decentralized blockchain oracle,” in 2018 IEEE Interna-
[9] V. Buterin, “Chain interoperability,” R3 Research Paper, 2016.
tional Conference on Internet of Things (iThings) and IEEE Green
[10] D. Boneh, B. Lynn, and H. Shacham, “Short signatures from the weil
Computing and Communications (GreenCom) and IEEE Cyber, Physical
pairing,” Journal of Cryptology, vol. 17, no. 4, pp. 297–319, 2004.
and Social Computing (CPSCom) and IEEE Smart Data (SmartData).
[11] A. Boldyreva, “Threshold signatures, multisignatures and blind sig-
IEEE, 2018, pp. 1145–1152.
natures based on the gap-diffie-hellman-group signature scheme,” in
[34] M. Merlini, N. Veira, R. Berryhill, and A. Veneris, “On public decen-
6th International Workshop on Theory and Practice in Public Key
tralized ledger oracles via a paired-question protocol,” in 2019 IEEE
Cryptography. Springer, 2002, pp. 31–46.
International Conference on Blockchain and Cryptocurrency. IEEE,
[12] D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “Aggregate and
2019, pp. 337–344.
verifiably encrypted signatures from bilinear maps,” in International
Conference on the Theory and Applications of Cryptographic Tech-
niques. Springer, 2003, pp. 416–432.

169

Authorized licensed use limited to: UNIVERSIDADE DE SAO PAULO. Downloaded on August 05,2024 at 14:36:53 UTC from IEEE Xplore. Restrictions apply.