►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/improving-oracle-infrastructure-on-ethereum/
Oracles continue to fuel the growth of the Ethereum and layer-2 ecosystem. To build dApps that serve real-world use cases, from DeFi and DAOs to NFTs and beyond, Ethereum developers need access to secure oracle networks. In this session, we will dive into the latest oracle innovations and showcase new capabilities that enable Ethereum developers to build the scalable, secure, and feature-rich applications that can achieve widespread adoption.
Speaker(s): Lorenz Breidenbach
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: Smart contracts,oracles
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
B
A
Those
of
you
who
don't
know
oracle
infrastructure
connects
smart
contracts
with
the
rest
of
the
world
with
the
world
outside
the
blockchain,
and
so
let
me
start
by
talking
about
the
most
prominent
use
case
of
oracles
data
feeds.
I'll
start
by
reading
a
quote:
we'll
play
a
little
game.
You
guys
can
rather
read
the
quote:
guess
where
the
quote
is
from
I'll.
Give
you
a
few
more
seconds
after
I'm
done.
Reading
the
quote,
and
then
I'll
reveal
the
answer.
A
So
the
quote
is,
for
example,
one
powerful
use
case
of
an
oracle
contract
would
be
a
hedging
contract
where
A
and
B
put
in
a
thousand
dollars
worth
of
bitcoin
and
after
30
days
the
script
sends
a
thousand
dollars
worth
of
bitcoin
to
a
and
the
rest
to
B.
This
would
require
an
oracle
to
determine
the
value
of
one
Bitcoin
in
US.
Dollars
sounds
a
little
bit
like
defy.
The
terminology
is
a
bit
different
from
what
we
would
say
today.
A
So
the
solution
is,
it
comes
from
the
ethereum
white
paper,
all
the
way
back
in
2014.
so
already
back,
then
it
was
clear
that
oracles
are
required
for
certain
types
of
applications,
and
indeed
here
we
have
an
example
of
a
you
know:
price
feed
or
data
feed
Oracle
and
if
we
think
a
little
bit
about
the
properties
that
this
implies,
that
we
need
our
Oracle
to
have
there's
two
things
that
stand
out.
So,
first
of
all,
we
need
reliability.
A
We
need
to
make
sure
that
when
the
30
days
are
up
here,
indeed,
the
Oracle
supplies
the
exchange
rate
between
Bitcoin
and
dollars.
So
we
can
fairly
settle
the
hedging
contract
and
then
we
also
need
security
and
integrity
right.
The
price
that
is
provided
here
by
the
Oracle
will
be
used
to
settle
the
contract,
and
so
if
the
price
is
incorrect,
then
we
won't
be
able
to
settle
the
contract
fairly.
So
it's
essential
that
we,
we
have
a
Oracle
that
provides
these
properties
and
I.
A
So
let's
have
a
look
at
how
one
might
construct
such
a
data,
feed,
Oracle
and
I'll
start
with
a
straw,
man,
construction
and
then
I'll
evolve
that
construction
into
what
I
would
say
is
the
state
of
the
art
today
and
is
what
chain
link
does
today
so
here
in
this
Roman
example,
we
have
a
data
source
that
Pro,
you
know
the
Oracle
observes
in
this
case
the
data
source
says
Hey.
Ten
dollars
is
the
price.
A
The
Oracle
will
sign
that
price
and
it
will
then
provide
it
to
a
contract
running
on
chain
and
then
adapt
contract
can
read
price
from
our
data
feed
contract.
But
if
we
think
a
little
bit
about
the
two
properties,
I
had
just
mentioned
reliability
and
security,
then
this
system
does
not
achieve
them,
because
we
have
a
single
point
of
failure.
If
this
Oracle
goes
down
or
fails
to
provide
the
price,
then
the
system
on
chain
won't
work.
A
And
similarly,
if
the
single
Oracle
here
is
compromised
or
malicious,
then
it
can
feed
a
false
price
to
the
contract
on
chain
and
cause
the
contract
to
be
settled
incorrectly
unfairly.
So
how
can
we
solve
this
problem?
Well,
there's
a
few
different
approaches
that
people
commonly
take
but
I
think
the
most
common
one
today
is
to
say:
let's
decentralize
the
Oracle.
So
let's
have
a
bunch
of
independent
oracles
all
provide
the
system
together,
and
so
what
we've
done
here
is.
A
The
typical
aggregation
one
would
use
for
numerical
data
is
to
take
the
median,
because
that's
a
robust
statistic
that
doesn't
respond
to,
for
example,
false
outlier
values
or
things
like
that,
and
then
you
know
once
we
have
medianized
our
value,
we
can
expose
it
to
the
dab
contract
Downstream,
and
this
is
nice
because
we
can
now
handle
subsets
of
oracles
being
faulty
right.
So
if
some
of
the
oracles
here
do
not
send
a
price
or
if
some
of
them
send
false
data,
that's
okay!
A
If
they,
if
they
don't
send
a
price,
our
data
feed
contract
can
just
handle
that
by
ignoring
a
certain
number
of
missing
submissions
and
if
they
send
a
false
price.
As
I
had
mentioned,
we
use
the
median,
which
is
a
robust
statistic
and
which
ensures
that
as
long
as
no
more
than
half
of
the
oracles
here
are
faulty,
the
aggregate
price
still
lies
within
the
interval
of
prices
reported
by
correct
oracles.
A
A
Folks
out
here
have
them
run
a
Byzantine
fault,
tolerant
protocol,
Byzantine
fault,
tolerant,
means
that
they
can
handle
arbitrary
faults.
So
any
of
these
oracles
could
be
you
know,
malicious
or
faulty
or
down
or
whatever
else,
and
as
long
as
you
know,
some
subset
of
them
is
affected
by
this,
depending
on
exactly
how
you
set
up
the
assumptions
either
less
than
a
third
or
less
than
half
of
the
oracles.
The
overall
system
will
keep
functioning
correctly
chain.
A
Link's
version
of
this
is
called
the
off-chain
reporting
protocol
and
indeed
it's
far
more
efficient
than
the
predecessor
I
had
just
showed
you.
So
we
realized
something
like
90
on
chain
cost
savings,
and
this
is
good
for
security,
because
it
means
that,
with
the
same
security
budget,
we
can
have
a
lot
more
oracles.
A
This
is
very
desirable.
Indeed,
as
I
mentioned
right.
This
is
how
how
the
chain
link
off
chain
reporting
protocol
works,
and
it's
been.
It's
been
very
successful,
so
we
we
designed
it
for
powering
data
feeds
on
evm,
Chains
It's
been
running,
reliably
and
securely.
For
at
this
point,
one
and
a
half
years
in
production,
it
secures
roughly
20
billion
dollars
of
value
across
all
the
various
chains.
That
chain
link
is
active
on
14
billion,
just
on
ethereum
there's
more
than
a
thousand
feeds
across
all
the
chains.
A
We're
active
on
and
more
than
290
of
those
are
on
ethereum
and
I.
Think
the
the
reliability
and
secure
of
the
system
are
also
shown
by
the
fact
that
we
have
major
major
D5
protocols,
relying
on
this
system
like
names
such
as
other
compound
and
synthetics
all
use
this
cool.
But
okay,
so
I
told
you
about
data
feeds,
but
now
I
want
to
tell
you
that
oracles
are
about
a
lot
more
than
just
data
feeds.
A
They
enable,
in
the
general
sense
interactions
of
smart
contracts
with
the
outside
world,
that
is
to
say,
you
know
things
that
are
outside
the
blockchain
or
contract
executes
on,
and
so
they
Empower
smart
contracts
to
reach
their
full
potential.
Because
now
I
can
do
a
lot
more
interesting
things
with
my
contract,
then,
if
I'm
just
isolated
on
the
blockchain
and
cannot
interact
with
the
outside
world.
A
Secure,
Randomness,
contract,
Automation
and
cross-chain
interoperability
I'm
going
to
talk
about
more
later
in
the
talks.
I
won't
go
into
them
now,
Fair
sequencing,
you
know,
I
can
use
an
oracle
Network
to
protect
users
from
toxic
Mev
extraction
by
fairly
sequencing
transactions.
I
can
Outsource,
computation
and
storage
so
that
I
can
enable
contracts
to
scale
beyond
what
the
evm
provides
as
much
as
we
all
love
the
evm
and
as
much
fun
as
gas
golfing
is.
A
There
are
some
things
that
are
just
a
little
bit
hard
to
do
on
the
evm
and
then
finally,
I
can
also
enable
oracles
to
perform
real
world
actions.
So
we
actually
had
a
hackathon
a
couple
of
months
ago
inside
chain
link
Labs,
where
we
had
contracts
ordering
pizza
via
the
Pizza
Hut
API
to
people's
houses.
So
I
think
that's
a
that's.
A
pretty
neat
use
case
that
is
enabled
here
and
that
would
not
be
available
to
contracts
natively
and
then.
A
Finally,
we
can
also
provide
privacy
preserving
access
to
almost
any
Web
2.0
data
and
I'll
cover
that
also
towards
the
end
of
my
talk.
So
this
gives
rise
to
this
notion
of
hybrid
smart
contracts
and
and
when
I
say,
hybrid,
smart
contract.
What
I
mean
here
is
a
hybrid
system
that
partly
operates
on
chain
in
the
form
of
a
smart
contract
running,
say
on
ethereum
and
partly
off-chain
operated
by
a
network
of
decentralized
oracles,
and
so
this
overall
hybrid
smart
contract
is
now
able
to
interact
with
the
real
world,
and
so
so.
A
This
enables
me
to
do
all
sorts
of
interesting
things,
and
let
me
you
know,
give
you
some
more
specific
details
on
some
of
these
and
I'll
start
by
talking
a
bit
about
secure,
Randomness
and
what
that
enables
contracts
to
do
as
you're,
probably
familiar,
there's
kind
of
two
on-chain
native
ways
on
ethereum
these
days
to
get
random
values.
One
of
them
is
the
block
hash
up
code
and
that
sort
of
you
know
audit
findings.
101
do
not
rely
on
the
Block
hash
op
code
for
Randomness.
A
Any
block
producer
can
can
easily
tamper
with
that
and
now,
since
the
merge
there's
also
a
second
op
code
prevao,
which
is
a
little
bit
better
than
block
hash,
but
which
is
still
manipulable
by
block
producers,
and
so
so
the
output
of
both
of
these
can
be
biased.
So
if
your
contract
needs
secure,
Randomness,
for
example,
for
running
a
lottery
or
for
doing
a
nft
mint,
where
you
assign
valuable
random
attributes
to
your
nfts,
these
are
not
good
enough
and
so
on
chain.
A
There
is
no
native
capability
to
get
good
Randomness,
and
this
is
where
oracles
come
in
and
oracles
can
provide
that
functionality.
So
we
we
have
a
cryptographic
construct
here.
That's
called
a
verifiable
random
function
and
that
enables
an
oracle
to
provide
tamper-proof
Randomness,
and
let
me
explain
how
that
works.
So
we
start
here
with
our
dap
contract
that,
if
it
wants,
some
Randomness
can
request
from
another
contract
on
chain.
That's
part
of
this
drf
service,
some
random
words.
A
The
contract
will
emit
an
event
with
you
know,
just
telling
the
oracles
that
Randomness
has
been
requested.
The
oracles
will
evaluate
the
verifiable
random
function,
which
is
based
on
deterministic
public
key
cryptography,
that
is
to
say,
the
oracles
actually
have
no
ability
to
change
the
output
It's
deterministic
So,
based
on
a
given,
keep
here
and
a
given
blockchain
state,
which
is
used
as
the
input
for
the
vrf.
We
will
always
get
the
same
output
value
the
same
randomly
distributed,
output
value
and
the
oracles
will
then
provide
a
cryptographic
proof
that
they
correctly
evaluated.
A
The
vrf
will
send
that
cryptographic
proof
to
our
coordinator
contract
here,
which
can
cryptographically
verify
the
proof
and
if
indeed
the
verification
succeeds.
Then.
Finally,
the
coordinator
can
send
the
the
random
output
here
to
the
DAP
contract,
which
can
then,
for
example,
run
its
lottery
or
whatever
else,
and
this
is
live
today
in
production.
If
you
are
writing
a
contract
and
you
need
this
functionality,
you
can
use
it
and
I
think
there's
over
1
400
unique
contracts
that
have
used
this
in
the
past
30
days.
So
okay,
Randomness,
is
cool.
A
Now,
let
me
talk
to
you
about
yet
another
use
case
that
is
live
today
and
that
you
know
enables
contracts
to
do
more.
Interesting
things,
and
that
is,
contract
automation
once
again,
I'll
return
to
the
quote
from
the
original
ethereum
white
paper
in
2014,
but
this
time
I'll
highlight
a
different
part,
so
here
we
have
after
30
days.
The
script
sends
a
thousand
dollars
worth
of
bitcoin
to
a
and
the
rest
to
be.
So
how
does
the
script
do
this?
A
How
can
the
script
or
the
smart
contract
send
those
funds
to
a
and
b
contracts,
do
not
have
an
ability
to
initiate
their
own
execution
right
and,
of
course,
I
could
say.
Well,
you
know,
I'll
just
have
my
users
A
or
B
here
you
know
call
the
contract
after
the
30
days
are
up
and
then
I'll
do
a
payout,
and
maybe,
if
I
just
have
two
users,
that's
fine,
but
now,
let's
say
I
have
a
lot
of
users
or
I
want
to.
A
You
know,
sweep
a
bunch
of
tokens
from
different
contracts
into
a
single
pool
or
whatever
other
expensive
maintenance
action.
My
system
requires
to
run
then
that
will
lead
to
a
very
poor
ux
if
I
put
the
onus
of
Performing
those
maintenance
actions
on
the
users,
interacting
with
my
dap,
because
if
I'm,
a
user
I
now
have
a
non-deterministic
gas
price
right
once
in
a
while
when
I
interact
with
adapt,
it's
going
to
cost
me
a
hundred
thousand
gas
another
time.
A
I
need
to
maintain
some
expensive
maintenance
on
the
side,
and
suddenly
it's
going
to
cost
me
500
000
gas.
That's
not
great!
It's
also
unreliable,
because
I
can't
really
rely
on
my
users
calling
the
contract
at
a
specific
point
in
time,
and
so
this
is
where,
where
contract
automation
comes
in
to
play.
A
And
so
then
the
you
know,
the
programmer
of
this
upkeep
contract
can
basically
come
up
with
any
arbitrary
predicate
to
decide
whether
their
contract
ought
to
be
called
or
not.
And
you
know
if,
if
the
contract
says
no
I,
don't
want
to
be
called
no
problem.
We
just
check
again
in
the
next
block,
but
if
indeed
the
contract
wants
to
be
called,
It
Can
indicate
so
to
the
Oracle
Network,
which
will
then
send
a
second
or
will
then
actually
send
the
first
real
transaction
to
the
chain.
A
That's
not
simulated
with
a
perform
upkeep
call
for
upkeep
contract
here
and
now
this
contract
on
chain
can,
you
know,
take
whatever
logic
it
wants
to
so,
for
example,
in
the
previous
case.
At
this
point,
it
could
have
paid
out
our
two
users
A
and
B,
depending
on
the
outcome
of
this
hatching
contract
and
again,
this
functionality
is
live
today,
there's
over
250
unique,
upkeep
contracts
that
have
been
active
in
the
past
30
days.
And
if
that's
useful
for
your
for
your
smart
contracts,
then
I
would
encourage
you
to
check
that
out.
A
So
the
problem
here
is
that
smart
contracts
cannot
natively
interact
with
smart
contracts
running
on
other
blockchains,
but
we
live
in
a
multi-chan
world.
Now
right,
there's
dozens
of
chains
out
there,
it's
a
very
heterogeneous
environment,
some
memorable
ones.
Some
are
l2s,
some
use,
the
EDM,
some
don't
and
so
on
and
so
forth,
and
so
indeed,
there's
also
a
lot
of
demand
for
bridging
between
contracts
on
different
chains.
So
today
it's
something
like
168
billion
dollars
of
value
have
been
bridged.
A
Just
in
the
past
12
months,
we've
seen
over
two-thirds
of
the
total
volume
ever
bridge
for
something
like
115
billion
dollars
bridged,
but
also
we
have
a
challenge
with
security
in
this
cross-chain
space.
So
to
date,
2.5
billion
dollars
have
been
hacked
from
cross-train
protocols
and
just
this
year,
over
70
percent
of
all
values
stolen
in
in
kind
of
the
blockchain
ecosystem
is
from
cross-chain
hacks,
so
I
think
once
again,
this
indicates
that
security
is
Paramount,
but
that,
unfortunately,
the
the
current
Solutions
are
not
yet
up
to
the
task.
A
So
we
at
chain
link
are
also
working
on
a
solution
to
this
problem,
which
we
call
the
cross
chain,
interoperability,
protocol,
ccip,
and
so
here
we're
working
on
a
programmable
bridge
that
enables
a
smart
contract.
That
contract
here
say
on
ethereum
to
send
a
message
to
a
contract
running
on
some
other
chain,
and
you
know
it
could
be
talking
to
multiple
other
chains.
A
If
you
want
to
learn
more
details
about
this,
we
just
had
a
talk
at
smart
con
roughly
two
weeks
ago,
where
we
went
in
more
detail
about
the
architecture
of
ccip
and
it's
on
YouTube,
so
I'd
encourage
you
to
check
that
out.
If
that's
interesting
to
you,
the
second
Oracle
enabled
capability
for
the
future
that
we're
working
on
is
about
providing
privacy,
preserving
access
to
Web
2.0
data
to
almost
any
Web
2.0
data
to
Smart
contracts,
and
this
is
I
think
a
super
cool
capability
at
first.
A
B
A
The
fundamental
problem
is
that
the
the
vast
majority
of
data
is
private
and
is
therefore
not
publicly
accessible
in
the
Web
2.0
ecosystem.
So,
for
example,
my
online
bank
account
my
Twitter
profile,
my
Facebook
profile,
my
Amazon
account
some
government
website.
None
of
these
are
accessible
by
smart
contracts
on
chain,
because
all
of
them
are
behind
some
kind
of
authentication.
Wall.
Right
and
I
would
argue,
that's
a
good
thing.
I
don't
want.
A
My
bank
account
information
to
be
just
visible
to
any
contract
on
chain,
but
still
it
would
be
kind
of
cool
if
there
were
a
way
to
expose
in
a
privacy,
preserving
information,
just
the
information
required
to
Smart
contracts
unchain,
because
that
would
unlock
I
think
many
interesting
use
cases
things
like
decentralized
identity
risk
scoring
where
I
can
use
information
about.
My
off-chain
behavior
to
you
know
score
how
risky
of
a
borrower
say:
I
am
consequent.
A
Consequently,
under
collateralized
lending,
where
you
know,
maybe
in
order
to
borrow
a
hundred
dollars
worth
of
assets,
I
don't
have
to
put
up
200
worth
of
collateral
on
chain
or
private,
defy
instruments
where
I
can
have
a
D5
instrument
where
only
the
parties
that
are
participating
in
that
instrument
need
to
learn.
You
know
what
exactly
the
conditions
of
it
are
on,
what
based
on
what
condition
it
settled
and
so
on
to
improve
privacy
of
on-chain
trading
and
more
things
that
I,
probably
can't
even
imagine
yet.
A
This
is
a
very
general
technology,
and
so
the
technology
we're
working
on
here
to
to
address
this
is
called
Deco.
Deco
was
originally
researched
at
Cornell,
University
and
ic3.
The
initiative
for
cryptocurrencies
and
contracts
and
since
then
chain
link
has
has
pushed
the
project
forward,
is
actively
developing
it
and
further
researching
it
to
make
it
efficient
and
practical,
and
so
I'm
briefly
going
to
describe
to
you
how
Decor
works
and
what
properties
it
affords
first
in
the
abstract
and
then
by
going
through
an
example.
So
we
have
three
off-chain
parties.
A
Here
we
have
a
web
server,
we
have
a
prover
or
a
user
and
we
have
a
bunch
of
verifiers
or
oracles,
and
so
now
what
what
Deco
enables
the
user
to
do
is
to
prove
to
these
verifiers
and
then,
by
extension,
to
the
smart
contract
that
some
data
indeed
comes
from
a
certain
web
server.
So,
for
example,
I
can
show
that
indeed,
bank.com
made
some
statement.
We
assume
that
this
web
server
runs
TLS,
which
is
the
the
standard
protocol
for
securing
Communications
on
the
web.
A
Today
you
know,
whenever
you
go
to
some
website,
you'll,
probably
see
a
little
lock
icon
at
your
address
bar
indicating
that
the
connection
is
secured
with
TLS,
so
I
can
prove
provenance,
so
I
can
show
that
the
data
indeed
comes
from
a
certain
Source,
but
I
can
do
this
in
a
privacy
preserving
way
where
I
can
run
a
zero
knowledge.
Proof
protocol
to
only
reveal
the
information,
the
minimal
information
that
I
want
to
reveal
to
the
verifiers
and
then,
by
extension,
again
to
the
contract
and
right,
so
so
the
web
server.
A
Obviously,
if
it's,
for
example,
my
bank
knows
my
balance
and
my
password
I
as
the
user
also
know
my
my
password
and
my
balance,
but
the
the
verifiers
or
oracles,
for
example,
should
definitely
not
learn.
My
password
right
and
Deco
enables
me
to
do
this
in
this
privacy
preserving
way
and
then
finally
and
I
think
this
is
actually
the
coolest
property
of
Deco.
A
It's
compatibility,
so
it's
compatible
with
the
existing
TLS
web
ecosystem,
and
that
means
that
there's
no
need
to
get,
for
example,
the
the
data
holder
here,
the
web
server
to
change
anything
about
their
API
or
their
stack.
They
don't
even
need
to
know
that
Deco
is
being
used
to
prove
something,
and
you
know
if
you,
for
example,
look
at
how
hard
it
is
to
get
the
internet
migrated
to
IPv6.
A
You
know
that
protocol
upgrades
are
very
difficult,
so
it's
I
think
a
game
changer
here
that
this
works
with
the
existing
Web
2.0
ecosystem
without
requiring
modifications
on
the
part
of
the
web
server
or
the
user.
So
let
me
let
me
show
you
an
example.
So
I'm
the
I'm,
the
approver
I'm
the
user.
Here
my
name
is
Lawrence
and
I
want
to
show
to
a
contract
on
chain
that
my
bank
account
balance
is
greater
than
a
thousand
dollars
without
revealing
anything
on
top
of
that.
A
A
If
you
just
have
the
envelope
you
cannot
see
what's
inside,
but
you
also
cannot
switch
the
contents
without
somebody
noticing,
because
you
kind
of
tore
the
envelope-
and
this
is
basically
a
similar
thing
here.
So
the
verifiers
hold
a
cryptographic
commitment
about
any
data
that
was
exchanged
within
the
session,
so
I
as
the
user
cannot
sort
of
alter
the
data
after
the
fact,
but
the
verifiers
do
not
see.
A
But
that
is
the
only
thing
they
will
learn.
They
will
not
learn
my
credentials
and
they
will
not
learn
my
precise
balance.
The
oracles
can
then
cryptographically
sign
an
attestation
that
they
have
successfully
verified
this
zero
knowledge
proof
and
this
attestation
can
be
forwarded
to
our
smart
contract
on
chain.
Here
again,
you
know
signed
by
a
chrome
of
oracles,
and
then
we
can
verify
in
the
contract
that
indeed
those
those
signatures
match,
and
so
now
I
have
convinced
the
contract
on
chain
that
I
have.
A
You
know
at
least
a
thousand
dollars
in
my
contract
and
I've
done
that
without
having
revealed
any
additional
information
and-
and
you
know
you
can
think
about
this
in
a
far
more
General
sense,
because
this
is
your
knowledge
proof,
I
could
basically
prove
almost
any
statement
about
the
data
that
was
exchanged
in
almost
any
TLS
session.
So
this
is
a
very
general
and
very
technology.
A
A
A
Yeah
and
third
of
all,
I
think
we
we
yeah,
have
a
opportunity
to
make
contracts
more
exciting,
more
interesting,
to
empower
them
to
reach
their
full
potential
Beyond
just
doing
things
within
the
closed
on-chain
ecosystem
that
they
would
naturally
operate
in
without
the
native
oracles.
So
yeah
thanks
a
lot
and
if
you
have
any
questions,
I
think
I'm
I'm
over
time,
so
just
come
and
find
me
after
the
talk
you.
A
I
see
I,
see
I
see,
so
basically,
what
happens
is
that
the
the
depth
that
relies
on
contract
automation,
oh
yeah,
we'll
we'll
maintain
a
balance?
I,
don't
know
whether
it
can
go
back
to
that
slide,
no,
no,
no,
no
more
anyway!
So
so
it
maintains
a
subscription
balance
with
an
automation
registry
contract
that
sits
on
chain
and
then,
when
the
DAP
is
invoked
by
the
Oracle
Network.
A
B
C
A
So
so
my
my
short
answer
and
forgive
me,
is
just
gonna,
be
Magics
your
knowledge
proofs.
Basically,
that's
what
dkps
are
about
right.
I
can
I
can
prove
statements
about
data
and
sort
of
very
counter-intuitive
ways
without
revealing
anything
beyond
the
statement,
but
I
think
we
probably
don't
have
time
to
go
into
the
details
of
how
that
works.
Unfortunately,
but
come
find
me
afterwards
and
I'm
happy
to
talk
more.
B
So
I
have
a
question
about
the
OCR.
The
off-chan
Oracle
reporting
protocol,
so
with
with
a
blockchain,
is
easy
for
the
different
note,
Rich
consensus
right,
because
you
can
check
the
the
transaction
signature.
They
can't
really
run
rerun
all
the
byte
code
of
a
smart
contract
by
the
way,
the
Oracle.
How
does
the
different
node
ritual
consensus?
Because
if
it's
a?
If
it's
a
data
phase,
then
you
cannot
compute
right?
You
cannot
compute
the
weather.
This
feed
is
great
or
not.
A
So
so
I
believe
that
the
answer
to
your
question
is
OCR
is
a
Byzantine
fault,
tolerant
protocol
that
is
actually
the
same
family
of
protocols
that
consensus
Protocols
are
from
right.
It
uses
similar
techniques,
it
just
has
a
different
goal.
Its
goal
is
to
provide
you
know
reliable
and
secure
reports
about
some.
A
You
know
data
observed
from
off-chain
to
contracts
on
chain,
but
it's
it's
similar
techniques,
and
so
you,
you
kind
of
as
part
of
how
that
protocol
Works
get
that
property,
that
you
know
the
oracles
communicate
with
each
other
over
the
peer-to-peer
Network
and
that
some
of
them
can
be
faulty
and
so
on.
So
you
you
know
you
you
broadcast
things.
You
converge
cast
things
you
use
digital
signatures,
the
usual
type
of
things
you
would
do
in
bft
protocols.
B
Yeah
I
mean
if
let's
say,
if
it's
easier
and
or
if
the
other
blockchain
different
nodes,
just
have
to
have
the
same
similar
result
from
the
trans
executing
the
transaction
have
a
similar
result.
If
a
two-thirds
two-third
of
node
have
a
similar
result,
then
can
reach
a
consensus
right,
but
but
with
I
understand
with
you
can
use
that
for
the
for
the
consensus
layer.
B
B
No
for
like
for
computation
for
computation
tasks,
it's
very
easy
to
reach
a
consensus
between
different
computers,
because
as
long
as
your
as
I
run
on
the
result
or
computation
is
the
same,
if
two
two-thirds
of
node
computer
agreed,
like
the
result
of
the
commutation
result
of
one
transaction,
is
the
same,
then
you
have
a
consensus.
You
have
you're
fine
you're
good,
but
with
the
data
fade
like
let's
say,
if,
if
two,
if
one
sort
of
a
server
or
node
or
Channing
knows
I,
think
the
the
price
of
ethereum
is
one.
A
Thousand
I
see
I,
think
I.
Think
now
I
get
the
question
okay,
so
so,
basically
inside
the
OCR
protocol,
which
I
did
not
have
time
to
explain
in
detail
here,
there
is
a
phase
where,
where
the
different
Oracles
converge
cast
their
individual
observations
to
each
other
and
at
the
end
of
that
phase,
every
Oracle
will
have
a
signed
observation
from
every
other
Oracle.
A
So
if
you
know
we
have
a
bunch
of
Oracles
in
here,
every
Oracle
will
know
what
all
the
other
oracles
think
the
price
should
be,
and
at
that
point
I
can
then
you
know,
have
everybody
compute
the
same
kind
of
deterministic,
aggregation
function
and
I
will
end
up
with
the
same
outputs,
and
so
I
can
reach
agreement
between
the
different
Oracles
thanks.
Everyone.