►
Description
Topics covered
-----------------------------
1:03 - Introduction of co-authors
2:53 - EVM Object Format v1 (EIP-3540)
3:54 - Introduction of the EIP
5:10 - Main Motivation of the EIP
9:45 - EOF isn't the EIP but is it related to this?
11:11 - Is the EIP an incremental step for the long-term vision?
12:12 -Context- how it started?
16:10 - EOF Prefix (how EOF works?)
17:10 - EOF prefix
18:30 - EOF validation
19:00 - Can you say what it means to be valid?
19:43 - Validation affects contract creation
20:50 - what if invalid byte code is deployed before EOF rules are activated.
24:45 - Two HF required
27:25 - EOF1 code and data separation
27:38 - Does this affect any of the addresses with 0xEF?
28:55 - EOF 1 spec
31:21 - EOF 1 validation rules
37:50 - EOF 1 spec: format summary
38:50 - EVM execution changes - definitions
41:25 - What data usually in the current code and current contract along with size
46:25 - Implementers’ notes
46:40 - Potential future EOF uses
57:50 - Is validation on Etherscan easier with this?
59:20 - With this proposal for London, do we need a separate proposal for the reduction of refund?
1:01:13 - Any redundancy on the mainchain with EIP-3541 in case 3540 could not be deployed?
1:04:38 - EIP-3540 status
1:05:40 - What is the vision with versioning?
1:07:50 - JUMPDEST
1:12:21 - History - before the Ethereum launch story
Resources:
-------------------
Slides - https://notes.ethereum.org/@ipsilon/eof-peepaneip-presentation
EIP-3540 https://eips.ethereum.org/EIPS/eip-3540
EIP-3541 https://eips.ethereum.org/EIPS/eip-3541
Discussion to - https://ethereum-magicians.org/t/evm-object-format-eof/5727/4
London proposals playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxppsQYazgJ3EWWWjY2vNxVp
Survey:
---------------
Ethereum blockchain users and developers research - https://docs.google.com/forms/d/e/1FAIpQLSeugRHv93fizew0zeqXFOOnQIbjbWnVHoThLJR3f3g6gVvXhQ/viewform
Follow at Twitter
-----------------------------------------------
Alex Beregszaszi @alexberegszaszi | Paweł Bylica @chfast | Andrei Maiboroda @gumb00 | James Hancock @JHancock | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
It
can
be
considered
as
a
prep
for
eip3540
update
format,
which
can
be
expected
in
the
following
network
upgrade
to
talk
about
the
duo
proposals
we
are
joined
by
the
co-authors,
alex
pavel
and
andrea,
so
welcome
everyone.
Before
we
dive
into
the
proposal.
May
we
have
a
quick
introduction
of
the
co-authors.
B
Okay,
so
maybe
I'll
I'll
start,
my
name
is
pavel
and
I
I'm
working
on
the
core
ethereum
platform
for
many
years
I
started
before
ethereum
has
had
launched
since
then.
I
mostly
work
on
on
the
evm
and
propose
new
changes,
review
changes
proposed
by
others
and
yeah.
That's
what
I
have
been
doing
for
for
for
long
years.
Yeah.
I
think.
That's!
That's
not
for
me!
Well
andre!
You
want
to
go.
D
Yeah,
I
also
likewise
to
to
to
paralyze
I've
been
around
in
ethereum,
for
for
quite
a
bit
initially
contributed
to
ethereum,
js
and
and
then
solidity
and
to
date,
I'm
still
contributing
to
solidity,
mostly
on
language
design,
but
next
to
it.
I
also
have
been
involved
with
the
eip
process
for
quite
a
bit
and
and
work
with
andre
and
pavel
on
the
e
wasm
epsilon
team,
and
mostly,
we
have
been
concerned
with
reviewing
evm
improvements
or
proposing
our
own
improvements
and
the
object
from
it
is
it's
just
one
of
these.
A
B
B
B
But
what
you
want
to
start
with
is
to
give
some
introduction
and
motivation.
Why
why
we
propose
this?
I
will
show
how
how
familiar
is
to
that
to
maybe
it's
it's
like
known
fact
for
call
developers,
but
I'm
not
sure
how
much
it's
known
for
for
for
a
contract
developers
and
app
developers,
but
current
evm
current
evm
design
evm
can
execute
like
whatever
byte
array
of
of
the
code
it
gets.
So
it
can
be
some
nonsense,
a
set
of
instructions
and
it
doesn't
really
matter.
B
B
So
we
can
get
some
benefits
out
of
that
and
what
is
the
main
motivation
like
why
this
is?
This
is
good
thing.
I
think
the
critical
aspect
of
current
evm
design
is
that
it
has
some
some
positions
in
the
code
that
are
marked
as
a
valid
job
destinations,
and
this
is
like
this.
This
has
some
artificial,
special
op
code
that
marks
this.
This
displaces
and
and
also
some
additional
restrictions
related
to
that,
and
the
problem
is
that
you
need
to
know
which
are
the
valid
job
destinations
before
you
can
actually
start
executing.
B
B
Is
there
are
some
parts
of
the
bytecode
that
I
doesn't
mean
to
be
the
advice
that
stores
some
data
and
evm
can
read
this
data,
but
the
the
the
control
flow
never
never
reaches
these
places,
but
still
we
need
to
analyze
this
these
parts
of
the
code,
even
though
the
they're
not
going
to
be
ever
executed-
and
I
said
evm
currently
vm
implementation
can
live
with
that.
It's
not
it's
not
great,
but
it
starts
hurting
some
other
some
other
things.
B
One
of
the
one
of
them
is
on
chain
on
chain
code,
analysis
or
some,
let's
say:
l2
scaling
solutions,
and
one
of
them
is
this
optimism
and
optimistic
virtual
machine
as
it
was
called
previously
and
it's
it
will
do
the
code
analysis
on
chain
and
it's
it
would
be
nice
if
if
they
can
skip
the
the
data
part
of
the
code
and
this
this
is
also
related
to
some
other
proposals
where
there
were
some
other
marks
in
the
bytecode.
That's
a
separated
code
from
the
data,
but
eof
version.
B
We
can
benefit
from
and
we'll
get
to
that
later,
but
some
of
these
are
functions
and
subroutines
inside
evm,
something
that
has
been
discussed
one
or
two
years
ago,
which
is
code
versioning.
This
is
some
way
of
having
backwatering
compatible
changes
to
evm,
and
this
wasn't
done
because
there
were
some
concerns
about
how
this
should
be
deployed
to
to
the
network
and
also
something
that
was
also
considered.
But
it's
difficult
to
roll
out
in
the
current
vm,
which
are
multibyte
op
codes.
B
B
B
This
is,
I
think
this
is
e,
so
we
limited
the
number
of
features
because,
as
you
may
know,
it's
difficult
to
roll
out
like
big
big
feature
set
as
one
as
one
one
like
change
and
code
and
data
separation.
It's
it's
quite
easy
to
do
this
way
and
I
think
it's
it's
quite
important
for
future
to
have
rather
soon
than
than
later.
F
B
D
I
guess
to
to
give
them.
Maybe
a
bit
of
context
had
this
started
is
one
part
is:
is
the
subroutines
proposal
right,
which
has
been
discussed
at
quite
a
bit
of
length
over
the
past
year
and
during
last
year?
One
of
the
the
bigger
discussion
points
was
how
restricted
or
or
unrestricted
subroutine
should
be,
and
actually
that
entire
discussion
really
centered
around
the
effect
on
the
jump,
dust
analysis.
D
So
basically
the
subroutines
proposal,
the
achilles
heel
of
that
was
the
jump
dust
analysis
impact.
So
that
was
one
of
the
the
reasons
we
started
to
look
into
this,
and
the
second
reason
was
the
I
guess,
the
multiplied
up
codes,
because
that
came
up.
As
a
I
mean
it's
a
recurring
thing.
It
came
up
last
with
the
evm384.
D
Meanwhile,
a
workaround
has
been
identified,
but
if
we
would
have
you
know
a
system
like
uf,
you
wouldn't
even
need
to
work
around
and
the
last
trigger
was
really
the
the
code
and
data
separation,
because
I
mean
there
was
this
other
eip
to
just
propose
the
code
and
data
separation,
and
it
has
been
out
as
an
idea
that
that
particular
way
of
doing
it
has
been
out
as
an
idea
for
I
guess
over
two
years
and
it
has
been
recurring.
But
night
seemed
like
that.
D
It
may
be
considered
and
some
some
people,
some
core
developers
were
not
entirely
happy.
The
way
that
the
ip
would
do,
the
separation
and
and
practically
organically.
This
discussion
led
to
you,
know
into
a
proposal
smart
to
the
eof,
and
maybe
one
more
explain
there
on
this
code
and
data
separation.
D
E
F
D
Yeah,
the
hidden
part,
is
so
the
the
problem.
With
the
the
analysis,
I
mean
it's
just
really
hard
to
analyze.
When
you,
you
really
don't
have
any
kind
of
separation,
because
code
may
or
may
not
be
valid,
and
you
also
have
like
a
limited.
You
know
limited
gas.
You
can
spend
on
this
analysis
on
mainnet,
so
in
in
the
general
case,
this
is
just
practically
impossible
to
to
validate.
D
B
B
B
B
So
the
prefix
will
be
how
how
I
said
it
would
be.
That's
one
thing,
and
then
there
will
be
some
additional
rules
and
restrictions
which
depends
on
the
version,
and
I
will
show
what
what
the
version,
what
rules
do
we
do?
We
do
we
propose
for
the
for
the
uf
version,
one
and
these
rules
are
checked
on
deploy
time,
so
so
yeah
we'll
get
to
that
in
the
moment.
B
So
the
validation
is
done,
but
when,
when,
when
someone
wants
to
create
new
contracts
and
deploy
new
code,
so
so
far
in
the
evm,
this
is
done
by
executing
init
codes.
It's
like
some
a
thermal
code
that
is
supposed
to
actually
generate
the
the
end
result
code,
which
is
going
to
be
deployed
in
the
ethereum
state
and
we'll
add
additional
steps
in
this
process.
B
This
and
result
code
will
also
be
validated
according
to
the
ef
rules,
and
so
before
we
go
to
the
specific
rules
for
uf
version.
One
there's
one
gap.
We
I
want
to
explain
so
so
this
is
like
the
origin
of
this
magic
bytes
that
are
not
specified
yet
and
the
reason
why
there
is
additional
additional
ap
proposed
for
to
be
deployed
very
soon.
So
we
want
to
make
sure
that
there
is,
there
doesn't
exist,
any
any
bytecode
that
has
some
kind
of
valid
eof
prefix
right
now.
B
D
That
would
mean
that
in
the
future
you
would
have
two
kinds
of
two
kinds
of
like
uf
looking
byte
code
and
you
would
not
be
able
to
tell
which
is
valid
and
which
is
not
so
we
we
want
to
to
make
sure
that
once
you
can
deploy
tc
with
bytecode,
it
always
gonna
be
valid
by
code.
That
is
the
the
whole
reason
we
have
to
do
these
different
steps,
I'm
not
sure
james
does
that.
Does
that
help
in
the
explainer.
F
Yeah
so
there's
like
a
the
things
that
are
possible
to
deploy
at
ethereum
are
really
huge
and
then
you're
saying
that
if
it's
within
this
subset
of
rules
now
you
have
sort
of
like
a
smaller
thing.
Like
you
have
you,
you
promise,
I
I
guess
I
was
just
trying
to
understand
the
from
the
general
perspective
of
like
why
having
valid
code,
but
I
think
you're
kind
of
getting
to
that
like
from
someone
who,
who
hasn't
really
heard
about
all
making
sure
like
block,
is
valid,
that
that
durham
kind
of
gets
thrown
around.
D
D
That's
the
the
only
rule
which
exists
today
and
this
analysis
jump
test
analysis
checking
that
every
basically
just
building
up
a
list
where
all
of
these
markers
are.
That
is
the
jump
test
analysis
and
that's
the
only
thing
evms
do
today.
It's
not
really
a
strong
guarantee,
and
if
you
have
strong
guarantees,
then
you
can
change
all
this
logic
and
make
it
cheaper
and
faster
and
quicker
and
remove
some
of
this.
That's
the
call
with
validity.
B
Okay,
so
I
I
will
try
to
explain
how
actually
we
plan
to
deploy
this
so
so
we
will
we'll
have
two
two
hard
forks,
but
by
high
force
I
mean
eip
is
included
on
some
different
yeah
hard
forks
happening
at
different
time
and
in
the
first
hard
fork,
oops.
Not
this
way
in
the
first
hard
book,
the
eip
eip3541
will
is
going
to
be
deployed,
and
this
is
simple
change
and
it's
mo
it's
like
the
only
thing
it
does.
B
It's
for
beats
deploying
code,
starting
with
this
ef
ef
bite
at
the
very
at
the
very
beginning.
This
has
been
improved
for
london
and
it
will
go
in
london
and
that
is
going
to
happen
somewhere
and
somewhere
around
summer
this
year
you
might,
you
may
have
like
better
dates
than
me,
but
yeah.
We
kind
of
we
are
very
satisfied.
We
we
could
get
it
in
after
this
date.
B
B
What
we're
going
to
do
after
the
london
hartford
is
that
we'll
analyze
all
the
bytecodes
that
are
on
the
on
the
chain
and
probably
and
probably
will
also
inspect
all
of
the
testnets
that
are
important
to
us
and
then
because
the
the
search
space
for
these
magic
bytes
following
ef
byte,
has
been
has
been
frozen
by
by
the
by
the
first
hard
fork.
We
can
like
find
some
additional
magic
by
that's
are
not
happening
anywhere
on
the
mainland
and
on
the
test
nets.
We
want
to
keep
running
on.
B
So
this
is
the
way
we'll
pick
some
some
additional
magic
bytes
and
we'll
get
some
multi
byte
like
pre
prefix
or
like
indicating
that
this
is
this
is
eof
code
and
and
we'll
know,
none
of
these
exist
on
the
on
the
in
the
state
at
the
moment,
we'll
specify
it
and
finally,
in
the
hard
work
two
which
will
hopefully
introduce
eof
version,
one
we
just
need
to
to
do
it
yeah.
I
hope
you,
I
don't
confuse
you
a
lot.
Why
buy
this?
If
there's
any
questions
so
far,.
B
F
B
Okay,
so
finally,
the
uf
version
one.
What
is
the
the
version
one
about
so
the
main
feature
is:
is
the
code
and
data
separation,
as
we
mentioned
before,
and
how
it
looks
inside
so
well,
it
will
have
the
f1
will
have
the
of
prefix
with
version
one,
that's
what
we
already
defined
and
discussed
and
and
there
will
be
two
like
parts
of
the
of
the
codes
that
will
follow.
B
B
So
section
headers,
so
in
in
general,
this
is
kind
of
yeah,
it's
something
we
we
that
goes
above
the
code
and
data
separation,
but
we
want
to
be
like
generic
enough.
So
these
these
things
are
not
unlikely
to
change
in
in
the
future,
but
they
are
kind
of
extendable
to
new
new
section
kinds,
and
but
we
can
keep
the
container
format
as
as
specified
in
version
one.
B
Currently,
you
being
used,
and
in
the
first
version
we
will
have
three
three
kinds
of
of
sections:
the
terminator
section,
which
is
kind
of
special
way
of
marking
that
there
are
not
any
more
section,
headers
specified
in
the
container
and
yeah,
and
there
are
two
two
main
well
two
sections
that
can
actually
have
some
payload,
which
one
is
for
the
code
and
one
is
for
data.
Unsurprisingly,.
F
Yeah,
so
the
previous
stuff,
thanks
for
letting
me
interrupt
a
bunch,
but
this
is
a
this-
is
really
fascinating.
The
the
so
the
previous
stuff
is
all
set
in
stone.
Pretty
much
that
you
talked
about
this
stuff
is
the
things
that
are
going
to
be
worked
out,
but
will
be
worked
out
before
the
next
hardcore
before
the
next
thing
you
eip
that
you
implement
this,
is
that
our
correct.
B
Understanding
yeah,
I
would,
I
would
assign
like
two
three
different
levels
to
that.
So
what
is
what
is?
What
is
for
sure
that
we
will
forbid
this
this
code?
We
will
forbid
deploying
code,
starting
with
this
special
byte
ef,
and
this
is
for
london,
so
I
expected
it
to
be.
It
will
be
on
my
net
soon
and
and
in
the
second
level
we
are
committed
to
this
eof
graphics.
It's
simple
enough!
So
and
we
don't
find
anything.
B
We
don't
have
anything,
that's
that's
simpler
than
that
and
and
finally,
how
exactly
your
version,
one
will
look
like
yeah,
it's
very
much
up
to
discussion.
So
I
think
my
understanding
is
like
we'll
try
to
intensify
working
after
the
the
london
is
finished
because,
like
people
are
busy
with
that
as
well,
it's
it's
quite.
I
think
it's
quite
hard
on
deadlines.
The
the
modern
heart
works
so
well.
B
D
I
would
add
that
I
think
the
the
confidence
level
in
what
is
I
mean
explained
here
with
these
sections.
I
think
I
think
we're
pretty
confident
that
there
shouldn't
be
too
many
changes
to
this,
because
this
work
I
mean
this.
This
was
quite
a
few
iterations,
I
would
say,
like
you
know,
over
like
five
five
six
iterations
of
different
designs.
D
I
mean
this
is
pretty
simple
stuff,
but
even
the
simple
stuff
you
can
do
in
so
many
different
ways
and
those
different
iterations
were
discussed
with
some
core
devs
and
the
solidity
team
as
well,
so
it
had
like
a
different
input.
So
I'm
kind
of
I
kind
of
feel
like
that.
There
won't
be
too
many
changes
to
this.
If
the
you
know,
if
this
first
feature
of
code
and
data
separation
and-
and
this
is
good
enough,
then
I
think
the
design
is
is
pretty
good
and
maybe
unlikely
to
significantly
change.
B
I
would
try
to
make
it
short
so
not
to
bore
you
so
much
so
what
we,
what
we
there
was
some
question
about.
What
is
validation
means-
and
these
are
these-
are
actually
the
the
six
eof1
validation
rules,
provided
that
this
this
previous
container
specification
is
known-
and
it's
not
super
critical
to
understand
all
of
these
right
now,
but
these
are
specified
in
in
this
way,
as
you
can
see.
B
So,
for
example,
we
define
that
there
must
be
one
only
one
there
was
must
be
exactly
one
code
section
in
this
container
and
then
maybe
there
may
be
one
data
section,
so
you
can
have
zero
on
one
data
sections
in
in
the
in
the
container
yeah.
Obviously,
you
can
like
try
to
tweak
it
a
bit
if
there's
some,
like
good
good
reasons,
to
do
that,
for
example
like
to
to
allow
only
data
section
if
someone
wants
to
that,
we
didn't
find
good
reasons
to
to
allow
this.
B
B
B
So
I
think
you
can
come
up
with
much
more
complicated
byte
byte
containers,
but
we
tried
to
keep
it
simple.
There
are
some
other
ideas
how
to
design
that
this
is
what
we
currently
have
and
and
lastly,
in
terms
of
spec,
before
we
can
go
through
some
discussions.
So,
as
I
mentioned
like
this
kind
of
the
behavioral
changes
to
the
evm
are
are
two
things
first,
one
is
this:
is
this
validation
step
which
actually
happens
twice
during
a
contact?
B
Creation
and
second
part,
is
some
changes
to
the
avm
execution,
and
for
that
we
we
we
tried.
So
the
confusing
the
confusing
term
is
is
code
which
we,
what
we
realize,
because
code
means
something
that
is
deployed
as
a
part
of
the
account
in
the
in
the
state
tree
and-
and
here
we
we
want
to
like
kind
of
a
bit
redefine
that
so
the
code
is
the
content
of
the
code
section
and
the
the
whole
bytes
of
the.
B
B
It
started
when
the
code
section
starts
and
that's
mostly
like
the
the
two
fundamental
changes
and
the
other
part,
the
kind
of
like
consequences
of
god.
So
yeah
considering
like
we
have
15
minutes
left.
I
think
it's,
it's
not
so
super
critical
to
go
into
more
details
about
that.
There
are
additional
like
specific
rules
specified,
but
it
mostly
clarifies
that
some
of
the
existing
instructions
doesn't
change
the
behavior
or
like
clarifies
how
exactly
it's
supposed
to
behave,
but
mostly
it
means
they
are
not
like.
They
are
not
implementations.
D
D
So,
for
us,
like
data,
is
natural,
like
all
this
discussion,
you
know
because
we
deal
with
this
on
a
daily
basis,
but
yeah.
It
occurred
to
me
that
maybe
yeah
just
explaining
what
what
use
cases
you
know
data
has
and
the
the
first
use
case,
which
is
extremely
common
right,
is
when
you
create
when
you
deploy
a
contract.
D
You
have
this
like
initialization
code,
the
contract
trends
runs,
and
then
it
returns
the
actual
runtime
code
which
will
stay
on
chain,
so
the
actual
contract
code,
so
every
contract
deployed,
has
already
two
parts.
It
has
like
this
initialization
code
and
has
the
the
the
actual
contract
code
as
data
right.
Does
that
make
sense
before
I
go
any
further.
F
D
D
Yeah,
so
the
the
the
the
runtime,
what
we
call
the
runtime
code,
that
is
what
ends
up
on
the
chain
right
and
this
initialization
code
during
contract
deployment
that
that
is
only
run
at
contract
deployment.
It
doesn't
get
get
stored
anywhere
and
this
runtime
code
is
is
considered
data
for
the
initialization
code.
So
what
this
means
at
the
time
you
you
deploy
a
contract.
You
have
this
very
large
chunk
of
data
which
you
need
to
analyze,
and
but
you
need
to
analyze
it
with
it
in
the
current
case,
but
it's
not.
D
So
that's
one
one
giant
piece
which
which
happens
all
the
time
and
the
the
second
case
where
data
happens
is
practically
every
single
solidity.
Byte
code
has
data
because
it
has
at
the
very
end
something
called
metadata,
which
is
practically
a
hash
and
and
like
a
version
byte
of
what
what's
already
compiler
was
used,
and
this
metadata
can
be
used
by
contract
verification
tools
like
sourcify
or
etherscan,
to
verify
the
you
know
when
somebody
supplies
the
divide
code,
verification
so
like
the
sources
for
the
bytecode.
D
This
metadata
can
be
used
to
to
actually
validate
that
the
the
people
submitted
the
correct
sources,
so
this
means
that
every
single
byte
code,
since
probably
like
2017,
has
metadata
at
the
end
and
there's
no
real
separation,
and
all
of
that
is
is
in
the
by
the
current
evm
is
considered
like
as
code
and
it's
it's
it's
not
really
nice.
It's
a
design
and
basically
things
like
optimism
has
to
get
rid
of
the
metadata
because
they
cannot
really
handle
it.
D
D
Has
like
a
factory
contract
and
a
factory
contract
is
basically
a
contract
which
will
create
new
contracts,
and
I
think
gnosis
safe
works
like
this,
that
it
has
the
the
safe
contract
and
when
you
create
a
new
safe,
it
deploys
that's
safe
for
you.
So
there's
definitely
a
lot
of
cases
where,
where
data
is
is,
is
part
of
bytecode
and
and
then
there
are
like
more
other
minor
cases
where
it
makes
sense
to
to
store
some
larger
larger
pieces
as
data,
it
really
depends
on
the
compiler
what
they
decide.
F
D
D
B
One
more
note
is
that
we
have
implementations
in
gaff
and
we
want
like
proof
of
concept
implementations,
so
there
are
links
included
in
this
slide
just
for
reference
and
and
finally
we
can.
We
can
discuss
some
potential
like
future
use
of
erf,
so
something
what
can
could
be
done
in
like
you
have
to,
or
five
or
feather
versions.
So
we
mentioned
some
of
these
during
the
the
presentation.
B
The
list
is
not
like
very,
very
structured
and
very
ordered,
but
what's
what's,
what
alex
almost
almost
touched
is
that
in
the
first
version
we
separate
code
and
data,
but
still
the
jump.
This
analysis
has
to
be
done
on
the
code
section,
so
we
limit
the
the
the
size
of
the
jump,
this
analysis,
but
what
could
be
possible
in
future
changes
is
that
to
actually
encode
some
something
like
jump.
This
table
is
instead
of
trying
to
find
these
places
inside
the
code.
B
Looking
for
some
special
marks,
we
could
encode
that
in
some
other
sections,
so
the
good
part
of
that
is
like,
instead
of
to
scanning
the
the
whole
code
section,
it
could
be
enough
to
just
load
stable
in
some
internal
representation,
and
so
that
makes
the
code
bootstrap
much
more
efficient
than
the
currency
would
have
yeah.
So
so
other
option,
which
I'm
kind
of
interested
in,
is
that
this
is
a
kind
of
additional,
I
think,
unwanted
unwanted,
unwanted.
B
You
know,
property
of
the
current
dvn
is
that
there
is
no
no
clear
point
where
it
terminates,
so
there
are
multiple
conditions
when
the
execution
terminates.
Obviously
there
are
some
like
exceptions
that
can
happen
because
of
the
incorrect
instruction
execution,
but
there
is
no
like
stop
point.
You
can
identify
up
front,
so
your
interpreter
has
more
has
to
check
multiple
conditions
when
it
runs,
and
this
is
much
less
efficient
than
like
the
any
kind
of
proper
virtual
machine
design.
B
D
D
I
mean
that
that
requires
having
the
static
jumps
or,
if
you're
cannot
do
that,
just
have
to
jump
this
table
or
introduce
actual
like
evm
functions
instead
of
subroutines
there
there's
so
many
different
possibilities
which
which
can
be
done,
and
I
think
this
is
something
we
we
want
to
explore
after
uf1
goes
live,
but
it's
well.
It's
really
early
to
to
tell
which
option
is,
is
the
best,
and
I
mean
each
of
these
options
have
been
have
like
different
kind
of
motivations.
D
So
it's
it's
quite
a
bit
of
work
to
to
actually
go
through.
All
of
those
you
know
the
different
options
and
the
motivations
and
and
judge
which
one
is
is,
is
something
which
is
like
nice
from,
like
a
research
point
of
view,
you
know
that,
like
a
pure
slash
research
that
you
want
like
a
nice
evm
versus
practical,
you
know
benefits,
but
I
do
expect
that
there
will
be
at
least
one
kind
of
change
or
improvement
relating
to
to.
I
guess
control
flow
because
it
is
a
recurring
topic.
D
D
I
guess
the
view
was
that
it's
not
easy
to
introduce
multivitam
codes
and
what
multibyte
op
code
means
is
an
instruction
which
is
included
in
more
than
one
byte,
but
there
a
workaround
has
been
identified.
So
if,
if
somebody
really
wants
it,
I
think
it's
possible
to
do
it
now,
but
with
with
eof,
you
wouldn't
need
to
work
around
and
the
worker.
What
the
workaround
means
is
that
you
would
have
an
extra
byte.
D
So
if
you
want
like
a
two
byte
instruction,
you
would
need
to
use
three
bytes,
but
with
uf
you
could
do
it
in
two
bytes
and
while
that
single
one
by
doesn't
seem
like
a
big
thing,
the
evm
byte
code
is
and
current
mainnet
is
limited
to
roughly
25k.
So
it's
it's
quite
restricted.
You
know
size
people
have
to
deal
with
so
even
saving
one
byte.
You
know
if
you,
if
you
need
to
use
that
instruction
like
100
times.
That's
that's
quite
significant.
D
And
then
I
guess
going
into
another
set
of
like
bigger
discussions
which
are
relevant
today
is
how
to
deprecate
features,
and
the
self-destruct
has
been
like
one
of
the.
I
guess
the
the
key
examples
for
deprecating
features,
and
currently
it's
it's
really
hard
to
deprecate
stuff,
because
you
have
to
be
conscious
of
what
you
break
the
deprecation.
D
If
you
would
have
something
like
the
eof,
you
could
very
easily
state
that
say
an
eof2
no
contract
can
have
this
bytecode.
This
instruction,
self-destruct
is
just
one
example,
but
we
have
a
bunch
of
other
instructions
which
are
legacy
and
they're
not
really
used
anymore,
and
I
think
a
lot
of
a
lot
more
of
this
discussion.
D
But
if
at
least
that
kind
of
econ
destruction
design
would
come
back
into
consideration,
it
would
be
made
quite
more
sim
quite
more
simpler
with
the
uf,
because
one
big
issue
with
account
abstraction
with
the
proposal,
is
how
to
determine
you
know
how
much
byte
code
can
be
must
be
run
by
the
miner
before
it
is
paid
and
ensure
that
it
gets
paid.
That
is
the
whole
discussion,
but
a
kind
of
abstraction.
D
D
And
so
it
it,
it
may
bring
back
accounts
abstraction
into
into
consideration,
and
I
guess
lastly,
is
really
just
tooling-
which
I
guess
is
an
added
benefit,
but
it
doesn't
really.
It
doesn't
really
make
any
difference
to
on
chain,
because
these
are
really
just
you
know,
off-chain
use
cases,
but
compilers
and
frameworks
definitely
could
benefit
from
having
you
know
the
separation
or
having
all
these
other
features
to
discuss,
because
right
now,
for
example,
all
these
frameworks
dealing
with
with
solidity
code.
F
D
D
A
All
right,
so
I
have
couple
of
more
questions.
One
is
directly
from
this
slide.
It
may
be
a
very,
very
dumb
question.
Point
number
two
mentioned
here:
easier
replication
of
existing
evm
instructions
such
as
self-destruct.
We
are
already
having
a
proposal
for
reducing
refund
was
that
needed
if
we
are
already
having
this.
D
Yeah,
I
would
say
these:
these
are
kind
of
orthogonal
in
the
sense
that,
yes,
you
can
more
easily
deprecate
such
features,
but
obviously
you
can
only
deprecate
it
for
new
byte
code
old
bytecode.
You
can.
This
won't
really
affect
old,
byte
code,
and
so
this
is
kind
of
like
in.
In
that
sense,
a
you
know
not
a
complete
solution,
but
the
word
is
this:
helps
if
in
the
future,
let's
say
you
have
eof,
and
you
have
this
restriction-
that
only
eof
code
can
be
deployed
legacy
code.
D
Cannot,
then
then
deprecating
features
will
be
easier
because
you
will
have
a
fixed
set
of
contracts
which
could
be
affected
because
right
now,
even
though
you
want
to
say
deprecate
self-destruct,
this
list
of
contracts
which
you
know
exist
on
mainnet,
this
is
unbounded.
There's
people
can
keep
deploying
you
know
such
contracts,
so
at
least,
if
you
have
you
know
like
uf
and
and
we
disallow
deploying
non-eof
contracts,
then
we
reduce
the
the
the
number
of
contracts
we
need
to
investigate
every
single
time.
We
want
to
deprecate
something
or
change
something.
A
Make
sense
I
have
a
couple
of
more
questions.
I
believe
those
are
going
to
be
really
quick
so
with
the
expectation
of
erp
3540,
maybe
in
the
following
upgrade.
What
if,
for
any
reason,
the
this
proposal,
evm
object,
format
proposal
is
not
deployed
on
the
main
net.
Do
we
see
any
redundancy
with
the
former
proposal
3541
on
the
main
chain.
D
I
wonder
if,
if
I
should
answer
but
yeah
andrei
pablo,
you
guys
should
feel
free
to
to
speak
up.
I
think
pablo
mentioned
this
earlier,
so
if,
if
3540
is
not
deployed
in
the
end,
the
the
scheme
of
like
using
this
ef
byte
can
be
utilized
by
by
other
proposals
or
in
the
worst
case,
if
it
turns
out
that
nobody
ever
gonna
need
anything
like
that
that
restriction
of
3541
could
be
lifted.
So
it's
it's
pretty
harmless.
A
B
B
It
was
discussed
and
and
yeah
it
has
been
had
been
designed
before,
but
we
it's
back,
then
we
couldn't
actually
get
it,
get
it
done.
So
the
changes
we
kind
of
find
a
way
to
do
that
with
this,
with
this
pre
prefix
and
so
the
more
the
most
importantly,
it
doesn't
require
to
change
the
the
the
ethereum
state
tree
structure,
which
was
one
of
the
way
of
getting
code
versioning.
A
That
make
a
lot
of
sense.
Thank
you.
So
one
last
question:
it's
about
eip
3540.
Currently
the
status
shows
it
in
draft
like
the
way
we
have
discussed
it
today.
It
looks
like
it's
more
or
less
like
already
set
in
stone.
So
is
it
now
ready
to
be
moved
to
review,
or
do
we
want
to
see
it
for
some
more
time
in
draft.
A
F
B
So
so
yeah,
this
is
oh
right
yeah!
This
is
no.
This
is
kind
of
simple
thing,
so
we
don't
want
to
so
it's
it's
a
similar
story
to
what
we,
what
you
currently
try
to
do
to
find
a
prefix
that
has
not
been
deployed
previously
and
all
this
trickery
with
the
sec
two
hard
forks
and
it's
it's
kind
of
the
same
situation.
So
you
don't
want
when,
when
you
only
have
eof1
specified,
you
don't
want
to
to
someone's
deploy
code.
B
That
starts
with
eof
to
p
prefix
and
any
other
version
so
like
it's
reserved
for
future
use.
So
it's
when
only
erf
one
is
specified.
You
cannot
like
deploy
future
versions
because
simply
they
are
not,
they
are
not
specified
yet,
and
you
cannot.
You
could
not
verify
these,
so
this
is
only
because
of
that
and
if
we
going
to
like
design
uf2,
if,
if
any,
then
we
need,
we
have
to
just
like
decide
like
how
the
the
different
versions
were
were
interact
with
each
other.
B
F
And
then
the
next
question
is
so
the
current
stuff:
that's
validated
is
jump
desks
like
if
you
do
a
jump
you
have
to
land
in
the
dump
destination
thing.
Is
that
something?
And
then
the
new
fools
are
going
to
also
contain?
That,
is
that
something
that
we
inherited
and
then
we're
just
like?
Okay,
we
have
to
deal
with
it
like
a
good
idea
in
general.
B
So
it
translates
that
to
like,
like
machine
codes,
it's
kind
of
like
jit
did
for
for
evm,
and
this
brother
project
was
kind
of
promising
back
then,
and
the
problem
is
that
when
you
can
jump
anywhere
in
the
code,
there
is
no
there's
no
way
to
translate
that
you
would
need
to
kind
of
mark
all
of
the
the
yeah.
I
would
need
to
mark
all
of
the
bytes
in
the
in
the
code
as
a
as
a
valid.
B
B
Considering
the
ethereum
1.0
specification
yeah
what
it
was
done,
and
so
so
why
I'm
saying
it's
not
super
relevant
anymore,
because
actually
I
don't
believe
anymore
that
this,
like
jet
compilation,
is
really
like,
very,
very
useful,
at
least
these
days
so
yeah,
maybe
in
the
future.
Some
would
like
to
spend
a
lot
of
time
on
this,
but
I
think
the
interpreters
are
good
enough,
that
it's
not
critically
needed
but
yeah,
but
don't
not
having
that
enable
some
additional
quirks
in
the
evm,
so
so
so
the
most
the
other.
B
The
other
problem
is
that
you
have
also
some
like
constant
values,
mixed
in
the
bytecode
so
like.
If
you
want
to
like,
add
one
to
something
you
have
this
one
value
somewhere
and
you
could
actually
jump
to
this.
One
and
evm
would
interpret
this
one
as
a
add
instruction,
so
it
kind
of
would
work,
but
it
might
be
nightmare
for
like
analysis,
so
this
is
avoided.
B
B
Yeah,
this
is
something
we
proposed
and
we
joined
kind
of
like
when
evm
was
kind
of
specified.
So
we
were
implementing
this.
This
did
compilation
for
a
for
already
existing
specification
right,
so
the
specifications
was
there
like.
Hero
paper
was
was
already
present
and
we
were
implementing
this
proof
of
concept.
Jit
compilation
based
on
the
yellow
paper.
So
it
was,
it
was
done
so
so
the
codes
the
gas
costs
were
not
assigned
back.
B
Then
there
was
some
like
I
mean
it
was
like
different
costs,
but
they
were
like
based
on
nothing
specifically
and
and
then
it
was
benchmarked
more
carefully,
let's
say
and
and
and
the
code
that
the
gas
cost
changes
also
back
then,
but
the
only
addition
I
think
to
that
was
was
the
jump.
That's
up
good
yeah,
probably
the
biggest
change
in
the
evm.
B
B
B
F
B
B
A
A
A
So
I
think
the
eip
3541
like
this
is
the
fastest
moving
proposal,
as
I
mentioned
once
again,
I
would
like
to
congratulate
for
this
perfect
coordination.
I
hope
the
release
of
this
video
may
help
proposal
3540
to
get
more
feedback
to
move
it
forward,
and
now
that
my
understanding
is
the
authors
are
considering
it
to
put
into
review.
So
we
can
expect
a
lot
more
reviews
on
this
note
for
all
our
youtube
viewers.
Thank
you
so
much
for
watching.
A
I
hope
you
like
the
episode
and
if
you
care
about
these
proposals,
please
do
share
with
people
of
similar
interests.
If
you
have
got
any
feedback
for
pip,
35,
40
or
35
41
leave
a
comment
reach
to
your
cat
hurdles
or
the
co-authors,
or
you
can
also
directly
add
comments
in
the
fellowship
of
the
imagination.
The
discussion
two
discussion
links
all
details
are
provided
in
the
description
box.
Few
announcements,
etienne
cathedrals,
are
conducting
a
user
and
developers
survey.
A
A
Today
there
was
a
release
of
london
blog
post.
It
lists
all
the
proposals
which
are
currently
on
the
third
developer's
test
net,
do
give
it
a
read
and
you
will
get
an
overview
of
what
to
expect
with
the
upgrade
that
is
expected
next
month.
Next
week
we
are
going
to
talk
about
another
proposal
that
is
london,
upgrade
eip1559
with
by
four
panabe,
and
my
kazoo
see
you
all
in
the
next
episode
till
then
keep
watching
keep
sharing
your
love
with
the
imperium
cathodes.
This
is
all
of
us
signing
out.