Oracle-platform

Alexander Herrmann
No Institute Given

Abstract. Decentralized applications (Dapps) and Decentralized Autonomous Organizations (DAOs) executed via smart contracts on blockchains
are starting to build a growing ecosystem. Many of these Dapps and
DAOs have an urgent need for a very reliable information feed connecting the blockchain ecosystem with traditional centralized services and
information. The Oracle-platform will be an open source platform, which
Dapps and DAOs can utilize to build a state of the art reliable information feed for their services. Using verifiable hosting environments and a
split game theory enforced with smart contracts, this Oracle-platform
will be outstanding in terms of security and reliability.
Keywords: DAO, decentralized price feeds, Ethereum

Oracle-platform

The Oracle-platform is a open source platform providing the framework to build

information feeds for DAOs and Dapps. Especially smaller Dapps or DAOs will
have the challenge that their customers might not trust them since their services rely on external information. Single smaller Dapps or DAOs will not have
knowhow and valuation of their company for putting on stake to build up a
reliable information feed. But if many small Dapps or DAOs co-operate and
put their collective financial power on stake, very secure information feeds can
be built. This paper explains how an Orcale-platform can be put together in
a efficient and very secure way. The rough idea is the following: The actual
information feeds of the Oracle-platform will be managed in by a Oracle-DAO
integrated in the platform. Shareholders of the Oracle-DAO elect paid delegates,
which are setting up information feed servers on verifiable trusted computing environments. If DAOs and Dapps issue requests to these information feed servers,
they will deliver these in a predefined way to the Dapps. In case users observe
that the verifiable, information feed servers are not working properly, anybody
in the block-chain ecosystem can vote Ether and DAOs shares, which are connected to the platform, in order to resolve whether the information feed was
indeed not working properly. Based on the voting, user funds and DAO shares
will be split: There will exists DAOs, which are containing the truth about the
feeds and DAOs which do contrary truth about the feeds. Using such an splitting mechanism and 2 stage betting protocol, this process is very secure from
manipulation attacks and will reveal the truth about a decentralized information
feed.

Oracle-DAO set up and escalation betting

Oracle-platform has two many tasks: managing the information feeds by the
Oracle-DAO and managing the shares of partner DAOs.
2.1

Managing information feed

Shareholders of the Oracle-DAO elect information feed server administrators and

delegates for negotiations with other companies. Delegates are important, since
they attract new DAO partners, which will increase the revenue and Oracle-DAO
security. Equally important are information feed administrators, since they are
setting up and maintaining the servers, as described in the next chapter. One
important feature of the feed server is that they are set up in way that any user
can easily verify whether they are currently working correctly. Furthermore, the
Oracle-DAO is managing also the escalation process, in case it is questioned by
users, whether the information feed is working properly.
2.2

Managing shares of partner DAOs

Now, suppose the Oracle-platform has the partner DAOs: DAO-1, DAO-2, ...,
DAO-N, which are also traded on chain and have a market capitalization of
M1 , M2 , ..., MN nominated in Ether. Furthermore, the Oracle-DAO itself has
also shares with a valuation of M0 . The shares of the partner DAOs should be
linked in a way such that:
1. the DAO-Oracle is knowledgeable about the market capitalization of M1 , M2 , ..., MN
2. the DAO-Oracle can create a copy of DAO-I: DAO-I
3. the DAO-Oracle can buy all shares of DAO-I for the current market price
MI .
Using this setup, the following escalation process can be implemented, in case
the Oracle-DAOs server are not working a predefined way.
2.3

Escalation process

Now, let us assume that the Oracle-DAO information feed is broken. Which
scenarios of broken feeds can happen, is described in the next sections as well.
Due to the set up of servers anybody can verify this and report this event to the
Oracle-DAO smart contracts. Then the Oracle-DAO will initiate a betting about
the truth in a similar way as the Schelling coin mechanism: Anyone can either
bet Ether or shares of DAO-0 to DAO-N on the outcome of the questions: Was
this report saying that the feed is broken issued to the Oracle-DAO rightfully?
Let us define the valuation of Ether and shares from the DAOs bet for the fact
that the oracle is working: W and that it is not working: NW. Furthermore, let
us define:
M = MO + M1 + M2 + ... + MN
(1)
Then we have following cases:

Case 1: W < N W and W < 45 M In this case, most of the Ether or shares
have been bet for the fact that the oracle is not working properly. Thus the
smart contracts will assume that the oracle is indeed not working properly. The
smart contracts will stop any settlements on recent feed information. Everyone,
who bet on and contributed to NW will be reward by distributing the Ether and
shares bet on W to them.
Case 2: N W < W and N W < 45 M In this case, most of the Ether and
shares have been bet for the fact that the oracle is working properly. Thus the
smart contracts will assume that the oracle is indeed working properly. Oracle services will continue. Everyone, who bet on and contributed to W will be
rewarded by distributing the Ether and shares bet on NW to them.
Case 3: N W > 54 M and W > 45 M In this case, a lot of Ether and shares
has been spent on the both sides of the bets. It might be that the betting process
is attempted to be manipulated by a very big player. In order to counter that a
new escalation stage is needed: risk free betting with DAO split.
Once this last escalation level has been reached, the smart contracts are
doing something drastic. They are using the funds from the first escalation stage
and exchange Ether for the shares from all DAOs: DAO-1, DAO-2,...,DAO-N
and Oracle-DAO at the last price of the shares nominated in Ether before the
escalation process started. Every shareholder of one of the DAOs will receive
the net worth of their shares paid in Ether, but in return the smart contracts
acquiring their shares.
The next step is that all DAOs will get split. Each DAO-k will get a copy
DAO-K and the Oracle-DAO will get a copy Oracle-DAO. DAO-K will be a
fully working DAO, but the Collateral and holdings of Ether of the DAO-K will
only be kept in DAO-K and not in DAO-K.
Now everything is set up for the final risk free betting. Now everyone in the
whole Ethereum ecosystem can again bet whether the oracle was working (W)
or was not working (NW) properly. One simply votes by sending Ether and his
vote. After 3 weeks of voting, we have a certain amount of Ether spend on W:
#W and a certain amount of Ether spend on NW: #N W .
Case 3.1: #W > #N W In this case, the majority bet that the oracle was
working. Now, everyone who spent Ether in the second escalation get its Ether
back. Also, everyone who voted for W will get a proportion of 30 percent of
shares from the DAO-1 to DAO-N proportionally to the amount of Ether he
bet on. The people voted for NW will get as rewards 30 percent of shares of
the DAO-1 to DAO-N. The first stage escalation bet will be resolved using the
outcome of this second escalation bet: people who bet for NW will lose all their
funds inputs, but will be rewarded with 70 percent of shares of the DAO-1 to
DAO-N. And people who bet for W in first escalation will get rewarded with
70 percent of shares of DAO-0, to DAO-N and will receive in total 90 percent of
their fund inputs.

Case 3.2: #N W > #W In this case, the majority bet that the oracle was
not working. Now, everyone who spent Ether in the second escalation gets its
Ether back. Also, everyone who voted for NW will get a proportion of 30 percent
of shares from the DAO-1 to DAO-N proportionally to the amount of Ether he
bet on. The people voted for W will get as rewards 30 percent of shares of the
DAO-1 to DAO-N. The first stage escalation bet will be resolved using the
outcome of this second escalation bet: people who bet for W will lose all their
funds inputs, but will receive 70 percent of shares of the DAO-1 to DAO-N.
Furthermore, people who bet for NW in first escalation will get rewarded with
70 percent of shares of DAO-0, to DAO-N and will receive in total 90 percent of
their fund inputs.
Additional security measurement for second escalation stage Customers
of all Dapps and DAOs should have the chance to settle their financial products/services with the last price/information feed available before the report of
a broken information feed, if the second escalation stage has been reached.
Using this approach, customers of the DAO-1 to DAO-N can comfortably
leave the DAO service without any risk of losing much money. In case the second
escalation betting is not revealing the truth in their opinion, they use this exit
in order to be not depended on a non-reliable information feed. They can use it
also in order to switch from DAO-I to DAO-I - the newly created DAO.
As shown later, the costs of getting into the second escalation stage are very
high and can be increased by adding more DAOs to the DAO-platform. This is
why the platform can be built in such a way that is always very unprofitable to
push the first escalation betting stage to the second stage for a price manipulation
attack (cp. 5).
Incentive model: The amount an attacker must spend for getting into the
second escalation stage is:
4
4
M = (MO + M1 + M2 + ... + MN )
5
5

(2)

Since the second stage betting is risk free, he probably can not over vote the
majority of honest betters, if he does not bribe them. If the honest better is
revealing the truth, he will be awarded a proportion of valuable shares, which
should have a worth of around M. But if the honest better bets for the manipulator, he will get worthless shares of DAOs, which have no proper working
feed. Thus the normal reward for betting against the truth is just 0. Hence a
possible manipulator needs to hand out a bribe of at least 0.3 M + epsilon.
Here, epsilon stands for the additional bribe that users are getting for voting
for the manipulator. This bribe would need to be shared among all people, who
bet against the truth and for the manipulator. Thus the total cost for an attack
should be:
4
(3)
Cost = M + (0.3 M + epsilon)
5

If the attack is successful, the manipulator would get 90 percent of his stake from
the first escalation bet back and he would also get the worthless DAO shares.
Hence, we have
Revenue = 0.9 M + 0
(4)
Thus, he ends with a loss of
Balance = Revenue Costs = 0.1 M (0.3 M + epsilon)

(5)

Taking the unrealistic scenario that an attacker can manipulate the betting
procedure without any bribing, he would still lose 0.1 M ;

3
3.1

Set up of an information/price feeds

Machine Images on Verifiable Computation Environments

This method has been known for quite some time in block-chain research [2]. On
Devcon2 Mircrosoft announced that they will offer this service of an verifiable
and trusted computation environments as special middleware for blockchains.
[1]. We will show quickly the original idea, in order to show the reader what is
happening under the hood. The concept for a deployment on AWS from [2] is
to create a machine image with a set of programs and scripts on a server and
publish all the information needed to enable everyone to verify that right now
exactly this published machine image is running at a dedicated server provider.
Let us call this machine image with the set of programs and scripts for the
price feed oracle. Imagine this oracle machine image is running on major SaaS
providers, as for example Amazon Web Services, Google cloud platform or Mircosoft Azure and is sending information signed with private keys protected by
dedicated Hardware Security Module (HSM) [4] to the block-chain. Smart contracts on the block-chain are then verifying the information, comparing and
averaging them to calculate an official price feed and signaling possible irregularities in the data. This way, a solid information flow from central servers to
smart contracts is built. Of course, this method has weaknesses, as for example,
what happens if oracle server operators collude and decide to sign wrong information with their private keys from the oracle server. But in such a scenario
other methods will save the information feed. First, we describe the details of
this method:
technical setup In order to demonstrate the method described above, we describe how to set up an oracle server.
The oracle server is supposed to run the following software:
a client software that reads price feed requests from the block-chain
a script that performs the requested price feed request via TLS
a client software that creates transactions for the block-chain with price feed
information

Moreover, there must be two application programming interfaces (API)

One API for publishing all answered price feed requests
One API for serving the history of machine images running on the server
The oracle can be set up performing the following steps:
1. Create an instance from a public machine image and modify the software
according to oracles needs.
2. Create a snapshot of the machine image/volume and make that snapshot
public including its Snapshot ID.
3. Describe all the modifications applied to the initial machine image, so that
anyone could perform the same actions in order to reproduce the file tree
hashes of the public snapshot.
4. Starting a server instance and submit its private key for signing transactions.
5. Provide a server API giving the history of machine image running on the
server.
Once these steps are done, we have a basic price feed, which can only be
manipulated by the oracle server administrator or the hosting company. Both
sources of manipulation can be removed by the following approach.
The hosting company is not a concern, since an oracle server can be set up at
different hosting companies as for example Google, Amazon and Microsoft and
their information are compared on the block-chain. If only one hosting company
is manipulating the price feed, smart contracts identify this price feed easily
and sort it out. Let us call the event, in which many of these companies are
tampering their oracle servers at the same time, company tampering. This event
is very unlikely and it can be handled via the moderated escalation betting
process.
The other concern is due to server administrators. They could either detach
the machine image or abuse private keys to sign arbitrary information. Certainly,
one malicious oracle operator can be easily sorted out on the block-chain. But
even if the majority of oracle operators collude for something malicious, our price
feed system can still defend its users and penalize these oracles. The big advantage about this setup is that anybody can see easily whether oracles are working
correctly. Using the server API provided by the hosting company, everybody
sees whether the right server images are running. Furthermore, by comparing all
public transactions signed by the private key of the server and the listed transaction on the oracle API, everybody sees whether the private keys have been
misused. Let us call the event in which many of the oracle server administrators
collude and manipulate this price feed oracles conspiracy. This event would be
obvious to everyone via the hosting API. Hence, it could be easily reported into
the block-chain and smart contracts can initiate the required escalation betting.
These escalation betting has been describe in the previous section.
3.2

Security analysis for Oracle-platform information feed

The Oracle-platform has three major advantages over other information feed
provider:

High and adjustable manipulation costs The biggest advantage is that

small DAOs, which do have only a small market capitalization can link themselves to other DAOs and use their cumulative market capitalization to protect
themselves against any manipulation attacks. Depending on the security requirements, DAOs can join different Oracle-platforms with different cumulative
market/protection capitalization. Also, the attack costs measured with respect
to the market capitalization of the DAO is very high. The costs are about 100
percent of the market capitalization and the capital to start the attack is about
200 percent of market capitalization 3. Whereby other DAOs voting mechanism
can usually be manipulated with 50 percent of tokens or less. Hence, the attack
costs are only 50 percent of the market capitalization. Although one has to keep
in mind, that the market capitalization of a DAO can rise significantly if an
attacker needs to acquire so many tokens.
Decentralized and open truth finding method Many other oracles, as for
example used by the Augur project are closed in the sense that only token holders can vote in order to find the truth. This is critical since quite often token
holders are not well decentralized and there might be a dominating stakeholder,
who could abuse his power. In contrast in the oracle platform anybody can vote
and have a say. Hence we have a platform with a complete decentralized structure, which can not be manipulated by any centralized entity.
Below are some more issues and their resolution, which can happen:
Oracle servers get hacked If one or two oracle servers get hacked it will not
be a problem, since all price feeds of all oracles will be compared on-chain by
smart contracts and deviations can easily be sorted out. That all oracle servers
get hacked at the same time is very unlikely. If it really happens, no customer
funds are at risk, due to the nature of the escalation betting process.
Hosting companies of oracles tamper with their API giving machine
image info In the case of the event company tampering 3.1, trusted persons of
the price feed provider will probably realize this event first and the escalation
process will be started. Since this should be reported by news and oracle admins,
there should be a fast convergence of opinions. Via the escalation process, the
Oracle-DAO will come to the conclusion that the oracle system is not working or
at least it will be pushed to the second escalation phase, and every customer/user
can settle derivatives with the last prices available.
Central price feeds are broken Oracle software should not only request
price feeds from one central server but from many. For example, to report the
Ether/USD price, oracles should report a special average value of all Ether/USD
trading exchanges, so that it does not have any effect if one central server is
reporting wrong data.

Manipulation of market and enforcing settlement Another attack vector

would be that Mr. Malicious is pushing the price of a financial instrument in
a DAO and once the price is high, he could initiate the escalation process. If
he is able to bring the escalation to the last stage, he will be allowed to settle
his derivatives with very good prices. This attack vector is very unlikely to be
profitable for the attacker, since the cost of the attack is a big portion of the
Oracle-DAO and its partner DAOs market capitalization, see the first chapter.
3.3

Conclusion of security model

Concluding from previous section, this price feed model has only two major
attack vectors: 1st many oracle servers get compromised at the same time and
2nd the escalation betting does not reveal the reality.
The first attack vector is very unlikely to succeed, if the DAO chooses server
admins carefully, oracle servers are hosted at different companies and if these
oracle servers are constantly reviewed for their trustworthiness. Also, there is no
direct incentive to compromise the price feeds, since an attacker can not profit
from it. And even it happens the escalation process will protect all users funds.
The second attack vector is also very unlikely to succeed and even when
the attacker succeeds to push a new subjective truth into the system, he will
do this with a huge loss. Furthermore, user funds are never at risk, due to the
allowance of settlement with the last price feeds that were confirmed before the
attack.
Hence, DAOs using this Oracle-platform, as for example a derivative marketplace DAO, should be as secure as a traditional exchange regulated by governments.

References
1. https://github.com/Azure/azure-blockchain-projects/blob/master/bletchley/bletchleywhitepaper.md
2. https://bitcointalk.org/index.php?topic=301538.0
3. http://www.oraclize.it/
4. https://aws.amazon.com/cloudhsm/
5. https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universaldata-feed/
6. https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incompleteterminology-guide/
7. https://tlsnotary.org/