►
From YouTube: Alice in Proxyland
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 IPFS and more.
https://archive.devcon.org/archive/watch/6/alice-in-proxyland/index
The story of Alice in her journey of making her smart contract upgradeable.
She starts with a very naive approach, and quickly bumps into the fundamental problems of proxies: using CALL vs DELEGATECALL, the execution context, storage collisions, the importance of tooling, etc.
As her system grows in complexity, her proxy architecture iterates and becomes more and more sophisticated, finally arriving to a very powerful, elegant and easy to use architecture: The Router Proxy.
Speaker(s): Alejandro Santander
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: proxies,upgradeability
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
Then
I
worked
with
Aragon
for
a
bit
and
now
I'm
working
with
synthetics,
mainly
addressing
the
problem
of
how
do
you
build
a
super
complex,
smart
contract
system,
in
a
way
that
you
can
iterate
through
it
and
fix
bugs
and
and
improve
an
experiment
and
other
than
that?
I
I.
Consider
myself
a
bit
of
a
an
educator
in
the
space
I.
Just
it's
not
that
I
know
a
lot
of
things.
I
I,
just
love
to
empower
other
people
with
with
knowledge
right.
A
So
what
we're
gonna
do
today
is
talk
about
proxies
and
then
like
in
general,
and
then
we're
gonna
talk
about
a
pretty
sophisticated
type
of
proxy
that
we're
using
in
synthetics,
so
I
think
that
it's
critical
for
for
everyone
to
understand
how
proxies
work
under
the
hood
I
think
that
it's
not
okay
for
a
Dev
to
use
proxies
and
not
know
how
they
work.
But
the
good
news
is
it's
that
they're
really
easy
like
in
the
end.
There's
like
no
mystery,
it's
very
easy
to
demystify
it
right.
A
So
I
I,
insist
besides
the
proxy
I'm
going
to
show
I.
Think
the
the
essence
of
this
talk
is
to
to
promote
the
awareness
of
how
proxies
work
and,
if
you're,
going
to
use
one
like
make
sure
you
understand
how
they
work
so
to
illustrate
this
we're
going
to
play
them
like
we're,
going
to
start
with
a
with
a
very
simple
contract
and
make
it
upgradable
and
see
what
happens.
A
So
this
is
the
contract.
I,
don't
know
if
it's
a
good
idea
to
bring
in
code
to
a
talk,
but
I,
don't
know
if
you
can
see
it,
but
it's
just
a
contract
that
sets
a
value
right.
It
has
a
function
set
value.
You
can
set
the
value
and
it
records
who
said
the
value,
it's
message
sender
and
an
image,
an
event:
that's
it
so
this
car,
this
contract
is
deployed
at
the
0x1
address
right
and
then,
after
deploying
it
Bob
calls
set
value.
A
42
right,
then
42
is
set
in
storage
slot
zero
because
the
variable
is
declared
it's.
The
first
variable
declared
and
zero
X
Bob,
which
is
the
address
of
Bob,
gets
stored
in
the
second
slot,
which
is
slot
one.
Okay,
that's
how
solidity
lays
out
storage
automatically
when
you
declare
variables
in
a
contract
and
an
event
is
emitted
from
0x1.
A
Now
they
decide
to
make
their
contact
upgradable
all
right.
How
does
this
work?
They
they
decide
to
deploy
a
proxy
which
is
just
a
function,
a
contract
that
has
a
function.
You
can
tell
it
what
the
current
implementation
is,
which
is
going
to
be
the
other
contract,
and
then
it
has
a
like
a
magic
assembly
function
which
forwards
anything
using
call
to
the
implementation
contract.
A
So
this
is
deployed
at
0x2,
then
Bob
calls
set
implementation
0x1
and
in
the
proxy
storage
it's
not.
Zero
now
holds
0x1
because
the
address
implementation
variable
is
declared
in
slot.
It's
the
first
one
declared
so
it's
saved
in
slot
zero,
then
they're
now
connected.
This
is
the
proxy,
and
this
is
implementation
and
block
calls
value
right.
A
A
That's
weird
right,
that's
message,
sender,
so
the
the
problem
that
we
have
here
is
that
call
makes
the
execution
context
to
be
the
implementation
of
the
proxy,
like
the
event
is
submitted
from
the
from
the
implementation,
which
is
also
not
a
good
thing
right,
because
you
don't
want
to
have
a
protocol
and
and
tell
people
like
to
be
changing,
addresses
every
time
you
update
the
implementation
right.
So
the
problem
that
we
have
with
this
particular
proxy
that
uses
call
is
that
the
execution
context
is
here
right
and
we
don't
want
that.
A
A
So
how
can
we
take
the
proxy?
The
execution
context
to
the
proxy
we
just
need
to
use
delegate
call
so
call
wants
the
code
that
we're
running
in
the
current
context
and
delegate
call
runs
the
code
in
the
context
of
the
caller
right.
So
here
we
have
a
second
proxy
right,
which
is
the
only
difference
is
that
it
uses
delicate
call
right.
A
A
The
execution
context
is
still
that
it's
fine
now
this
is
gonna
delegate
call
to
whatever
is
stored
in
the
implementation,
and
the
implementation
is
in
slot
zero
and
the
value
now
holds
one
three
three
seven
right.
So
what
are
we
delegating
call
to
to
some
contract
at
one
three,
three,
seven,
which
there's
probably
nothing
there
right.
So
we
just
we
have
a
storage
Collision
right.
A
We
overwrote
the
address
of
the
implementation
with
a
number
right,
so
we
basically
bricked
this
proxy
right.
So
daily
call
is
awesome,
but
it
is
dangerous
because
you
have
storage
collisions
so
to
solve.
This
Bob
goes
to
the
next
level
and
and
these
structures
the
proxy
storage.
So
what
is
this
structuring?
It's
basically
choosing
where
to
put
to
put
to
store
something.
That's
it
it's
not
using
solitaire's
custom
slots,
but
just
choosing
where
you
put
it
so
for
solidity.
First
variable:
is
it
zero?
A
Second,
at
one
Etc
and
you
have
infinite
slots,
destruction
is
just
picking
a
custom
slot
right.
So
we
have.
The
third
proxy
here
is
called
unstructured
proxy
and
the
difference
is
that
we
are
not
using
solidities
like
regular
storage
slots,
but
we
are
declaring
where
we
store
things
at
slot
1000
right
and
using
that
the
the
code
looks
a
little
bit
weirder,
but
that's
it
so
we
deploy
this
proxies.
He
works
for
we
connect
it
to
the
implementation.
Oh,
this
is
important.
Can
you
see
the
storage
it's?
A
The
implementation
address
is
stored
at
the
custom
slot
of
1000..
So
that's
destructured
right
now,
so
now
we
call
set
value.
It
makes
a
delegate
call.
The
execution
context
is
that
we
write
the
new
value
values,
but
they
don't
like
step
over.
Let's
say
the
implementation
address
right
and
the
event
comes
from
from
the
proxy,
which
is
fine,
so
we
have
a
proxy
that
works
right
and
now
we
can
upgrade
the
implementation,
because
we
we
know
that
it
works.
So
we
have
value
holder
V2.
A
A
A
A
So
Paul
understands
that
to
to
avoid
this,
you
in
an
implementation,
you,
you
only
append
to
the
storage
instead
of
like
putting
it
anywhere
right,
so
keep
moves
the
date
variable
to
the
end
of
the
previous
storage
layout,
and
that's
it
that's
pretty
a
pretty
simple
fix.
That's
another
rule
of
like
using
proxies,
always
a
pen
to,
and
now
this
value
is
gonna
get
whatever
is
stored
at
slot
zero,
which
is
one
three
three
seven.
So
it's
fine!
So
we
we
avoided
that
Collision!
A
So
storage
collisions
it's
it's
critical
to
understand
when
they
occur
and
it's
basically
the
two
types
of
collisions
that
I
just
showed
you
that's
it.
If
you
get
that
you,
you
can
pretty
much
think
about
any
type
of
coalition.
Things
to
consider
the
execution
context
is
always
the
proxy,
so
everything
is
stored
in
the
proxy
there's
two
type
of
collisions
that
we
just
talked
about.
A
The
first
kind
can
be
avoided
by
unstructuring,
the
storage
layout
and
the
the
second
one
can
be
avoided
by
just
making
sure
that
the
updates
to
the
storage
layout
and
implementations
is
valid,
always
append,
and
something
to
consider-
and
this
is
critical-
multiple
inheritance
flattens
your
contracts.
So
you
cannot
protect
the
storage
layout,
so
you
can
add
a
new
inherited
contract
to
you
to
your
like
super
contract
and
it
can
add,
like
five
new
variables
in
an
unpredicted
part
of
the
layout
part
of
the
layout.
A
A
A
A
And
we
can
see
that
we
have
the
gray
storage
we're
not
using
anymore.
We
have
the
proxy
name:
storage,
name
space,
let's
say
there
and
the
new
implementation
namespace
here
and
they
don't
Collide
right.
So
we've
unstructured
the
implementation
storage
right
now
we
have
we're
pretty
happy
with
this
proxy.
Like
configuration,
we,
the
the
context,
is
kept
at
the
proxy
and
collisions
are
avoided
using
unstructured
storage
or
storage.
A
So
there's
no
ideal
standard
solution
for
multi-contract
systems,
people
often
use
registry,
which
is
basically
a
contract.
That
knows
every
other
contract
right
and
whenever
a
contract
a
needs
to
talk
to
contract
B,
it
needs
to
go
to
the
registry
and
ask
hey:
I,
want
to
talk
to
business,
B,
here's
B
and
then
it
makes
a
call
to
contract.
B
right
and
then
B
needs,
if
it's
a
sensitive
operation
needs
to
say,
okay,
who's.
Calling
me
a
is
a
from
the
system.
A
A
So
we
basically
have
a
new
contract,
which
is
another
contract
that
has
one
variable.
It's
called
cool
value,
and
it's
also
using
these.
This
storage
name
space
system
instead
of
solidities
like
own
a
storage
layout
thingy,
but
that's
it
it
just
records
a
variable
right
gets
the
store,
sets
the
the
stores
value
and
then
it's
a
an
event.
A
A
It
has
the
addresses
of
the
two
contracts,
value
holder
and
another
contract
hard-coded,
and
it's
a
fallback
function
basically
has
to
do
like
this
binary
search
algorithm
to
determine
which
implementation
has
that
function
right.
Is
it
valueholder
or
is
it
another
contract
right
and
it
just
checks
the
incoming
selector
and
forwards
it
to
the
appropriate
implementation
and
that's
it
and
then
it
just
makes
the
the
regular
delegate
call
proxy
forwarding.
A
A
A
A
A
Everything
else
is
the
same,
and
Bob
sets
the
implementation
of
the
proxy
to
that
new
router.
So
that's
how
you
upgrade
the
any
contract
in
your
system.
So
what
would
a
more
complex
system?
Look
like
maybe
like
this.
You
have
the
main
proxy
right.
You
have
the
different
storage
name
spaces
of
that
proxy,
and
then
you
have
the
router,
which
you
keep
changing
every
time
you
upgrade
the
system
and
you
have
the
different
modules
that
specify
a
particular
behavior
of
your
system.
A
It's
like
a
concern
with
this
pattern,
because
you're
used
doing
two
delay,
calls
keep
in
mind
that
transparent
proxy
is
the
ones
almost
everyone
uses
costs
like
3
000
gas,
Universal
proxies
about
1600,
and
this
system
uses
only
2
600
gas,
which
is
all
right
and
then
intermodial,
intermodular
Communications.
How
would
a
module
talk
to
another
module?
You
could
you
could
cast
your
module
as
the
other
module
and
just
call
its
function,
because
every
module
is
this
the
system?
A
But
the
problem
with
this
is
that
message
sender
would
be
lost,
because
it's
it's
a
call.
You
you
break
the
delegate
call
chain
right,
so
you
need
to
delay,
call
to
the
other
module
just
the
the
same,
like
self-casting
mechanism,
but
with
delay
code.
It
works,
but
there's
something
much
better,
which
is
mixins,
which
are
pieces
of
code
that
know
how
to
interact
with
another
module
storage.
They're
like
delegates
for
that
particular
part
of
the
logic
right
and
they're
not
deployed
they're
just
inherited.
A
And
the
nice
thing
is
that
you
can
tell
the
mix
in
to
interact
with
the
other
module
without
even
making
a
call,
so
communication
becomes
super
cheap.
Let's,
let's
see
an
example,
we
have
owner
storage,
which
just
declares
a
struct
with
what
single
variable
that
mechanism
to
to
get
custom
storage
slots.
A
Then
we
have
the
owner
mixing,
which
knows
that
storage
and
only
has,
and
only
only
owner,
modifier
right
that
does
the
typical
check
right
and
then
in
owner
module.
We
inherit
the
mixing,
which
gives
us
the
only
owner,
modifier
access
right,
and
we
have
a
getter
for
the
owner,
and
now
we
have
a
new
version
of
value,
holder,
B5
right.
A
If
you
want
to
use
this,
you
only
have
to
change
your
code
style
a
little
bit,
it's
kind
of
weird,
but
you
get
used
to
it
fast
because
it's
simple,
you
just
need
to
use
storage
name
spaces
instead,
instead
of
like
regular
variables
and
yeah
you
get
used
to,
it
should
Solitaire
do
this
under
the
hood.
There's
a
proposal
from
maxim4,
so
it
is
something
that
the
solidity
team
is
considering.
This
could
be
a
language
supported
feature
to
have
like
a
contract
hub
and
yeah.
Why
use
the
router?
A
A
It's
ideal
for
complex
experimental
systems
and
the
other
nice
thing
is
that
the
router
is,
since
the
addresses
are
hard
coded.
It's
very
explicit.
So
it's
good
for
for
governance.
If
you
want
to
make
an
update
to
the
system,
you
show
your
community
like
this
is
what
we're
going
to
change.
This
is
what
the
configuration
of
the
system
will
look
like:
it's
not
hidden
in
some
Dynamic
storage
somewhere,
it's
right
there
and
yeah.
A
B
A
Basically,
okay,
it's
it's!
Some
people
are
calling
the
diamond
proxy
a
dynamic
router,
and
this
one
is
static.
Router,
and
we
like
this
one
because
for
our
project,
because
it
it
saves
storage,
reads
because
the
the
values
are
hard-coded
and
it's
also
more
explicit
like
that.
What
we
don't
like
about
diamonds
is
that
you
don't
like
if
you're
a
Community
member
or
whatever,
and
you
want
to
know,
what's
the
current
composition
of
the
system,
you
need
to
query
it
a
lot
right,
but
yeah,
it's
the
same.
Otherwise,
just.
C
A
Well,
if,
if
you
declare
your
array
or
any
Dynamic
type
inside
of
those
storage
namespace
drugs,
then
solidity
is
like
regular
storage.
Layouts
system
is
used,
which
uses
unstructured
storage
under
the
hood
like.
If
you
have
a
dynamic
array,
the
position
of
that
array
I
think
it's
going
to
be.
It's
slot
say
if
it's
9003,
because
it's
the
third
variable
instruct
the
hash
of
that.
So
it's
going
to
be
some
other
random
place,
so
it
probabilistically
the
even
though
they're
in
in
struts.
D
D
A
All
sort
of
tools-
okay,
yeah,
so
if
you're
using
open
settlements
proxies,
you
should
use
their
tooling
if
you're
using
the
router.
As
you
can
see,
we
just
we
didn't
just
offer
like
a
solution
to
generate
the
code,
but
we
have.
We
have
a
it
checks,
your
the
storage
layout
of
your
entire
project.
So
in
that
case
you
can
use
our
code
right,
so
I
would
say
always
use
the
tooling
of
whoever
is
providing
you.
The
code,
the
smart
contract
code
of
the
proxy.
A
I,
don't
think,
there's
a
need
to
the
way
solidity
like
these
structures,
arrays
and
mappings,
and
all
that
it's
it's
theoretically
impossible
to
to
get
a
collision.
So
there's
no
need
to
sandbox
it.
The
problem
with
collisions
is
when
people
use
like
a
design-
that's
not
supported
at
a
language
or
at
a
protocol
layer
like
the
evm
right
and
they
get
collisions
between
two
contracts
right.
C
A
You
just
need
to
probably
choose
new
namespaces
and
populate
the
data
right
or
accept
that
your
modules
are
going
to
use
existing
search
right
and
make
sure
that
new
modules
declare
like
a
new
namespace
or
something
but
yeah
sure
you
can
do
it
even
if
so,
if,
if
solidity
like
makes
this
a
language
feature,
you
just
stop
using
generate
routers
and
deploy
a
solution
Hub
right.
So
it's
completely
future
proof.
I.
Think.
F
How
standardized
it
is,
is
proxy,
are
you?
Are
you
the
only
ones
using
it
or
is
someone
else
using
it
in
production
doesn't
mean
first
question
and
the
second
question
is:
do
you
think
it
will
be
useful
to
have
something
in
the
like
a
public
function
in
the
in
the
proxy
to
share
the
signatures
that
are
being
used?
So,
let's
say
a
user
or
someone
that
wants
to
check
what
is
being
used,
doesn't
have
to
dive
into
the
source
code.
A
Yeah
so
standards
not
many
right
now,
if
you
deploy
this,
you
won't
see
anything
on
etherscan.
For
example,
etherscan
doesn't
know
how
to
interpret
a
proxy
that
has
multiple
implementations,
which
is
unfortunate,
but
we're
trying
to
solve
that
pretty
fast.
It
shouldn't
be
hard
and
your
second
question,
you
would
just
add
a
module
that
adopts
a
ERC
165.
Is
it
that
just
like
replies
it?
It
has
that
function?
I,
don't
remember
the
name
of
the
function
that
gives
you
the
entire
interface
of
the
whole
system.
Okay,
that's
it!
Thank
you
very
much.