►
Description
Topics covered
-----------------------------
1:46 - Guest’s introduction
4:20 - Presentation EIP-1967
4:27 - A quick overview of the proxy types
7:06 - Which proxy use ERC 1967?
7:20 - What does ERC 1967 specify?
9:59 - The storage slots
10:46 - Hash collision in mapping is extremely unlikely. Is that because of how far into the storage they are?
12:35 - The events
13:38 - How to interpret these slots content?
15:28 - Example
16:50 - Why standardize?
18:50 - Links
19:00 - End of presentations, Q&A
19:23 - Clarity of how beacon slot works
21:20 - For all contracts which utilize this standard, be utilizing the same storage slot? How would that work?
23:05 - Is EIP-1967, the first proxy proposal that was implemented?
26:51 - Take on EIP-1822
27:30 - Are you aware of ways that contracts written in languages other than Solidity & Vyper may make use of this standard?
30:01 - Please pause pending ethereum/solidity#12547 so that we can link to Solidity project commitments rather than public comments from developers on that project.” Could you explain why and how is it important to be addressed and who is the responsible party to address the concern?
39:11 - Why is storage slot collision important? What’s the worst that could happen?
41:58 - Can you talk about the necessity of implementing an EIP in a dapp? How simple or complex was the implementation of EIP-1967 in Open Zeppelin?
45:42 - Are you aware of any project that is implementing EIP-1967?
47:57 - Beacon contract - is it anyway related to the beacon chain?
51:08 - What made you decide that the proposal is ready to be moved to the “Last Call” or become a standard?
53:34 - Can you briefly touch on the conflict of EIP-1967 with the Diamond standard?
59:23 - Advice for dapp developers
Resources:
------------------
EIP-1967 - https://eips.ethereum.org/EIPS/eip-1967
Discussion - https://ethereum-magicians.org/t/eip-1967-standard-proxy-storage-slots/3185
Slides - https://docs.google.com/presentation/d/1t-VWWASHCdKsqObVNYtHHknaf7uYHF0VNEWbTn8ddkk/edit?usp=sharing
Follow at Twitter
-----------------------------------------------
Hadrien Croubois @Amxx | 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
B
A
No
did
so.
Today's
topic
is
a
really
very
special
for
the
dapp
developers.
As
you
can
hear,
we
have
one
of
the
open
zaplin
developer
here.
This
is
special
to
the
project
that
deals
with
delegating
proxy
contracts.
So
I'm
looking
forward
to
learn
more
about
the
proposal,
but
before
we
get
there,
may
I
request
you
to
share
a
bit
on
your
background
and
how
you
stumbled
upon
ethereum
sure.
B
Well,
I
heard
about
ethereum
a
long
time
ago
and
didn't
really
pay
much
attention,
even
though
I
should
have.
I
really
came
across
ethereum
during
my
phd.
I
did
a
phd
in
france
at
economic
superiority
on
distributed
systems
and
my
phd
advisor
was
sharing
his
office
with
jill
fedak,
who
happened
to
be
one
of
the
co-founder
of
ixe,
which
is
a
french
startup
that
had
an
ico
in
2017..
B
Even
so,
it's
not-
and
this
was
very,
very
powerful
to
me-
and
this
is
what
brought
me
into
the
ethereum
ecosystem
as
a
way
to
to
implement
distributed
designs
and
during
my
first
year
at
ixa,
because
I
continued
working
there.
After
my
phd,
I
had
the
opportunity
to
attend
a
lot
of
community
conferences,
learning
about
the
ecosystems
being
an
ethereum
magician
learning
about
the
cat
holders,
all
that
interesting
stuff
and
about
the
erc
and
the
ip
process.
B
A
That's
pretty
interesting,
backstory
yeah,
it's
always
fun,
and
I
think
this
is
the
most
fun
part
of
the
talk.
I
love
to
meet
people
amazing
people
coming
into
the
blockchain
space,
especially
when
they
are
coming
directly
from
finishing
their
education
and
just
jumping
into
the
blockchain
industry.
So
it
was
great
great
to
hear
that
getting
back
to
today's
topic,
we
will
be
having
an
overview
of
proposal
1967.
A
B
B
So
maybe
we
can
go
through
the
first
side,
so
the
first
thing
we
want
I
want
to
discuss
is
like
this
proposal
is
about
proxies
and
upgradeability,
and
the
first
thing
is:
I
want
to
give
an
overview
of
what
is
my
vision
of
this
space.
Obviously,
maybe
many
people
might
have
other
opinions,
but
I
think
this
vision
helps
understand
what
scope
this
erc
applies
to,
and
the
first
thing
is
that
a
proxy
is
usually
a
smart
contract
that
can
either
directly
call
another
smart
contract
or
use
the
delegate
code
rules.
B
If
you
directly
call
other
contracts.
That
means
that
the
storage
you
are
working
on
is
another
contract,
and
then
your
proxy
is
basically
a
router
routing
code,
and
this
can
be
interesting,
but
it's
not
really
where
upgradeability
works.
When
you
are
on
the
delegate
call
root.
This
means
that,
even
though
you
are
using
the
code
of
another
account
another
contract,
you
are
using
your
own
storage,
and
this
is
where
upgradeability
works,
because
the
proxy's
through
storage
space
is
what's
actually
being
used,
and
here
I
would
this
divide
it
into
two
big
categories.
B
There
is
what
I
would
call
the
v
table
space.
I
mean
that's
for
my
background
in
c
plus
plus,
but
that's
what
the
diamond
pattern
that
is
described
in
a
few
erc's.
It
goes,
and
basically
this
is
where,
depending
on
the
message,
signature
you're
going
to
redirect
to
a
different
modules,
but
there
are
simple
proxies.
B
This
is
where
we're,
what
we're
focusing
on
it's
like
the
single
implementation
space,
and
that's
mean
that
it's
a
proxy
that's
going
to
delegate
and
it's
going
to
delegate
all
the
calls
that
are
incoming
to
a
single
implementation,
a
single
address
and
again
here
we
have
different
possibilities.
There
is
a
clone
pattern
that
is
erc
1167.
B
So
this
is
like
a
very
small
proxy
that
is
non-upgradable,
because
the
address
of
the
target
is
fixed
and
then
there
are
the
upgradeable
one
that
stores
the
address
into
storage,
so
it
can
be
edited
later
on
and
those
are
either
the
upgradeable
or
the
beacon
one,
which
is
something
that
opens
up
an
introduce
that
we
are
going
to
discuss,
and
basically
this
is
a
scope
of
erc
1967
those
available
and
become
so.
Those
are
proxies
that
use
delegate
code
to
target
an
implementation,
and
the
address
of
the
implementation
is
in
the
storage
space.
B
B
If
you
have
a
smart
contract,
values
are
going
to
be
stored
and
if
you
are
writing
in
solidity-
and
I
think
vipre
does
the
same-
it's
starting
at
slot
zero
and
then
it's
increasing
and
whenever
you
had
a
value
in
your
contract.
It's
a
new
slot
and
basically
what's
happening.
Is
that
the
linearized
version
of
the
contract
determines
which
slots
are
used
for
what?
And
if
you
do,
an
upgrade
and
you
modify
the
order
of
the
variable
or
you
do
it
differently.
B
But
one
of
the
storage
that
is
important
is
actually
the
address
of
the
of
the
implementation
and
that's
only
used
by
the
proxy.
It's
not
used
by
the
implementation
itself,
but
it's
important
that
this
is
kept
safe
across
upgrade
and
that
it's
not
overwritten
or
modified
by
mistake,
and
the
idea
is
that
we
should
not
use
the
four
slots
that
are
assigned
by
solidity
and
by
the
contract.
For
that
we
should
use
a
very
specific
slot.
B
B
So
basically
those
are
just
hashes
of
strings
and
there
are
arbitrary
values
and
that's
the
whole
point
is
that
those
should
not
conflict
with
anything
else,
because
it's
not
very
low
values
and
since
there
are
like
explicitly
the
hash
of
strings
that
have
been
determined
for
for
this
it
I
mean
it's
realistically
un
impossible
to
have
collision
or
we
don't
expect
to
have
any
collision
on
that.
So
so
it
should
be
like
slots
that
nobody
else
should
be
using
unless
they're
specifically
trying
to
to
use
this
specific
mechanism.
C
B
B
And
on
the
next
slide,
we
have
a
few
events
that
are
defined
that
should
be
emitted
whenever
one
of
these
slots
is
updated
and
that's
because
it's
not
easy,
I'm
not
sure
it's
even
possible
with
concluding
to
just
react
to
one
particular
slot
changing
on
like
any
contract.
But
it's
possible
to
listen
for
these
events,
to
identify
for
from
tooling
that
yeah
this.
B
If
this
implementation
slot
is
zero
and
if
the
beacon
slot
is
not
zero
and
both
should
not
be
nonzero
at
the
same
time,
it's
either
one
or
the
other
or
none
of
those.
If
the
beacon
slot
is
nonzero,
then
you
know
that
it's
also
a
proxy.
But
you
know
that
if
you
want
to
get
the
address
of
the
implementation,
you
should
not
use
this
slot.
B
You
should
interpret
the
value
of
the
slot
as
the
address
of
a
beacon,
and
you
can
call
the
implementation
function
on
the
beacon
to
get
the
actual
address
that
that
the
proxy
we
will
use.
Last
but
not
least,
there
is
this
admin
slot
and
in
many
cases
this
will
be
zero.
But
if
this
is
is
not
zero,
then
you
have
again
a
very
strong
clue
that
the
address
that
is
stored
there
is
the
account
that
is
authorized
to
do
upgrades
for,
for
this
contract,
obviously
upgrade
might
be
done
in
a
different
way.
B
That's
what
the
ups
pattern
does.
Maybe
we
will
discuss
that
later,
but
it's
just
like.
If
you
have
these
slots
being
set,
you
have
strong
clues.
If
those
are
not
said,
then
you
cannot
say
much
about
the
contract,
but
if
they
are
set,
it's
very
very
strong
ideas
and
on
the
next
slide
we
see
that
these
slots
are
being
used
by
our
implementation.
B
We
have
the
erc
1967
proxy
that
uses
the
implementation
slots,
but
doesn't
have
and
a
built-in
upgrade
mechanism,
so
it
doesn't
use
the
admin
slots.
We
have
the
transparent,
upgradable
proxy.
That
is
a
proxy
that
con
self
contains
upgradability
mechanism.
This
one
uses
both
slots
for
the
implementation
and
and
the
admin
slot
open.
Zaplin
also
has
the
beacon
proxy.
This
one
uses
the
beacon
slot
and
it's
not
modifiable
by
default.
B
I
also
discovered
that
other
contracts,
particularly
the
ethereum
proxy,
so
ethereum,
I
don't
think
it's
live
anymore,
but
it
used
to
be
a
smart
contract
based
wallet
and
it
used
proxy
to
make
the
creation
of
pro
of
for
that
from
your
user
as
cheap
as
possible,
and
they
use
the
same
slot
as
we
do.
Basically,
they
follow
dci,
dcrc.
B
So
the
question
is:
why
should
we
standardize
that-
and
there
are
two
things-
the
first
thing
is:
we
want
to
promote
good
practice
and
the
good
practice
is
to
isolate
the
proxy
specific
values
like
where
to
implement
from
the
storage
needed
by
the
underlying
values.
For
example,
if
you
have
an
upgradeable
year,
c20
you
have
your
symbol,
your
name,
your
total
supply,
your
allowance,
your
balances,
those
are
like,
like
specific
to
erc20,
and
those
should
be
separate
from
the
actual
address
of
that
is
used
by
the
proxy
for
doing
this.
B
Upgradability
things-
and
we
want-
I
mean
everybody.
I
think
in
this
space
understand
that
it's
a
good
practice
to
isolate
that,
and
we
want
to
isolate
that
outside
of
like
the
first
few
slots.
So
we
need
to
agree
on
where
to
put
it-
and
this
is
what
this
year
is
all
about.
Is
I
agree
on
that,
and
once
we
have
this
agreement,
then
we
know
that
proxies
will
not
conflict
with
one
another.
If
one
proxy
wants
to
point
to
a
logic
that
has
the
ability
to
upgrade
the
proxy,
then
it's
going
to
work
together.
B
That
appears,
when
you
are
interacting
with
a
contract,
that
is
a
proxy,
and
this
happens
not
with
all
the
proxy,
but
it
happened
with
the
ercers
in
1967,
because
metamask
is
aware
of
of
this
standard
that
is
in
this
erc
and
is
able
to
use
that
to
expose
additional
info
to
the
user.
That's
that's
truly.
What
this
year
is
about.
It's
not
just
about
contracts,
it's
about,
tooling,
that
he's
going
to
inspect
and
and
help
in
this
case
it's
mostly
developers,
but
it
could
also
be
end
users
in,
in
the
end.
A
E
It
so
I'm
trying
to
kind
of
gain
some
clarity
a
little
bit
on
the
the
way
that
this
hashing
works
or
like
the
beacon
slot,
like
the
the
key
and
specifically
what
I'm
wondering
is,
if
you
know
like
a,
I
think
it's
both
valuable
for
my
understanding
as
well
as
maybe
for
others
who
aren't
aware
of
like
how
solidity
works.
If
you
know
how
to
kind
of
relay
how
this
would
work
and
say
like
python
or
something
or
some
other
sort
of
standard,
more
popular
language
in
their
data
structures
like
objects.
B
Okay,
so
so
there's
what
you
have
to
keep
in
mind
is
that
these
slots,
that
the
way
we
end
up
with
this
number
is
not
really
important.
Those
numbers
are
just,
to
all
intents
and
purposes,
those
are
just
random
slots
and
by
taking
random
slots
we
avoid
conflict.
It's
just
the
way
we
generate
the
randomness.
B
It's
going
to
be
used
in
the
smart
contracts
or
entering
solidity
or
in
viper
to
read
values,
or
it's
going
to
be
used
by
by
tooling,
like
javascript
or
python
tooling.
That
would
want
to
inspect
the
blockchain
space.
This
would
be
done
through
a
provider,
so
I'm
mostly
familiar
with
essers.js,
but
all
providers
have
this.
I
mean
you
could
even
do
it
directly
in
rpc
command.
There
is
this
eth
get
storage
at
and
you
would
just
put
the
address
of
the
contract
and
this
arbitrary
value,
and
that
would
allow
you
to
read
the
story.
E
B
Each
contract
has
a
memory
space
that
is
its
own,
that
is
not
shared
with
other
contracts,
and
it's
it's
like
when
you
have.
I
don't
know
how
people
are
familiar
with
like
os
development,
but
each
process
has
its
own
view
of
the
memory
and
expect
from
very
specific
cases,
like
the
all.
Things
are
alone
in
the
system
and
like
the
each
smart
contract,
has
a
completely
available
storage
and,
like
all
two
to
the
256
slots,
are
supposedly
empty
and
contract.
B
A
and
contract
b
can
write
to
this
slot
number
and
it
would
not
be
shared.
It
would
be
each
in
their
own
view
and
basically,
what
happened
in
that
in
the
grand
tree
of
all
ethereum
state.
What
you
have
is
that
you
first
go
from
the
root
of
the
tree
to
the
contract
and
then
inside
once
you
reach
the
contract.
You
go
to
the
storage
slot,
so
tens
of
thousands
of
contracts
can
use
the
same
storage
slots.
B
A
Thank
you
alita,
so
I
have
a
few
questions
related
to
the
proposal.
I
understand
that
you
are
not
the
author,
so
I
will
try
to
put
questions
with
respect
to
open
sampling.
But
if
you
have,
you
know
answers
to
any
of
the
questions
that
may
be
addressed
to
author.
Please
feel
free
to
let
us
know
so
in
the
presentation.
You
did
talk
about.
Why
standard,
so
we
understand
the
reason
for
why
we
should
have
a
standard.
It's
actually
a
very
good
reason.
A
We
should
want
the
the
ecosystem
to
be
following
same
proposal,
same
standards.
We
know
that
there
were
other
proposals
for
proxy
and
delegating
proxy
standards
such
as
eip
897
eip1822,
that
is
a
universal
upgradable
proxy
and
even
the
proposal
1967
they
have
mention
of
this.
My
question
is
so
for
open.
Zaplin
is
eip
1967.
B
B
I
mean
it
contains
a
lot
of
description
of
how
proxy
should
work,
but
the
actual
technical
proposition
in
22
and
fran
can
correct
me
on
that,
because
I
know
he
also
knows
the
erc,
but
the
actual
proposition
technical
population
of
1822
is
how
an
implementation
should
advertise
that
it's
supporting
proxies
and
that
a
proxy
can
use
that
as
an
implementation,
and
in
fact,
what's
happening.
Is
that
not
only
those
are
complementary,
but
in
one
of
our
implementation,
what
we
call
the
ups
proxy?
B
Zeppelin
specific-
and
we
used
that
with
the
proxies
that
were
deployed
by
the
zos,
so
it
was
a
cli
for
a
great
ability
and
at
some
point
there
was
this
effort
that
this
is
not
just
an
open,
zipline,
tooling
and
opened
up
a
contract,
and
that's
when
we
moved
to
other
storage
slots
that
are
more
generic
that
are
not
really
open.
There
is
no
mention
of
open
zaping
in
the
way
they
are
computed
and
that's
where
we
put
an
effort
to
our
standardization.
A
Well,
that's
very
good
to
know
because
I
was
wondering
we
have
the
guest
author
of
the
proposal
1822
in
the
past.
I
think
it
was
about
one
and
a
half
years
ago
when
the
proposal
was
actively
pursued
and
currently
the
status
of
the
proposal
is
the
stagnant.
So
it
was
a.
It
was
a
conflicting
to
me
like
why
we
are
having
a
competitive
proposal
and
what
makes
1967
a
unique
or
a
special
that
can
be
proceeded
towards
being
the
standard.
A
That's
that
would
be
nice,
because
1822
is
another
one
of
a
kind
proposal
and
I
hope
that
it
will
be
used.
I
mean,
as
you
mentioned,
that
the
open
zaplin
is
already
using
this
for
some
other
purposes,
not
exactly
the
way
1967
is
being
used,
so
it
would
be
good
to
have
complimentary
proposals.
Thank
you.
My
next
question
is
about
eip
specification.
A
That
is
the
limitation
to
the
contract
language.
So,
as
I
understand
by
reading
the
proposal,
this,
this
proposal
is
helpful
for
contracts
written
in
languages
such
as
solidity
and
viper,
because
they
had
the
case
of
clashing
when
they
are
claiming
to
the
memory
storage
by
any
chance.
Are
you
aware
of
any
other
ways
by
which
the
tabs,
those
are
not
written
in
this
solidity
or
wiper,
can
make
use
of
this
standard.
B
Well,
one
thing
is
that,
even
in
the
solidity
version
we
we
are
so
low
level
with
storage
slots
that
basically
the
implementation
needs
to
resolve
to
ascend
to
your
assembly.
So
the
truth
is
it's
not
even
really
an
solidity
implementation.
It's
as
it
is
a
new
implementation
to
some
extent,
so
I'm
honestly
not
very
familiar
with
viper
and
I'm
even
less
familiar
with
lll
or
other
evm
targeting
contracts.
B
This
erc,
obviously
like
like
a
lot
of
vrcs,
like
your
c20,
for
example,
defines
standards
through
the
solidity
interface,
because
that's
what
developers
are
mostly
familiar
with,
but
the
truth
is
what
we
we
imply
solidity
encoding
and
decoding.
But
the
underlying
thing
is
that
we
are
designing
things
that
are
very
low
level
that
are
evm,
for
example,
in
the
rc20,
when
you
are
defining
the
transfer
function,
you
are
just
defining
a
message:
signature
for
first
byte
and
you're,
defining
a
way
to
encode
a
call
when
you
send
it
to
a
contract.
B
You
are
expecting
changes,
and
here
it's
even
truer
in
the
sense
that
we
are
designing.
We
are
designing.
We
are
sending
bcrc
crc
around
a
storage
slot,
which
is
basically
very
low
level
evm
consideration
of
how
to
do
an
m
store
assembly
call,
and
we
are
also
designing
events
and
events.
We
we
write
them
in
solidity
for
for
ease
of
use,
but
in
the
end,
it's
just
like
a
log
assembly
call
that
people
could
do
like
in
in
in
evm
assembly
if
they
wanted.
A
All
right,
but
that
brings
to
another
question
like
we-
can
clearly
understand
the
relationship
with
this
proposal
and
solidity.
Obviously
there
are
many
more
proposals,
many
more
erc,
especially
which
are
related
in
solidity.
I
found
a
very
unique
comment
in
the
proposal.
I
understand
there
is
an
open
pull
request
to
move
it
to
the
last
call.
It
was
mentioned
that
please
pause
pending
that
there
is
this
issue,
I'm
gonna
share.
A
D
Yeah,
so
what
what
puja
is
referring
to
here
is
in
the
eip.
There
is
a
basically
a
link
to
a
tweet
by
one
of
the
salinity
core
developers
where
he
essentially
promises
that
the
language
is
not
going
to
change
the
way
that
storage
variables
are
laid
out
in
the
in
a
in
a
contract
right,
an
insanity
contract.
D
There
is
some
potential
that
a
language
a
compiler,
something
like
that
could
define
a
new
convention
for
putting
values
in
storage
that
would
conflict
with
the
values
that
we
chose
here
right
and
by
this
we
mean
that
simple
code
written
by
the
user
right
like
high-level
code
without
result
resorting
to
any
sort
of
assembly
or
low-level
op
code
and
so
on.
A
simple
contract
like
that
should
not
clash
with
the
storage
slots
that
are
defined
in
the
eip.
D
D
B
Yeah,
for
I
mean
I
tried
running
some
numbers
today,
we
don't
have
an
exact
figure
because
it's
hard
to
to
detect
it,
but
the
number
of
transparent
or
ups
proxy,
so
proxy
of
any
kind,
whether
they're
opened
up
in
our
orders
that
are
both
using
or
events
upgraded
and
the
storage
slot
for
the
implementation.
This
is
about
5
000
contracts
on
chain.
Now
we
also
defined
the
bitcoin
bacon
approach
and
we
will
discover
that
for
the
beacon
approach
there
is
way
less.
B
B
I
don't
like
to
say
that,
but
like
this
is
already
widely
adopted
and
and
even
more
than
one
what
we
ourself
expected.
So
that's,
I
think
one
more
reason
say
like
hey:
this
is
not
just
something
we
want
to
push,
but
it's
something
that
already
gained
a
lot
of
attraction.
Hope
I
mean
it's
all.
I
think
it's
always
bad
to
standardize
after
the
fact
using
the
adoption
as
an
argument,
but
we
are
here.
A
That's
pretty
interesting,
so
just
one
a
follow-up
question
on
that.
I
found
this
comment
on
the
solidity
github,
so
I'm
just
wondering
like
how
is
it
the
responsibility
of
the
author
or
the
proposal,
and
why
is
it
so
much
required
that
this
should
be
resolved
first
before
we
can
move
the
proposal
to
the
finals?
Just
changing
some
of
the
specification
will
help.
D
D
I
I
mean
in
favor
completely
in
favor
of
documenting
assumptions,
right
and
document
and
documenting
guarantees
and
open
zeppelin
contracts
is
always
completely
in
favor
of
stability
and
backwards
compatibility
and
is
actually
something
that
we
also
try
to
convince
the
solidity
team,
often
to
to
prioritize
as
well,
which
of
course,
that
you
know
they
have
a
trade-off
with
evolving
the
language
and
not
making
breaking
changes.
But
anyway,
this
is
to
say,
I'm
absolutely
in
favor
of
documenting
this.
B
And
I'd
I
for
as
far
as
as
I
understand
this
concern
is
about
if
solidity
decided
to
change
the
way
they
used
or
nz,
or
any
language
uses
storage
from
the
high
level
code
to
the
low
level
execution
on
evm.
This
would
possibly
break
contracts
that
are
upgradable
using
erc
1967,
that's
true,
but
if
they
would
be
breaking
much
more,
I
mean
solidity.
Team
has
a
tendency
to
do
a
lot
of
breaking
change
during
versions,
and
I
think
that's,
okay,
the
language
is
evolving.
It's
very
soon.
B
One
thing
that
never
broke
is
the
storage
layout.
I
mean
this
is
the
main
thing
that
they
are
keeping
in
line
with,
because
they
understand
the
importance
of
that
and
if
they
were
to
change
that
it
would
affect
erc
1967,
but
it
would
affect
a
lot
of
other
erc's.
Basically,
anything
that
is
related
to
how
storage
work
during
a
great
ability
would
somehow
be
broken
by
that,
and
this
might
include
ercs.
That
are
already
final.
So
I
mean
it's
really
a
concern.
B
It's
a
concern
for
us,
but
it's
also
a
concern,
for
it
would
be
a
concern
for
the
entire
ecosystem.
If
that
was
to
happen-
and
this
is
something
we
need
to
document
us
from
say-
maybe
solidity,
so
it's
team
could
make
a
stronger
promise
that
this
is
something
that
they
really
really
don't
want
to
change.
But
we
don't
know
what
the
ecosystem
will
be
in
five
years.
A
C
E
This
one's
kind
of
broad
we're
not
really
broad,
but
I'm
just
wondering
like
there's,
been
a
lot
of
discussion
about
the
storage
slot
collision
and
how
that's
being
prevented.
But
why
is
that
so
important,
and
maybe
you
can
offer
like
a
like
if
that
were
not
the
case
where
it
was
prevented
like
what
could
happen?
B
So,
let's
take
an
example:
let's
imagine
a
contract
that
is
upgradable
like
like
what
we're
designing
here
and
there
is
a
slot
somewhere.
Let's
say
like
it's
like
a
drawer
somewhere
in
your
office.
That
is
where
you're
recording
the
address
of
the
implementation
of
that
is.
That
should
be
used,
and
this
is
very
critical
if
you
modify
that
or
change
that
the
proxy
will
stop
working
altogether,
it
would
be
like
closing
the
road
just
in
front
of
your
house.
Your
car
cannot
go
out
anymore
if
that
slot
is
not
modified.
B
If
the
road
keeps
being
directed
correctly,
everything
works
well
now.
Let's
imagine.
The
contract
that
we
are
discussing
is
an
erc20
token
and
someone's
decide
to
transfer
assets
from
israelites
to
his
father
or
his
brother,
and
the
father
of
the
brother
has
no
token
yet,
so
their
balance
is
zero
and
when
you
do
a
transfer,
this
balance
will
be
changed
from
zero
to
one
token
or
50
token,
depending
on
the
amount,
the
quest
transfer.
Now
this
new
balance,
the
balance
of
the
of
the
receiver
wallet.
B
This
is
also
a
storage
slot,
and
if
you
are
keeping
that
in
a
different
drawer,
then
there
is
no
issue,
but
if,
for
some
reason
there
is
a
clash,
meaning
that
the
drawer
that
you
use
to
store
the
balance
of
the
account
ends
up
being
the
same
where
they
used
as
an
implementation,
where
there
used
to
be
an
address
that
was
guaranteeing
proper
functionality
of
the
contract.
No,
there
is
a
number
that
is
not
an
address
and
whenever
this
number
is
going
to
be
interpreted
as
an
address,
it
would
lead
nowhere.
B
So
you
would
what
we
call
breaking
the
contract
like
it
would
not
work
anymore,
and
that's
that's
really
important,
and
it's
also
true
of
let's
imagine
a
contract
that
is
ownable
and
that
is
erc20.
When
you
do
a
transfer,
you
don't
want
the
owner
to
change,
so
you
need
those
stuff
to
live
in
very
different
places.
B
The
solidity
as
we
discussed,
ensured
that
inside
the
contract
inside
a
single
contract,
but
when
you
are
having
a
contract
and
a
proxy
that
delegates
to
it,
those
are
developed
in
parallel,
and
you
have
to
make
sure
that
there
is
no
conflict.
There
is
that's
why
we
are
selecting
these
like
random
slots.
That
solidity
would
never
assign.
A
Thank
you.
So
my
next
question
is
related
to
the
implementation
in
open
sampling.
You
did
talk
about
like
the
the
proposal
is
implemented
and
even
the
proposal
1822
was
implemented.
So
I
I'm
trying
to
understand
the
necessity
of
implementing
the
proposals.
Ethereum
improvement
proposals
in
ada
and
also
how
simple
or
complex
was
the
implementation
of
eip1967
in
the
opens
up
in.
B
B
I
think
that
implementing
this
erc
is
really
simple.
Like
we
we've
seen
I've
seen
implementations
today,
just
trying
to
figure
out
number.
I
discovered
that
this
ethereum
project
did
implement
it,
and
I
was
not
aware
of
that
and
their
implementation
is
maybe
20
lines
of
solidity,
maybe
59.
It's
very,
very
small,
now
obviously
open
the
pinocchio
implementation
might
be
complex
because
we
worked
with
it
for
a
long
time
and
we
designed
it
in
a
specific
way
that
we
wanted
to
provide
tooling
and
and
and
an
abstract
function,
and
that
kind
of
things.
B
So
obviously
the
code
might
look
bigger,
but
really
like
this
erc,
as
we
discussed,
is
about
those
three
slots
and
those
three
events
and
emitting
an
event
is
something
that
all
solidity
developer
knows
how
to
do
and
writing
to
a
specific
slot.
It's
not
the
most
basic
thing,
because
you
have
to
resort
to
assembly,
but
it's
one
of
the
most
simple
assembly
thing
and,
and
it's
just
three
or
four
lines
of
solidity
that
that
all
developers
would
understand
if
they
were
to
see
it.
B
So
again,
it's
as
far
as
an
h3
like
that
at
open
zipline.
We
have
a
tendency
to
implement
a
lot
of
erc
when
they
become
final,
for
example,
rc27
20
months,
there
are
erc,
like
777
that
are
really
complex
to
deal
with
and
I'm
sure
a
lot
of
developers
are
happy
that
we're
providing
an
implementation
because
they
would
have
a
hard
time
building
their
this
on
their
own
here
for
proxy.
It's
not
the
case.
It's
really
simple.
A
Well,
this
is
pretty
interesting,
like
ercs
has
to
advertise
obviously
like
when
we
are
trying
to
make
a
standard,
they
would
want
some
implementation
to
be
done
like
if
project
is
already
implementing
it.
It
is
always
helpful
to
push
the
proposal
towards
finalizing
and
if
a
proposal
is
being
finalized,
we
would
like
to
see
some
implementation,
so
they
are
like
going
hand
in
hand.
We
can't
separate
them
somehow,
but
it's
good
to
know
that
the
implementation
for
1967
was
not
as
complicated
as
it
could
be
for
some
of
the
other
proposals.
What.
B
So
actively
implementing
it,
I
mean
a
lot
of
projects
are
using
our
contract
because
I
mean
I've.
I've
discussed
that
there
are
about
5000
implementations
in
instances
out
there.
Some
are
on
implementation
or
implementation.
Some
are
older
implementation,
but
the
truth
is
almost
none
has
been
deployed
by
us,
because
that's
not
what
we
do
at
open
zipping.
B
We
don't
deploy
a
lot
of
contract
domain,
so
that
means
that
that's
saying
that
a
lot
of
projects
either
created
their
own
implementation
and
used
it
or
trusted
us
with
our
implementation
and
deployed
or
implementation
through
or
other
tooling.
We
provide
for
it.
So,
and
that's
also
one
of
the
effort
is
that
once
it's
standardized,
so
if
the
implementation
is
good,
there
is
no
need
to
reinvent
the
wheel
and
to
and
to
and
to
rewrite
it
from
scratch.
A
lot
of
people
are
using
what
we
provide
and
so
far
are
happy
with
it.
D
I
would
also
say
this:
isn't,
since
this
eip
is,
isn't
really
documenting
a
specifying
a
smart
contract
right,
it's
it's
specifying
storage
locations.
What
does
it
mean
exactly
to
implement
it
right?
And
I
would
say
that
maybe
etherscan
is
not
an
implementer
but
an
integrator
of
this
erc
because
they
read
this
these
storage
slots
in
their
application.
In
order
to
show
these
read
as
proxy
and
or
write
as
proxy.
A
That's
pretty
interesting,
like
I
remember,
reading
something
about
this
proposal
is
also
facilitating
some
of
the
infrastructure
providers
so
yeah.
It
is
a
good
use
case
there
all
right.
I
have
a
kind
of
naive
question,
maybe
for
people
who
are
not
very
much
familiar
with
these
terms,
or
maybe
they
have
seen
this
term
somewhere
else
about
the
beacon
contract
address.
So
can
you
just
explain
for
the
people
who
may
have
been
confused
like?
Is
it
anywhere
related
to
beacon
chain,
or
it's
just
a
term
that
was
used
here
for
simple
ercs.
B
Yeah,
so
it's
no
not
related
with
the
bitcoin
chain
at
all.
I
don't
know
which
one
predict
predate
the
order,
and
just
the
concept
of
beacon
is
pretty
standard
like
the
beacon
chain
is
like
a
beacon
for
the
ethereum
two
world
or
it's
signaling
and
generating
finality
here.
It's
a
way,
less
cool
beacon,
but
it's
still
a
beacon
in
the
sense
that
we
have
this
smart
contract
that
we
call
the
beacon
contract.
B
I
mean
they
are
connected
to
the
beacon
contract
and
they
use
it
as
a
reference
and,
what's
on
one
of
the
interesting
usage
of
that,
is
that
if
you
have
thousands
of
of
proxies
that
are
all
having
a
look
at
the
same
beacon
if
the
b
can
change
what
it's
signaling
like
like
the
bat
signal
in
batman
like
if
it
changes
the
shape
everybody's,
going
to
see
it
as
once
atomically
and
that's
how
you
can
upgrade
hundreds,
maybe
thousands
of
proxies
as
one
using
a
single
transaction.
That
is
pretty
cheap.
And
maybe
that's.
B
Why
we're
seeing
such
high
number
of
usage.
I
was
very
surprised
to
see
like
over
25
000
instances
of
this
beacon
proxy
exist,
but
in
the
end
it
really
makes
sense,
because,
if
you're,
an
application
that
has
thousands
of
contracts
that
you
want
all
upgradeable.
But
you
want
them
to
all,
follow
the
exact
same
implementation
and
not
upgrade
them
one
at
a
time.
This
is
really
the
design
should
go
for,
and
I'd
like
to
add
that
we
have
recently
been
improving
the
tooling
for
interacting
with
this
contract,
and
we
had
a
workshop
about
that.
D
I
just
want
to
make
one
small
correction
to
something
that
adrian
said
earlier.
The
beacon
pattern
wasn't
introduced
by
open
zeppelin,
we
adopted
it,
but
it
was
originally
developed
by
the
dharma
smart
wallet
and
it
makes
a
lot
of
sense
in
that
context
because
well
we
just
heard
I
think
today
or
yesterday
that
they're
being
acquired
and
the
dharmas
marvel
is
being
discontinued
by.
A
Thank
you
for
clarifying
that
well.
My
last
question
for
today
is
about
the
readiness
of
the
proposal
up.
I
am
curious
to
understand,
like
what
made
you
think
that
proposal
should
be
moved,
should
go
ahead
for
a
standard.
Is
it
like
the
implementation
getting
finished
and
open
zaplin
is
that
the
community
feedback,
or
any
other
thing
that
may
have
triggered,
decide
pushing
the
proposal
now.
B
We
did
I
mean
this-
this
erc
is
pretty
simple
and
is
is
doesn't
have
a
lot
of
movement.
There
was
movement
about
maybe
six
months
ago
when
we
described
the
beacon
inside
this
erc
because
it
used
to
only
be
about
like
the
implementation
and
the
admin
slot
and
we
added
beacon
so
that
it
it
fills
the
entire
scope
of
open,
ziplines
visions
of
upgradable
contracts.
B
B
If
it's
changing
it's
going
to
be
another
erc,
but
we
are
not
planning
on
that
and
we
are
also
going
to
focus
on
on
other
things
like
this
is
final,
so
we
can
focus
on
improving
18,
22
or
maybe
work
on
on
on
the
diamond
pattern,
or
something
else
but
like
to
us
like
or
like,
like
it's
exactly
the
thing
you're
seeing
on
screen
right
now.
We
have
this
division
of
of
of
what
this
proxy
space
is,
and
there
is
this
subset
of
the
tree.
A
B
So
I've
been
an
implementer
of
the
diamond
standard
when
it
was
not
even
called
diamond
standard
to
me.
That's
called
1538,
because
that
was
the
whole
name
of
this
proposal
and
diamond
was
just
like
rebranding
it,
but
the
technology
is
the
same,
and
I've
been
developing
erc
1538
when
I
worked
with
alexeg,
so
we're
going
back
to
the
early
stage
of
the
calls,
and
this
this
1538
is
also
used
in
production
by
exact
amounts
order.
I
guess
1338
is
different
in
the
sense
that
you
are
not
delegating
to
a
single
implementation.
B
You
are
delegating
to
multiple
implementation.
This
means
that
you
cannot
just
store
the
address
of
the
implementation.
You
have
to
store
at
least
a
mapping
that
goes
to
from
byte4
to
addresses,
so
the
amount
of
data
that
the
proxy
needs
to
to
work
with
to
to
operate
on
to
to
work
properly
is
is
a
different
structure.
It's
a
different
kind
of
things.
It's
basically
it's
the
same
way
that
you
would
not
attach
your
house
to
the
road
the
same
way.
You
would
attach
an
airport
to
the
road
like
it.
B
It
needs
different
access
because
it
needs
to
ship
different
kinds
of
vehicles
and
that
kind
of
thing.
So
to
me
there
is
absolutely
no
conflict
between
1967
and
and
the
diamond
standard
because
they
are
discussing
different
proxy
designs
with
different
needs
and
1967
is
about
the
the
proxy
design
for
for
for
single
implementation
and
diamond
is
different.
Maybe
this
diamond
implementation
will
find
that
some
of
the
things
that
1967
propose
is
useful,
for
example,
maybe
not
the
implementation
slot,
but
maybe
the
admin
slots
can
be
used
by
a
diamond
proxy
and
and
that's
fine.
B
A
B
Also,
if
I
I
mean
I'm
not
familiar
with
the
very
latest
change
of
diamond-
so
maybe
I'm
not
up
to
date,
but
last
time
I
checked
the
diamond
was
about
standardizing
the
idea
of
a
proxy
that
acts
as
a
router
and
about
standardizing
what
they
call
the
loop
mechanism
to
to
to
to
see
that.
But
this
implementation,
demon
implementation
doesn't
standardize
specific
storage
slots.
They
let
any
developer
implementing
in
any
way
they
want,
and
then
the
standardized
way
to
read
these
slots
through
view
functions,
which
is
a
bit
different.
B
I
would
argue
that
maybe
one
of
the
reasons
why
diamonds
are
conflicting
implementation
and
has
not
been
moving
faster,
is
maybe
because
it's
more
difficult
to
standardize
the
storage
slot,
which
is
a
very
important
thing,
because
if
you
are
not
standardizing
that
different
implementation
might
not
be
fully
compatible,
so
so
so
that's
I
mean
the
diamond
standard
is
objectively
way.
More
complex,
that's
much
more
moving
pieces.
B
I
personally
think
it's
it's
really
great.
That's
why
I
implemented
on
top
of
it.
Open
zapping
has
not
been
addressing
it
first
because
it
wasn't
standard,
but
also
because
we
think
that
the
tooling
required
to
to
work
with
it
securely
is,
is
much
bigger
and
unless
we're
ready
to
provide
the
tooling
for
that,
we're
not
going
to
provide
something
that
user
can
shoot
themselves
in
the
foot
with.
So
I
mean
I'm
pushing
forward
using
it
more,
but
I
also
understand
that
it's
it's
kind
of
difficult
and
it's
really
two
very
different
things.
D
Yeah
just
a
very
small
comment,
but
I
I
I
was
just
thinking
that,
even
though
they
are
like
in
a
sense,
competitive
competitor
standards,
right
I
mean
they
kind
of
they
both
define
different
kinds
of
proxies
right,
so
one
has
to
choose
one
or
the
other.
I
feel
like
the
standardization
of
both,
including
1967
benefits,
both
right,
because
it
makes
sure
that
there
are
no
conflicts
like,
for
example,
if
the
diamond
standard
decided
to
use
the
same
storage
slots
for
a
different
purpose.
D
A
Really
that's
interesting,
like
I
saw
that
comment,
and
it
was
like
quite
confusing,
like
should
diamond
standard,
be
having
some
specification
changes,
because
this
particular
proposal
is
providing
more
flexibility
to
actually
implement
the
proxy
sense.
Well,
it's
a
time
to
wrap
up
any
final
thoughts
or
advice
that
you
would
like
to
share
with
the
rest
of
the
adapt
developers
implementing
this
proposal.
D
A
Sweet
we
appreciate
you
both
joining
and
talking
about
eip
1967,
which
I
think
is
being
used
and
will
be
used
with
some
of
the
other
projects,
so
all
the
best
for
moving
the
proposal
forward
for
people
watching
the
recording.
The
current
status
of
this
proposal
is
review,
but
we
have
the
full
request
up
to
move
it
to
the
last
call.
So
if
you
have
any
questions,
comment
concerns
or
any
suggestion
related
to
this
proposal.
A
This
is
the
best
time,
as
a
friend
mentioned,
that
you
can
either
join
the
open
zaping
forum
or
go
ahead
with
the
fellowship
of
ethereum
magician
thread
that
is
added
to
the
proposal
share
your
thoughts
over
there
and
it's
not
thanks
to
all
our
youtube
viewers
for
watching
sending
us
questions
on
different
proposals
and
letting
us
know
that
how
they
are
implementing
their
proposals.
For
today's
episode.
If
you
have
any
question,
you
can
obviously
leave
a
comment
check
out
the
description
section
for
links
and
I
guess
twitter
to
follow
if
you
like.