►
Description
Topics covered
-----------------------------
0:45 - Guest’s introduction
1:51 - Nick’s presentation
2:10 - Overview
2:32 - Problem statement
4:35 - Ecosystem review
4:43 - How do existing L2 integrations work?
7:15 - Proposed architecture
8:04 - Securely querying an L2
11:58 - Does it solve our problem?
13:05 - Much more than just ENS!
15:10 - Demo
19:38 - Work so far
21:00 - Next steps
21:39 - End of presentation/Questions
22:00 - Do you want to meet the trust to the gateway?
24:09 - Is there some way to extrapolate the state root contract on a zk roll up?
24:33 - What would we have on the side chains?
26:24 - How would you know what gateway will get returned from the original exceptions?
27:21 - Does any contract call in Ethers needs to be overloaded so that it gets an exception in 3668 format that automatically recognizes that as being part of this EIP and makes those additional calls?
28:43 - What was happening on the Eth call layer?
29:23 - How important is it to have compatibility with the IPFS platform? Does the proposal support? If not, is there an alternative?
31:40 - Could you talk about some of the other projects that you think of that can be simple and useful use cases of this proposal?
33:45 - Do you think this proposal would have helped the ENS airdrop, had this been a standard?
34:39 - Before this proposal was it not possible to make a network request which was off chain?
35:12 - In absence of specified validation specifications, do you think there is room for vulnerability in the project implementing this proposal?
37:00 - Would you have any specific recommendation for consideration to dapp devs?
38:16 - Why would you want to make a gateway request in the first place?
40:30 - Is this a standardized approach to storage being expensive?
40:55 - How much gas is being saved with the proposal?
42:40 - What is gateway? Is that a standard interface that is used throughout the industry?
44:00 - Are there any applications that you know that are built in the CCIP read or a bulky solution?
Resources:
------------------
EIP-721 - https://eips.ethereum.org/EIPS/eip-3668
Discussion - https://ethereum-magicians.org/t/durin-secure-offchain-data-retrieval/6728
Slides - https://docs.google.com/presentation/d/1qq93BL-Yq0TrQDdbs7HgkKOzE3wlDkJlRaCq6mEbtHY/edit#slide=id.g3e04caa69e_1_2
Follow at Twitter
-----------------------------------------------
Nick Johnson @nicksdjohnson | William Schwab @William94029369 | Brent Allsop @Brent_Allsop | Alita moore @AlitaMoore85 | Pooja Ranjan @poojaranjan19
ERCs playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
the
59th
episode
of
epenny,
an
educational
video
series
where
we
learn
about
an
ethereum
improvement
proposal,
upcoming
updates
and
the
basics
of
ethereum
blog,
I'm
your
host
pooja
rantan
and
today
we
are
going
to
talk
about
eip.
3668
ccip,
read
secure
of
data
chain
retrieval
with
our
special
guest
nick
johnson,
and
we
are
also
joined
by
william
shaw,
balita,
more
brent,
alsop
and
chewbacca
from
the
ethereum
catholic
team.
A
He
was
on
the
show
in
the
past
to
talk
about
potential
direction
for
new
eips,
a
couple
of
other
proposals:
eip137,
that
is
the
ethereum
domain
name
service
and
the
eip2544,
which
is
ens
wildcard
resolution.
So
if
you
missed
it
earlier,
please
check
out
the
episodes
17
and
29
on
the
penny.
Playlist
video
links
are
also
be
found
on
the
top
right
corner
of
your
screen.
A
A
B
So
today
I'm
going
to
go
over
what
the
what
the
problem
that
we
encountered
is
that
motivated
us
to
to
build
this
in
the
first
place,
a
sort
of
a
review
of
the
existing
ecosystem
tools.
Why
we
couldn't
identify
anything
that
already
did
what
we
needed
to
do.
The
proposed
architecture
for
3668,
a
very
short
demo
of
of
how
it
works
in
practice
and
then
some
more
information
on
what
we've
done
so
far
and
what
our
next
steps
are.
B
So,
first
of
all,
like
it's
really
useful
to
start
by
talking
about
what
it
is
that
we're
actually
trying
to
do
and
why
we
found
the
need
for
a
standard
in
the
first
place
so
with
ens.
One
of
our
primary
goals
at
the
moment
is
to
move
as
much
stuff
to
l2s
and
off
l1
as
possible
in
order
to
optimize
gas
efficiency
and
reduce
costs
for
users,
and
in
doing
that
we
have
some
fairly
unique
requirements
that
are
different
from
your
average.
B
You
know
defy
or
token
application
in
that
most
vns
is
concerned
with
reactivity,
with
people
resolving
names
and
so
forth,
and
so
we
have
some
fairly
unique
requirements.
We
don't
don't
want
the
clients,
that
is
the
pieces
of
software,
that
do
the
resolution,
like
your
wallet,
to
have
to
know
how
to
query
every
different
l2
and
we
want
the
owners
of
names
to
be
able
to
choose
the
l2
of
their
choice
rather
than
having
one
forced
on
them.
B
As
you
know
now,
ens
is
on
polygon
or
any
other
network,
and
when
clients
are
querying
in
l2,
we
need
no
additional
trust
assumptions.
So
if
it's
a
true
l2
that
has
no
trust
assumptions
for
verifying
state,
we
shouldn't
be
introducing
any
with
like
a
consortium
of
signers
or
anything
like
that
without
any
l1
commits
on
update.
B
So
that
means
that
if
you
own
a
name
and
you've
moved
it
to
say
optimism
and
you
want
to
create
a
subdomain,
you
shouldn't
have
to
create
a
transaction
on
how
one-
and
nor
should
some
back-end
system
have
to
do
so
and
without
any
transactions
for
queries.
Obviously,
because
when
you
look
up
a
name
in
your
wallet,
it
would
be
intractable
if
you
had
to
do
a
transaction
in
order
to
make
a
query
and
without
any
hard
requirements
on
the
capabilities
of
that
l2.
B
So
we
want
to
support
not
just
evm
compatible
l2s,
but
a
variety
of
other
l2s
and,
as
you'll
see
soon
even
things
that
aren't
strictly
speaking
l2s
at
all,
and
this
seems
like
a
fairly
steep
list
of
requirements.
You
know
nigh
unachievable,
perhaps,
but
it
turns
out
that
a
solution
is
both
practical
and
really
fairly
straightforward.
B
So
our
first
step
was
to
look
at
how
existing
l2
integrations
work,
and
so
the
the
interaction
model
on
existing
l2
integrations
tends
to
be
quite
different
from
what
we
need
the
the
basic
high
level
primitive,
that's
typically
provided
as
a
token
bridge.
So
you
have
a
token
on
l1.
You
want
to
move
it
to
say
you
know,
optimism,
you
use
some
sort
of
bridge
and
what
that
does.
B
We
need
to
send
a
transaction
in
order
to
resolve
the
name,
and
we've
already
said
neither
of
those
are
acceptable.
So,
what's
message
passing
built
on
the
basic
primitive
for
pretty
much,
all
bridges
is
prove
something
exists
or
happened
on
l2,
or
vice
versa,
for
l1,
and
this
is
a
much
more
useful,
primitive.
So
to
give
you
an
idea
of
how
this
works,
when
you
send
a
token
from
ethereum
to
optimism
what
it
looks
like
what
it
looks
like
is
that
you're
sending
a
token
underlying
that
you're?
B
We
can
use
this
to
fetch
storage
proofs
from
a
gateway
which
is
a
dedicated
server
whose
job
it
is
to
fetch
information
from
a
system
such
as
optimism
and
format
it
in
a
way
that's
commonly
understandable
to
the
client
without
the
client
having
to
care
about
which
particular
l2
it
is
or
what
the
format
of
the
proofs
are,
and
then
we
can
verify
them
in
the
callback
on
the
contract
and
return
the
result
to
the
client.
So
a
concrete
example
probably
helps
here
and
here's
my
ascii
tastic
process
diagram.
For
this.
B
B
The
contract
is
the
smart
contract
on
ethereum
l1
that
it
was
originally
trying
to
query
and
the
gateway
is
a
service
whose
job
it
is
to
help
the
client
and
the
contract
fetch
the
soft
chain
data
and
return
it
in
a
way
they
can
handle
it.
So
the
whole
system
works
starting
the
same
way
as
any
regular
contracts
call.
B
So
the
client
makes
a
call
to
some
function
on
the
contract,
which
would
normally
simply
return
return
data,
but
instead
of
returning
return
data,
the
contract
reverts
with
an
error,
and
here
we're
using
solidity's
recent
support
for
custom
errors
to
good
effect,
because
this
is
a
way
for
us
to
convey
exception
data.
It's
more
an
exception
than
an
actual
error,
and
the
error
returns
worth
has
a
number
of
parameters.
It
says
this
is
the
contract
that
needs
external
data,
which
will
usually
be
the
one
you
just
called
here.
B
Are
the
urls
for
some
gateways
that
you
can
consult
for
this
data.
Here
is
the
data
that
you
should
pass
those
gateways.
So
here's
the
question:
the
contract
wants
to
ask
the
gateways
and
when
you're
done,
please
call
the
callback
function
on
the
same
contract
with
the
response
and
also
with
some
extra
data.
So
we
get
all
of
this
back
all
five
parameters
and
the
client
then
goes
and
makes
an
http
request
to
the
gateway
that
it
was
provided.
B
The
url
for,
with
the
address
of
the
contract
that
requested
it
and
all
the
cool
data
that
that
contract
needed-
and
it's
important
to
note
here,
that
call
data
callback
function.
Extra
data
are
all
completely
opaque
to
the
client.
It
doesn't
have
to
care
how
they're
formatted,
whether
they're
abi,
encoded
or
something
else
the
gateway
has
to
understand
it
in
some
fashion.
B
The
contract
is
to
understand
it
in
some
fashion,
but
from
the
client's
point
of
view,
this
is
just
a
blob,
so
we
go
and
make
an
http
request
to
the
gateway
with
that
data,
and
it
comes
back
with
a
result
which
again
is
completely
opaque
to
the
client.
All
we
have
to
know
is
that
it's
binary
data
of
some
form
and
then
finally,
we
call
the
original
contract.
B
But
the
case
we
have
particularly
in
mind
is
working
with
l2s
and
working
with
proofs.
So
a
concrete
example.
In
this
case
the
client
is
intending
to
resolve
an
e
s
name.
The
contract
is
an
ens
resolver
and
we
go
and
ask
it.
What
is
the
address
of
this
and
it
comes
back
and
says
I
need
some
extra
data
to
answer
that
question.
B
So
does
it
solve
our
problem?
Well,
we've
got
no
additional
trust
assumptions
because
we
can
build
a
gateway
and
a
client
that
verify
any
sort
of
proof
we
want
and
we
can
utilize
the
existing
infrastructure
that
people
have
built
for
message
passing
and
token
gateways
in
order
to
generate
and
verify
these
proofs.
There's
no
l1
commitments
on
update
because
we're
taking
advantage
of
the
system
that
the
existing
system
for
serializing
state
routes
to
l1
the
very
thing
that
makes
rollups
work.
B
B
It's
a
generic
pattern
for
making
allowing
contracts
to
make
any
sort
of
asynchronous
request
off
chain,
so
it
works
with
other
external
systems.
You
don't
have
to
be
talking
to
an
l2.
You
could
be
talking
to
a
flat
text
file.
You
could
be
talking
to
a
traditional
api.
You
can
be
talking
to
pretty
much
anything.
The
only
limitation
here
is
that
the
contract
that
made
the
call
has
to
have
some
way
of
verifying
the
accuracy
of
the
data.
That's
returned.
You
know
this
isn't
a
magic.
B
You
know
secret
source
that
lets
you
fetch
data
trustlessly,
unless
you
already
have
a
way
to
verify
that
data.
So
you
could
use
this
to
fetch.
You
know
the
current
token
price
from
an
api,
for
instance,
but
you're
still
going
to
need
some
way
to
know
that
the
client,
the
user,
that's
submitting.
That
call
gave
you
an
accurate
value,
but
it
can
be
used
on
any
application
that
needs
to
read
off
chain
data.
B
So
ens
is
the
obvious
case
here,
but
another
example
and
one
we've
actually
worked
an
example
for
so
people
can
see
how
it
works
and
I'll
demo
shortly
is.
You
could
have,
for
instance,
example,
tokens
on
layer,
2
systems.
You
could
have
merkle
airdrops,
where
the
claim
interface
is
simply
transferring
the
tokens.
You
don't
have
to
have
a
specialized
site
and
and
really
you
can
have
just
about
any
sort
of
fetch
system
you
want,
and
it
can
be.
B
So
I
have
now
a
very
short
demo.
We
have
here
a
sample
program
which
I'll
share
now
that
this
is
a
fairly
standard
web
3
application.
There's
a
there's,
a
fair
bit
of
boilerplate
here,
which
I'll
ask
you
to
hopefully
ignore
what
we're
doing
here
is
we
we
have
a
token
at
some
token
address.
We
have
a
web3
provider,
we
have
an
account
we're
using
to
send
transactions,
and
we
want
to
send
some
tokens
from
one
account
to
another.
B
B
Sorry,
the
original
account
we
make
in
the
rc20
transfer,
and
then
we
check
the
balance
again
so
far.
So
simple,
the
one
change,
the
only
change
we
need
to
make
at
the
moment
in
order
to
support
using
3668
to
do
this
is
that,
instead
of
just
the
standard
provider,
we
wrap
it
in
this
piece
of
middleware
that
we've
written
called
the
ccop
read
provider.
So
we
take
a
standard,
web3
provider
and
this
provider
here
wraps
it
and
provides
all
the
functionality
we
just
described
and
with
that
this
all
of
the
contract
calls.
B
B
B
So
now
I
am
deploying
the
the
token
to
my
hardhat
node,
and
so
in
this
particular
example,
our
l2
is
actually
basically
a
text
file
of
balances
that
are
available
offline
and
are
signed
by
some
trusted
key.
So
this
isn't
using
like
a
real
l2.
This
is
a
much
simpler
demo
that
uses
a
sing,
a
gateway.
That
basically
says
I
will
sign
responses
to
say
they're
accurate
and
then
I
will.
B
B
It's
simply
here
we
go
it
fetches,
the
balance,
it
checks,
the
balance,
the
recipient
transfers,
one
token
checks
the
new
balances,
it's
not
much
to
look
at,
but
every
single
one
of
these
calls
involved
a
call
to
the
eep,
3668
gateway
and
involved
transparently
fetching
and
signing
data
without
the
client
code
having
to
know
or
care
about
how
that
actually
worked
and
I'll
briefly
show
off
the
so
these
are.
Our
contract
calls
I'll
briefly
show
off
the
gateway
as
well,
which
is.
B
B
And
you
can
see
that
the
whole
thing's
only
about
45
lines
long.
This
is
the
relevant
thing.
It
implements
a
function
called
get
signed
balance.
It
simply
looks
up
the
balances
in
an
array
of
balances,
signs
a
message
attesting
that
that
was
the
correct
balance
and
returns
both
the
balance
and
the
signature.
So
the
whole
implementation,
including
boilerplate,
is
less
than
50
lines.
Long.
B
And
so,
finally,
what
have
we
done
so
far?
And
what's
next
so
eep
3668
ccip,
read,
is
recently
moved
to
last
call.
We've
done
a
lot
of
work
on
it.
We've
gone
through
a
number
of
iterations
and
it's
gone
from
a
very
basic
starting
point
to
what
I
think
is
the
much
more
flexible
and
versatile
solution
we
have
today,
a
gateway
server
library
is
available,
so
that
is
the
framework
you
saw
in
the
last
snippet
of
code.
B
B
An
ethos
provider
is
also
available.
That's
what
we
were
using
in
the
first
snippet
I
shared,
and
it
allows
you
to
make
contract
calls
using
ccip
read
without
having
to
change
your
code
at
all,
and
in
fact
we
anticipate
this
package
becoming
obsolete
soon,
because
we're
working
on
getting
this
integrated
directly
into
ethers.
So
you
will
simply
be
able
to
make
these
calls
without
having
to
make
any
changes
to
your
code
at
all,
and
you
can
find
example
code
as
well.
B
Next
steps
actually
getting
through
the
last
call
stage
of
3668
getting
us
integrated
into
ethers,
web
3gs
and
others,
and
building
standardized
gateway
servers
for
standard
l2s.
So
we
can
have
a
gateway
server
that,
for
instance,
features
a
particular
storage
key
and
returns
the
key
along
with
its
integrity
proof,
and
then
that
can
be
used
by
systems
like
enes
or
anything
else,
without
the
need
to
write
a
new
gateway
server
for
for
every
individual
application,
and
that's
all
I
have
for
the
presentation.
A
C
B
So
if
the
gateway
lied,
then
the
proofs
would
fail.
The
the
other
avenue
that
a
gateway
could
mislead
is
by
answering
one
query
with
a
valid
answer
to
a
different
query.
So
I
ask
what
does
example
delete
resolve
to
and
it
returns
me
vitalik.d
and
the
way
we
avoid,
that
is
by
allowing
the
original
contract
to
pass
some
extra
context
to
the
callback
via
the
client.
C
Interesting,
I
think
what
I
was
missing
is
I
didn't
realize
that
you
could
use
the
optimism
gateway
like
the
optimism
contract
on
layer,
one
to
verify
the
state
route
of
a
contract.
You
can
verify
any
optimism:
contract
state
route
through
the
optimism
contract
on
okay,
yeah.
That's
what
I
was
missing.
The
picture
over
there
cool.
B
And
this
this
isn't
unique
to
optimism
either,
because
the
fundamental
primitive
of
every
l2
is
that
its
security
ties
back
to
l1
and
the
way
it
does,
that
is
by
allowing
l1
to
verify
state
transitions
and
so
forth
and
sort
of
by
necessity.
That
means
we
can
kind
of
hijack
that
behavior
in
order
to
get
whatever
proofs.
We
need
without
any
additional
trust.
C
B
So
the
side
chain's
a
little
trickier
if
you
well,
you
know
the
same
for
bridging
to
other
l1s.
If
you
have,
if
those
sidechains
have
a
gateway
that
allows
for
signing
messages,
so
you
you
pass
in
a
a
request
and
they
give
you
back
a
message
signed
by
a
consortium
of
validators.
That
says
yes,
that's
correct,
then
we
can
utilize
that
same
thing,
but
in
some
cases
these
these
bridges
don't
expose
that
api.
They
simply
expose.
B
You
know
token
movement
and
all
of
that
happens
via
a
private
api,
and
so
in
that
case
we
either
need
to
get
them
to
add
that
public
functionality,
so
we
can
utilize
it,
in
which
case
there
are
no
additional
trust
assumptions.
You
know
it's
it,
but
it
is
still
trusted.
You
know,
in
the
same
sense,
that
a
regular
bridge
to
that
that
network
is
if
they
won't
or
can't
expose
it,
then
we
would
have
to
run
our
own
consortium
of
signers.
B
And
and
in
mind,
that's
very
much
the
you
know
of
the
three
possible
solutions,
that's
the
least
preferable,
because
it's
best
to
be
able
to
do
this.
First
of
all,
with
no
trust
or,
second
of
all,
with
the
same
trust
as
you
already
assumed.
But
if
you
need
to
you,
can
you
can
fall
back
to
the
solution
as
well.
C
B
B
You
know
there
is
a
potential
issue
here
with
with
things
like
fingerprinting
and
so
on,
where
contracts
like
basically
just
causes
the
client
to
make
a
call
so
that
they,
then
you
know,
know
which
clients
are
visiting
that
contract,
and
so
for
that
we
may
need
some
sort
of
white
list,
but
from
a
security
point
of
view,
I
kind
of
view
it
as
the
same
as
like
the
contracts
could
also
rely
on.
You
know
on
unreliable
oracles
or
none
at
all,
or
it
could
just
accept
values
from
the
user
already.
C
Interesting,
and
also
just
by
way
of
clarification
when
ethers
or
library
like
that
would
implement,
would
implement
something
like
this.
So
I
saw
in
your
code
that
basically,
you
had
the
standard,
erc20
dot
transfer
with
the
arguments
right
after
that.
So
does
that
mean
that
basically,
any
contract
call
in
ethers
needs
to
be
overloaded
that
if
it
gets
an
exception
in
a
3668
format
that
it
automatically
recognizes
that
as
being
a
part
of
this
eip
and
knows
to
make
the
additional
calls
it.
B
Pretty
much
it
happens
at
a
slightly
lower
layer
than
that,
like
it
happens
at
the
east
core
rbc
layer,
because
it
doesn't
need
to
because
the
whole
thing's
opaque.
It
doesn't
even
need
to
know
anything
about
the
abi
encoding
of
the
contract
call,
but
it
does.
It
does
get
intercepted
in
the
way
you
described.
Yeah.
C
Oh
wait,
so
I
think
there
might
be
something
here
that
I'm
not
that
I'm
not
understanding
right.
The
way
I
understood
it
was
that
the
the
contract
on
l1
returns,
the
all
this
data
and
then
the
the
front
end
like
the
client
not
necessarily
a
front
end
unpacks
that
data
in
order
to
make
an
http
call
and
then
it
makes
a
separate.
Then
it
makes
a
separate
call
after
that.
That's.
C
C
A
Well,
I
have
couple
of
more
questions
for
you.
I
see
this
proposal
has
generated
some
decent
conversation
on
the
discussion
to
link
and
from
there.
My
first
question
is
the
compatibility
with
the
ips,
so
how
important
is
it
to
have
the
compatibility
with
the
ibs
like
platform
for
a
projects
to
implement
this
proposal
is
eip3668.
A
B
But
somebody
pointed
out
that,
like
in
many
cases,
it
may
be
useful
to
have
a
static
set
of
proofs,
so
you
could
imagine
a
situation
where
a
contract
wants
to
fetch
one
of
a
very
large
number
of
of
pieces
of
off-chain
data,
but
that
data
doesn't
generally
change.
So
you
know
to
take
a
random
example.
B
You
might
have
a
an
nft
where
you
need
to
be
able
to
access
the
metadata
on
chain,
but
obviously
you
can't
store
it
all
on
chain,
and
so
there
you
could
actually
pre-calculate
all
the
possible
responses
and
store
them.
But
that's
sort
of
all
for
naught.
If
your
gateway
then
has
to
be
a
dynamic
service
and
serve
them
up
on
the
fly.
You
know
from
post
requests
anyway.
A
That's
interesting,
I
mean
yes,
I
understand
that
people
are
using
ipfs
and
it
will
be
helpful
that
if
this
proposal
provides
some
of
the
facilitation
to
integrate
that
so
that's
nice
to
know,
other
thing
is
about
the
project
implementation.
You
mentioned
that
ethers
and
chain
link
may
have
some
implementation
or
the
snippet
that
you
shared.
Could
you
talk
about
some
of
the
other
projects
that
you
can
think
of?
That
can
be
simple
and
useful
use
cases
for
this
proposal.
B
It
presents
a
an
erc20
interface,
but
some
of
the
balances
and
the
transfer
functions
require
off-chain
data
to
complete,
and
I
you
know
the
other
example
I
gave
is
existing
oracle
services.
You
can
rewrite
a
gateway
or
an
oracle
as
sort
of
this
pull
mechanism
where
it
requests
data
when
it
needs
it
rather
than
a
push
mechanism
where
some
off-chain
service
features
the
data
and
submits
it
to
the
contract
on
an
ongoing
basis,
and
potentially
this
can
lead
to
gas
savings.
B
Where
your
users
update
the
oracle,
when
the
data
is
needed,
rather
than
you
having
to
update
the
oracle
on
a
regular
schedule,
even
though
maybe
nobody's
consulting
it,
and
as
I
say,
I'm
sure
that
there
are
others
beyond
this.
You
know
effectively,
you
can
think
of
it
as
providing
contracts
with
a
way
to
make
web
requests,
which
is
pretty
neat
in
my
book.
A
B
It's
it's
ironic,
like
yeah,
we
were
sort
of
looking
at
it
and
we
going
if
only
we
could
use
the
standard
we're
working
on
for
this
thing.
We're
doing
you
know,
but
it
just
wasn't
far
enough
along
if,
if
3668,
if
ccip
read,
had
been
integrated
into
wallets
at
the
time,
I
think
that's
probably
how
we
would
have
done
it
and
it
would
have
made
the
ux
simpler
to
users.
B
I
guess
the
other
motivation
we
had
is
we
really
wanted
to
onboard
people
into
the
dow?
Not
just
have
them
claim
tokens,
and
that
requires
like
walking
them
through
what
the
dao
is
and
what
the
constitution
is
and
so
on.
So
in
that
case,
maybe
we
would
have
had
to
just
stick
with
a
fairly
traditional
interface.
A
B
I
mean
you:
could
you
could
implement
a
similar
pattern
to
what
we
have
here?
You
know
your
your
initial
request
can
say:
hey,
go,
consult
this
thing
and
come
back
with
the
data,
but
you'd
be
building
it
more
or
less
bespoke
for
each
application,
and
so
you
add
an
awful
lot
of
overhead
coding
wise
to
each
time.
You
need
to
do
this,
whereas
this
provides
a
generic
pattern
for
it
and
on
the
client's
end,
makes
it
entirely
transparent.
A
A
B
I
think
this
will
be
made
somewhat
easier
by
having
standard
gateways
for
things
like
optimism
and
arbitrary
and
so
forth,
because
those
gateways
will
enforce
a
particular
form
of
response
and
reply,
and
they
will
come
with
solidity.
Libraries
that
enable
a
single
function
call
to
validate
the
response,
which
makes
it
sort
of
easier
to
build
the
right
solution
than
a
shoddy
one,
but
if
you're
building
a
custom
solution.
B
Yes,
you
have
to
think
first
of
all
about
how
am
I
going
to
validate
the
response
that
was
returned
is
accurate
and
and
remembering
that
you
can't
trust
data
sent
by
a
client
and,
secondly,
remembering
that
you
need
to
be
able
to
validate
that
it
was
actually
answering
the
question.
You
asked
not
some
unrelated
question.
A
B
So
if
you
are
working
on
something
we'd
very
much
like
to
hear
from
you
if
these
are
sufficient,
because
we've
altered
them.
Thinking
of
the
use
cases
we
have
in
mind,
but
I
have
no
doubt
that
there
will
be
others
that
we
haven't
anticipated
and
now
is
the
very
best
time
to
to
improve
it
and
make
it
more
general-
and
that's
already
happened
several
times
through
development
like
the
standard
is
substantially
better
than
it
would
have
been.
A
D
So
I
I
don't
fully
understand
the
proposal,
and
so
I
want
to
investigate
that
more
and
try
to
clarify
for
myself
and
maybe
that'll
be
helpful
for
others.
So
I
am
still
a
little
bit
confused
like
what
the
exact
because,
like
when
I
think
about
an
off-chain
lookup.
I'm
thinking
about
like
what
comes
to
mind
is
that
you
have
like
a
contract
and
then
on
the
contract
you're,
making
a
network
request
to
somewhere.
But
then
I
don't
unders
like
I'm,
not
really
sure
where
this
falls
in,
because
it's
like
why?
D
B
Or
something
yeah,
so
I
guess
the
the
simplest
example
is
you
you
want
to
save
on
contract
storage,
because
contract
storage
is
expensive,
but
you
still
need
some
of
that
data
in
order
to
to
complete
a
call
or
complete
a
transaction,
so
you're,
storing
it
off
chain,
but
on
chain
you're,
storing
something
that
allows
you
to
verify
the
the
validity.
So
trivial
example
is
you
have
a
large
database
of
data?
You
merkel
hash
it
all.
So
you
construct
a
merkle
tree.
B
You
store
the
root
in
the
contract
and
therefore
your
callers
can
can
provide
you
with
the
piece
of
data
needed
to
satisfy
their
particular
request
and
a
proof
that
that
is
part
of
the
tree
that
you
originally
committed
to,
and
so
all
of
that's
possible
today.
But
when
you
do
it,
you'd
be
building
a
custom
client
that
runs
in
the
user's
web
browser
that
understands
how
to
fetch
these
local
proofs
and
format
them
and
submit
them
to
the
contract
and
you'd,
be
writing
custom
contract.
Of
course.
That
understands
you
know
how
to
verify
those
proofs.
B
The
difference
here
with
with
ccip
read
is
that
you
can
do
all
of
that,
but
your
client
doesn't
have
to
know
anything
about
that,
so
your
client
simply
makes
a
call
and
transparently
behind
the
scenes.
The
contract
says.
Please
go
fetch
the
smoke
proof
for
me
and
return
it
and,
from
the
client's
point
of
view,
it
was
just
a
regular
call
without
having
to
worry
about
that
external
data.
D
A
B
So
it's
yeah
it's
difficult
to
say
I
guess,
because
it's
it's
very
application
specific
like
and
we
we
have
two
basic
operations
you
can
do
here.
You
can
make
contract
calls
and
those
have
always
been
off
chain
with
no
gas.
But
the
difference
is
that
now
you
can
easily
facilitate
fetching
data
from
from
a
gateway.
As
part
of
that
call-
and
you
know
you
if
you
decided
to
store
that
all
on
chain,
because
you
didn't
have
a
practical
pattern
for
that,
then
then
it
could
be.
B
You
know
effectively
unlimited
and
then
you
have
transactions.
Where
again,
you
can
now
fetch
it
off
chain
instead
of
of
storing
it
on
chain,
and
so
in
that
case,
in
some
cases,
what
you're
doing
is
you're
pushing
the
gas
from
the
time
when
you're
deploying
the
contract
and
inserting
the
data
to
the
time
when
you're
claiming
it.
B
And
if
you
don't
expect
you
know,
if
you
you
don't
expect
all
of
the
data
to
be
interacted
with
on
chain
in
a
short
period,
then
it
may
be
much
more
gas
efficient
to
do
that,
and
only
do
it
as
it's.
You
know
on
demand,
even
in
cases
where
you
expect
most
of
the
data
to
be
interacted
with
it
may
still
be.
Cheaper,
though,
because
call
data
is
a
is
an
awful
lot
cheaper
than
contract
storage.
You
know,
which
is
the
foundation
of
roll-ups.
D
B
B
B
Bulky
solution
so
since,
since
I
you
know
since
it
went
final,
I've
had
a
couple
of
people
reach
out
and
set
up
meetings
and
so
on,
because
they
have
ideas
that
they
think
will
fit
well
with
this,
but
beyond
the
ones
I
already
you
know
already
described
like
like
air
drops
and
off
chain
data
of
that
sort.
I'm
not
aware
of
other
applications
for
it
that
are
being
actively
built
out
today.
A
I
think
presentation
itself
was
quite
helpful
and
it
explained
a
lot.
I
don't
know
if
we
have,
I
mean
in
production
any
project
implementing
this,
but
we
may
hope
to
have
someone
soon
and
near
future.
We
appreciate
you
nick
taking
out
time
to
talk
about
this
unique
proposal
which
I
think
will
be
used
in
many
more
upcoming
projects
for
off
chain
data
retrieval.
A
So
thank
you
and
thanks
to
all
our
catholics
and
other
participants,
people
who
are
watching
this
recording
the
current
status
of
the
proposal
is
last
call
which
is
ending
on
january
24th.
It
means
the
eip
is
almost
ready
and
soon
going
to
be
in
the
final
status.
So
if
you
have
got
any
concerns,
this
is
the
best
time
to
join
the
discussion,
to
link
and
share
your
concerns
in
case
of
no
significant
changes
requested
during
this
review
period.
I
hope
this
proposal
will
move
to
the
final
status
by
the
end
of
this
month.
A
Should
you
have
any
question
on
this
proposal
or
any
other?
Let
us
know
in
the
comment
section
below
subscribe
to
the
ech
youtube
channel.
If
you
haven't
done
it
already
see
you
next
week
with
another
interesting
proposal.
I
believe
it
is
eip.
1967
till
then
keep
watching
keep
sharing
your
love
with
ethereum
cat
holders.