[Music]
hello to everyone thank you for having
me here today
my name is Thomas Burton I'm the CEO of
Oracle eyes during this presentation I
will start with a brief recap of the
Oracle problem and how Oracle eyes is
trying to solve it and I will do a deep
dive on the authenticity proofs and on
how we could verify them on chain so we
have already seen in the previous
presentations what it means the what the
problem the Oracle problem really is so
we know that in decentralized networks
like on etherium it's really complicated
to reach out to external data to data
which we find in different contexts is
like for example on the web but in
general this is something we want
because of the centralized applications
to have value because those application
might depend on external real world data
so it's important to define those three
different entities as in different
Oracle models than others
some of those are merged so specifically
we know that the data is the any piece
of code that requires the external data
then we have the Oracle and the data
source the data source is not
necessarily the same party as the Oracle
itself it's easy to define the Oracle as
the Oracle is the party that sends the
data to the blockchain but the data
source might as well be a different
party than the Oracle so we have seen in
the Thomson Reuters presentation a model
where basically the data source and the
Oracle are the same entity but in
general what we want is be able to reach
out to any external data sources without
having the data sources to adapt to the
blockchain this is because there are so
many external data sources
available on the internet that is quite
quite unlikely that in the short term
they will add up to the blockchain they
will start signing the data and sending
it wherever we need it so the Oracle
eyes solution is basically the one of
intermediating and so ironically we
could say that Oracle eyes is a new type
of intermediary in a word that is trying
to get rid of them so we see on one side
web api so any possible existing data
source and on the other blockchains in
general so our client stays in the
middle and tries to make the two
different words communicate so different
context is to communicate and exchange
data so this is what we call a data
transport layer we have seen a lot in
previous presentation the problem of
trust so of course having a new
intermediary implies some trust lines
that we have to open we don't want to
trust a small startup of 10 people so
this is why we add to provide some kind
of authenticity pros so a proof of the
fact that the data we are sending to the
blockchain application is indeed
authentic as reported by the external
data source and not tampered with by the
intermediary which is authorized in that
case so in order to do that we send the
blockchain not just the result that
comes from the external data source but
also the so-called authenticity profit
so authenticity proofs are a very
generic concept what we want to get is
just some kind of evidence of the fact
that the data fetching from the external
data source is indeed honest is not that
we want to know that the operator is
behaving honestly this is trivial when
the data source signs the data
unfortunately there are so many
different standard standards and
proposals to sign data on the Internet
that pretty much none of them is being
widely used hopefully this will be
solved in the future years but in the
meantime we know already that some data
sources made a choice so for example
there is an IETF proposal that is being
discussed for several years
which is being called cabbage HTTP
signatures which is that is seventy
duration now this is one possible way to
sign the data for the data source there
are already several data sources signing
the data in this way Oracle I supports
it so it means that if the data source
you choose on is signing the data in
this way you can leverage the Oracle
eyes data transport layer and connect
this Web API to your smart contrast
application straightaway but in general
Web API eyes do not sign the data and
this is why we need to leverage
different techniques we have seen what
chain link does with the Town Crier
project which is based on Intel SGX this
is one possible technology which we can
use so trusted computing by Intel SGX
but there are many others techniques
that can be used Oracle eyes at the
moment is using some sandboxing
techniques which are backed by software
guarantees such as TLS notary and some
others that are backed by hardware
techniques like Intel SGX
or the Qualcomm teehee legend analyst
attestation that we have seen yesterday
here with Nikolas from Letcher and many
others so basically there are many
different ways we can give this kind of
evidence and this kind of proof and what
our class is doing is not using a single
technology to do it
as as we will see in a minute we believe
that that will be a quite a weak
architecture so basically what we are
saying is that when the data source does
not sign the data then we need to use a
different technology but which one do
you choose
well this is a complicated question
because every time we use the technology
we are really trusting the at the stator
so the at the stator is basically
whoever designs the technology whoever
is providing the technology so think
about the Intel SGX case so on paper
Intel SGX is very safe for sure is one
of the most interesting and flexible
technologies for trusted computing that
we have available on the market but at
the end of the day we need to trust
Intel because we cannot verify in our
homes
if the chip for example is the CPU
package is really doing what it is
supposed to do we cannot really know if
the signature coming from the
attestation services is done correctly
as intended and in general every time we
use one of those technology we are
always trusting somebody so Internet
even in the case of the ledger proof for
example we are trusting ledger in the
case of the Android proof we are
trusting a Qualcomm and Google for sure
so basically by using those technologies
to prove the authenticity of the data we
are not really giving out a trustless
solution we are simply shifting the
trust from the central operator which in
that case is recognized as most are that
startup that we do not want to trust to
parties that has something more at stake
that have a strong reputation of course
if this is all we have this will be
quite weak and disappointing as if the
solution for the Oracle problem is to
trust a single party then we could
simply go to that company and ask them
to run the Oracle service this would be
exactly the same
open trust wine and it would be much
more efficient
however the blockchain was not designed
to move the trust away to a single
central company right or we will not be
here today so by using different
technologies we can spread the trust and
get more than one proof backing that
claim so if we use all the technology we
see here for example we are trusting
four different companies which in order
to provide valid proofs but backed by
tamper with data they will need to well
basically they will need to lie all at
the same time in the same way which is
quite unlikely so basically all we're
doing here is moving the trust away to
different parties by using their
technology but without asking them to
run the service something that we get
asked quite often is wait what but why
don't we just ask those companies to
come together in a consortium and to
provide this as a service they could
simply sign the date
animalistic fashion this will be
trivially doable and this will be much
easier right well if they come together
in a consortium this is quite weak
because by doing that they would show to
the world that they have an agreement
and if they have an agreement the chain
of the different proofs is much weaker
as they basically show that they are
willing to cooperate so this is why it's
much better to have an independent party
which is different from all these
different technology providers that runs
to the service so basically what Oracle
Isis is doing is putting in the Oracle
eyes engine which is one physical box
that we designed all these different
technologies all these different trusted
computing techniques so that we can
provide different layers different
levels of proofs and provide this as a
service to the blockchain this is
something that today we are managing
with a distributed network so this is
something we fully manage so as we just
we have just seen thanks to the
authenticity proofs we do not need to
trust Oracle eyes but we need to trust
all these different artists theaters so
the only risk of the central operator of
the Oracle eyes service is basically the
service to stop running so bad quality
of service or maybe censorship or many
other of these problems this is why we
are working towards a new possibility
which is basically delegating the
management of the Oracle eyes engine
machines to any interested parties that
might be willing to contribute to
maintaining the service running so this
is something that will basically move
away the governance of the maintenance
of the service from Oracle eyes to a
different entity the rest of the
presentation is around authenticity
proof so I want to dive into the
verifications of those proofs so what
you see here is the network monitor this
is a web-based tool that anybody can use
to verify of chain the authenticity of
the proofs unfortunately this means that
once you have a smart contract like this
which wants to reach out to a Web API
like crypto compare
you specify the proof you want like
Oracle is that proof proof type TLS
notary so here we are saying we want a
TLS notary proof which is software
backed and based on the trust with
Amazon and we want proof storage AP FS
so actually we will not get back the raw
proof which will be quite big but just
the AP FS multi ash of the same so as a
consequence it means that it's not
possible to verify with a contract like
this the validity of the proof on the
contract once it receives the codec
function so this is something that is
not easier because basically Oracle eyes
could potentially send back a Bronk
proof and you will just notice
afterwards so the interesting part is
that anybody can check for the last two
years and all all the 300,000 proofs we
are sent on chain and you will see that
there is none which at the moment is not
passing unless there was one while it
was on stage but in general what we want
is a stronger guarantee where basically
the authenticity proofs can be verified
by the receiving contracts so let's see
what the authenticity proof contains
first of all so basically this really
depends on the sandboxing technique
being used because different techniques
need different verification steps
however they are all basically a
collection of signatures and data to
verify some kind of attestation some
kind of claim coming from the artists
theater still those proofs are general
purpose so they have nothing to do with
the blockchain in their format we are
investigating use cases also outside the
blockchain space and they are
self-contained so it means that once you
have the proof you should be able to
extract the full message from the proof
itself there should be nothing outside
the proof that you need to verify the
validity of the proof itself however
giving that nature of the proof they
might be quite big depending on the data
you are trying to fetch from the
external data source so this is why we
cannot send them every time on the
blockchain because it will be a very
high cost and well given the gas limit
of course this is something that it's
not possible above certain sizes so I'm
intent is the proofs that we have
designed such as the ledger proof for
the random data source and the native
proofs like the ones where the data
source signs the data are trivially
verifiable on chain so this is for
example a very short piece of code which
verifies native proofs on chain as we
expect this is nothing really
complicated but we see there are
different steps like we need to check
that the answer is fresh that is
authentic and that there is integrity of
the proof and other steps for the
alleged proof it's even more complicated
because we are checking basically that
the trusted computing device is really
executing the correct code that we
expect it to be executed so you see in
the code that there is for example our
code ash which is the ash of the code
being executed which being open source
you can verify yourself of chain once
there is the public key of ledger which
is the one sign the attestation claim
and much more both these are already
working on chain and the cost is quite
reasonable so it's around the 50
thousand gasps 60000 gasp but to be for
bigger proofs where we have bigger
messages it might not be possible to it
to do it so in those cases um we have to
think of something different and this is
what the proof shield is so the proof
shield is basically a new concept where
we take the same trust model that we
explained before we use exactly the same
technology to reduce the complexity of
the proof verification down a single
signature so basically this is a
different application running on trusted
computing devices or on other tanks and
boxing techniques that we are using so
that the complexity of the proof the
proof the raw proof we had before is the
input of this software and the output is
a simple signature which we can easily
verify on the blockchain from the
calling smart country like with native
proofs or with alleged proof so in this
case it means that the receiving
contract
is not the raw proof but the proof
shield proof so it's a different problem
we solve but when we keep the same open
trust line the security model doesn't
really change so for example if we have
TLS not reproof which is based at the
end of the day given its nature to
unopened restrain with Amazon Web
service well if we somehow leverage a
fully lockdown approvable machine
running on amazon web service which
converts this proof to a single
signature then we are still trusting
Amazon for that convention for that
transformation and the optional
verifications becomes possible though so
this is something we have written in C
is quite modular and portable
architecture you can run in different
contexts --is it will be open sourced
very soon
it supports basically all the existing
proofs provided by Oracle eyes so all
you could put actually use I don't know
like ledger device to run the proof
sheet to verify an android proof but of
course in that case you open a new
additional trust range so the optimal
case is going to use exactly the same
technology and the first prototype will
be released on test net before the end
of year and it's in the first
implementation will be based on as a
bolus up so basically it's running on a
ledger device and the verification cost
again are in the fifty sixty thousand
gas range and it can be reduced even
more so that basically the transaction
verification itself so the signature
showing that transaction is coming from
a given sender it can be a ready the
verification step so in a version two of
the proshield
we will be able to reduce down the cost
of the proof sheet proof verification to
basically zero so that is also a really
compatible with a ready deployed
contract which now are several hundreds
on the main chain so so far we are the
most widely used Oracle service on the
blockchain we yes and three hundred
thousand over three hundred thousand
queries on the main net and today the
range is typically between one and five
thousand
the transactions per day on the main not
only we have integrations also with
other blockchains as you can see here
but a Tyrian is where we started from
and where most of the usage at the
moment comes from we are using different
technologies and attestation techniques
and this is something that we still have
in the working sister continues the
research problem so these are the things
we have in the working for the future so
basically we will facilitate with
Stargate D using private chains and for
in-memory executions and simulations the
proof shield I've already talked about
the decimal deployment and the version
show that we have in the workings and
Newton disapproves the reduce the
centralization points of the operators
of us of our service via the delegation
of the management machines to external
nodes and tomorrow
downstairs in the breakout hall at 3:45
p.m. I will do a deep dive around the
oracle eyes offering computations and i
will show you something which is quite
interesting or the using of this the
same technologies and the same trust
model to execute obtain any piece of
code and say no change as the result
also for like non-deterministic pieces
of code
thank you for attention
[Music]