►
Description
Topics covered
-----------------------------
00:32 - EIP intro
01:05 - Guests introduction
03:00 - EIP-3860
03:36 - Abstract
04:42 - Code vs Initcode
06:15 - Let’s bound init code
08:10 - Let’s pay for JUMPDEST analysis
09:13 - Why not pay for contract code length
10:33 - Why this cost?
12:43 - What is JUMPDEST analysis?
16:28 - Valid usage above limit
20:30 - Questions
20:56 - Security consideration - Failure mode of L2 projects?
25:28 - gas limit and increased attack cost
29:16 - Motivation - Value of adding history in motivation section
32:15 - “What do you think about non-charging 32k or gas when the returned deployment code is empty?”
37:00 - Actual length 2x of code size
Resources:
-----------------
Slides - https://notes.ethereum.org/@ipsilon/peepaneip-3860
EIP - https://eips.ethereum.org/EIPS/eip-3860
Discussion to - https://ethereum-magicians.org/t/eip-3860-limit-and-meter-initcode/7018
Follow at Twitter
-----------------------------------------------
Alex Beregszaszi @alexberegszaszi | Hugo De la cruz @hugo_dc | Paweł Bylica @chfast | Pooja Ranjan @poojaranjan19
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Shanghai playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxpok0smGmq-dFGVHQzW84a2
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
Website: https://www.ethereumcatherders.com/
A
B
B
C
Hi
my
name
is
pavel.
I
started
working
on
evm
very
early
back
in
2014
and
since
then
the
journey
mostly
follows
what
what
alex
explained.
So
I
was
working
on
evm
in
early
days,
then
we
had
a
period
of
webmaster
web
assembly
excitement
and
we
are
back
to
evm
right
now
so
yeah.
My
work
is
mostly
maintaining
c
plus
implementation
of
evm
and
proposing
and
reviewing
other
proposals
for
improvements.
A
C
C
So
the
the
proposal
like
if
we
start
with
the
describing
the
specification
it's
it
adds
two
two
features
to
init
code.
One
is
that
it
cannot
exceed
some
specific
limit
in
length,
so
we
don't
want
to
in
its
code
to
be
unbounded
and
we
put
some
specific
limit
on
on
the
size
of
it,
and
I
will
try
to
explain
why
exactly
this
number
is
is
shown.
C
So
maybe,
like
quick,
quick,
technical,
explain,
explainer
what
is
the
code
and
what
is
the
init
code
in
this
context?
So
when
usually
people
refer
to
code
in
in
ethereum
context,
they
they
rather
mean
that
the
contract
code-
and
this
is
also
how
it's
as
it's
mostly
named
in
technical
documents
about
ethereum.
C
So
this
is
the
code
that
is
actually
stored
in
the
ethereum
state,
and
this
is
the
the
contracts
code
that
is
being
executed
by
transactions.
But
there's
there's
some
kind
of
a
different
kind
of
code,
which
we
call
init
code,
which
works
as
a
constructor
to
to
contract
creation.
So,
like
solidity
refers
that
to
the
constructor,
I
think
the
constructor
is
not
like
technically
very
much
used
in
the
the
ethereum
technical
documents.
C
C
And
like,
as
I
mentioned,
we
want
first,
you
want
to
to
actually
limit
the
the
maximum
size
of
the
of
the
unit
code,
the
maximum
length
of
it,
so
the
the
code,
the
the
codes
contract
code.
What
I
what
I
mentioned
is
it's
already
bounded
to
some
number,
and
that
was
introduced
very
very
early
in
the
in
the
the
the
history
of
eips.
C
C
C
C
The
thing
called
jump,
this
analysis,
which
tries
to
find
the
valids
targets
for
for
jumps
in
the
code
and
because
the
init
code
is
ephemeral,
and
so
this
this
cost.
The
cost
of
analysis,
is
proportional
to
the
to
the
length.
But
is
this
nowhere
ex
directly
expressed
in
this
way?
So
there's
no
cost
currently
for
for
the
for
the
length
of
it
and
that's
creates
some
technical
challenges
for
the
implementation.
At
least.
C
C
C
C
C
So
when
we
consider
jumps
the
validity,
the
validity
of
of
a
jump
target
is
is
prescribed
that
the
the
jump
like
the
target
of
the
job
must
be
a
special
special
op
code
called
jump
desk.
So
whenever
you
actually
have
some
control
flow
in
your
in
your
in
your
code
in
evm,
you
cannot
like
jump
to
any
like
any
instruction.
It
must
be
precisely
the
jumpless
one
which
is
encoded
as
5b
in
hex.
C
So
that's
kind
of
easy
to
check
if
the
the
the
byte
you're
jumping
to
is
is
actually
this
one,
but
there's
like
complication
to
it
and
is
the
fact
that
some
of
the
instructions
and
currently
all
the
push
instructions,
actually
have
these
immediate
bytes
following
the
the
up
the
op
code.
In
this
examples,
I
put
like
push
5.
C
C
So
in
this
example,
if
the
5b
up
byte
is
in
the
dataset
the
data,
let's
say
section,
we
don't
want
to
consider
that
so
mostly
the
jump
test.
Analysis
need
to
scan
the
code
and
to
collect
all
possible
jump
test
positions,
and
to
do
that,
you
also
have
to
inspect
the
push
the
push
instructions
in
the
code.
C
There
is
no
easy
way
to
like
not
doing
it
from
the
beginning
to
the
end,
when
you
would
be
like
on
any
position,
you
can't
figure
out
what's
going
on
around
you
unless
you
start
from
the
beginning,
so
that's
some
kind
of
challenges,
and
so
this,
like
cost
of
doing
that,
it's
proportional
to
the
size
of
the
code.
That's
why
we
want
to
kind
of
express
that
in
the
the
gas
cost
model,
and
we
want
to
also
charge
proportional
cost
of
unit
code
analysis.
C
C
But
if
someone
is
curious,
I
will
try
to
explain
that
at
the
very
end,
if
if
we
have
time
for
it,
okay
and
yeah,
so
that's
mostly
was
the
the
the
description
of
the
of
the
ap
and
a
bit
about
jump,
dumplings,
analysis
and
and
finally,
that's
what
we.
What
we
discuss
internally
and
try
to
actually
collect
some
information
from
the
outside
is
is
about
about
the
the
init
code
length
limit.
So
we
put
two
two
times
the
the
codes
the
code
length
limit.
C
So
so
I
think
one
of
the
property
we
have
to
include
is
that
the
init
code
limit
must
be
bigger
than
by
the
by
the
code
limit
and
they
they
are
kind
of
tangled
and
probably
if
we
want
to
go
to
increase
the
the
code
limit.
We
also
need
to
increase
the
the
init
code
limit
and
in
the
specification
we
actually
use
the
constant
together.
So
it's
expressed
as
a
two
times,
the
other
constant
for
whatever
it
matters
yeah.
C
C
C
I
don't
think
you
can
actually
see
the
whole
hash
of
the
transactions,
but
I
we
found
like
one
a
transaction
that
actually
deploys
11
contracts
in
one
transaction
and
the
yeah
and
they
used
40
over
25
million
gas
to
do
that
and
the
total
initial
transaction
is
actually
like
two
two
times
bigger
than
the
the
limit
we
put
in.
So
that's
like
kind
of
like
tiny
question
we
have
like.
Maybe
we
should
reconsider.
C
C
A
A
Well,
I
have
a
few
questions
related
to
this
proposal.
The
first
one
is
about
the
security
consideration
out
of
those
three
points
which
I
can
follow.
The
one
of
those
are.
This
proposal
talk
about
introducing
a
failure
mode
for
layer,
2
projects
and
it
further
states
that
the
authors
of
this
proposal
are
not
aware
of
any
such
contract.
A
C
So
I
I
don't
think
that's
that's
really
affects
l2,
although
my
my
knowledge
about
how
to
require
requirements
are
not
like,
probably
fully
so
what
what
l2
are
currently
like
kind
of
struggling
with
is
the
transaction
data.
I
mean
they
use
transaction
data
to
actually
store
l2
data
on
on
l1,
and
this
data
is
not
supposed
to
be
executed
to
my
understanding.
C
So
I
think
the
difference
here
is
that
this
limit
doesn't
apply
to
this
use
case,
so
you
can
still
have
transaction
data.
That
is
long
as
you
as
you
want
to
pay
for,
and
this
is
fine.
So
what
this
this
limit
affects
is
the
transactions
that
are
explicitly
created.
Contracts
on
l1,
which
I
don't
think
is
the
case
for
l2
anyway.
B
B
So
there's
a
distinction
between
call
data
versus
just
gen,
generally
called
data
versus
the
specific
contract
creation
transaction,
which
is
a
very
specific
kind
of
transaction,
and
we
only
introduced
this
charge
to
the
contract
creation
transactions
and
not
generally
to
call
data
but
call
data
itself
already.
Has
a
gas
cost.
A
A
Right
because
I
was
wondering
like
when
we
were
deploying
1559,
there
were
a
lot
of
surveys
and
even
for
43.99,
when
it
was
brought
up
like
there
are,
there
may
be
some
project
there.
Contract
may
break
because
of
that.
So
generally,
this
kind
of
survey
helps
and
shanghai
is
a
little
far
from
now.
But
given
the
time
we
have,
I
was
wondering,
like
this
might
be
useful.
A
All
right,
my
next
question
related
to
security.
Consideration
is
about
the
gas
limit
and
the
increased
attack
cost.
So
it's
mentioned
in
the
proposal
like
currently
on
london
with
30
million
gas
limit.
It
would
be
possible
to
trigger
jump
test
analysis
of
a
total
of
1.3
gb
of
in
it.
With
this
proposal,
the
cost
for
such
an
attack
would
increase
by
roughly
80
million
gas.
C
Yeah,
so
going
a
bit
back
to
like
the
the
one
one
question
before,
so
we
actually
like
from
from
the
like
client
implementation,
implementer's
point
of
view.
We
actually
see
it's
like,
I
think,
a
lot
of
support
for
this
change,
mostly
because
of
the
security
risk
and
the
the
the
proposal
mentions
this.
This
kind
of
attack
when
you
can
like
construct
a
transaction
that
mostly
tries
to
produce
us
as
much
in
its
code
as
possible
and
yeah.
C
That's
like
this
like
serious
concern
currently
so
the
way
to
kind
of
mitigate
it
at
the
existing
maintenance
is
to
like
really
carefully
optimize
the
jump.
This
analysis
so
make
sure
like
it's
fast
as
fast
as
possible,
and
there
are
even
some
trade-offs.
You
have
to
make,
for
example,
to
what
makes
the
jump
instructions
slightly
slightly
slower
because
of
that.
C
A
Right
right,
the
last
one
that
occurred
in
november
2021
it
sorry
december
2021.
It
was
only
for
pushing
the
difficulty
bomb
and
most
of
the
feature
proposals
are
for
this
upgrade
the
shanghai
upgrade
yeah.
Well,
that's
yeah!
That's
a
good
thing
that
this
is
finally
in
the
cfi,
so
we
are
hoping
to
see
this
proposal
down
soon
and
will
be
helpful
for
the
network.
A
C
How
to
explain
that
to
my
understanding,
so
this
this
is
kind
of
like,
in
the
same
time
like
known
known
issue
of
evm,
but
in
the
same
time
not
everyone
were
like
fully
aware
of
the
of
the
situation
so
kind
of.
In
the
same
time,
when
the
proposal
was
was
being
drafted,
there
was
there
was
there
was
the
benchmark
of
this
jump.
A
All
right,
there
is
one
final
question
and
it
is
related
to
the
discussion
tool
link.
The
proposal
suggests
applying
an
extra
gas
cost
off
two
for
every
32
by
chunk
of
init
code.
There
is
this
question
by
a
user
at
discussion
to
link,
and
it
suggests
that
what
do
you
think
about
non-charging,
32k
or
gas
when
the
returned
deployment
code
is
empty?
C
C
Yeah
so
like,
in
other
words,
to
allow
any
code
to
be
executed.
You
need
to
kind
of
charge
charge
this
this
jump,
this
analysis
cost
and
unfortunately,
init
code
is
like
very
sensitive
to
that.
The
other
code
is
kind
of
less
because
there's
a
way
to
implement
it
in
a
proper
way
that
it
doesn't
really
matter,
but
in
here
yeah.
That's
that's
the
problem.
C
We
actually
want
to
solve
with
this
one
and
yeah-
and
I
understand
now
like
I
think
this
like
valid
use
case,
and
that
was
discussed
some
time
ago
in
some
other
places
that
to
have
some
kind
of
mechanism
in
in
like
in
evm
in
general.
That
would
allow
you
to
de-execute
a
thermal
evm
code
to
do
some
things.
A
Well,
that's
a
good
thing
like
the
proposal
is
in
review
status
and
if
there
is
any
kind
of
discussion
needed,
people
are
free
to
share
their
thoughts,
but
it
seems
like
this
particular
question
is
not
directly
related
to
the
proposal.
So
as
execu
executive
saying,
maybe
this
is
a
discussion
but
for
a
different
place.
Maybe
thank
you
so
much
for
your
answer.
B
I
actually
do
I
wanted
to
expand
a
tiny
bit
on
on
the
actual
length
you
know,
which
is
not
proposed
as
being
a
2x
of
the
the
code
size
and,
as
final
explained,
the
reason
behind
it
is.
If,
if
you're
deploying
code,
you
inherently
need
more
bytes
in
the
net
code
than
what
the
the
maximum
code
limit
is.
However,
this
code
limit
number
seems
to
be
a
tiny
bit
arbitrary.
B
One
benefit
it
gives
it
can
simplify
some
of
the
evm
implementations
and
to
only
deal
with
like
a
16-bit
offset
and
another
benefit
is
that
a
proposal
like
the
evm
object
format
can
also
be
clearly
articulated
with
16-bit
offsets,
and
I
think
that's
and
that
proposal
is
also
in
cfi.
So
I
think
we
would
be.
You
know
rather
interested
to
keep
the
limit
within
16
bits,
but
it
doesn't
have
to
be
this
40
49k.
B
It
could
be
something
like
65k,
but
it
has
to
be
bigger
than
the
net
code
limit
and
the
the
main
benefit.
If
we
specify
it
as
2x
is
that
if,
in
the
future
the
code
size
limit
would
be
increased
and
then
this
limit
would
the
net
code
size
limit
would
follow
it
if
we
specify
it
independently
of
it,
then
there's
a
risk
that
maybe,
in
the
future
the
code
size
limit
is
increased,
but
the
net
code
size
limit
is
missed
and,
and
you
know,
then
you
don't
really
get
the
benefit
of
the
code.
B
Size
limit
increase-
and
another
point
I
wanted
to
just
briefly
mention-
is
which
isn't
the
motivation
that
if
we,
if
we
introduce
this
charging
per
init
code
chunks,
then
this
this
cost
system
is
useful
for
other
eips
as
well.
Solu
proposals,
which
which
do
some
kind
of
analysis
at
deploy
time,
would
need
to
have
some
kind
of
a
a
gas
system
in
place
for
those.
B
For
that
analysis
and
again,
a
good
example
is
the
the
edm
object
format,
which
does
a
tiny
bit
of
analysis
at
deploy
time,
and
this
cost
would
be
likely
covering
that
as
well.
But
there
are
other
proposals
like
eip-3779,
which
tries
to
analyze
the
control
flow
of
the
code
and
should
something
like
that
be
implemented.
B
You
would
also
want
to
to
charge
for
the
the
analysis
cost
of
it.
So
once
we
have
this
in
its
code
size
metering
proposal
in
place,
it
is
an
extendable
proposal.
You
can
increase
the
per
chunk
gas
cost
with
a
single
change
of
a
constant.
You
don't
need
to
change
all
the
clients
at
all,
so
it
is.
It
is
a
future-proofing
proposal
as
well.
A
That's
nice,
I
I
think
the
eof
proposal
that
is
35.40
and
a
version
of
it
3541,
is
already
deployed
with
a
london
upgrades,
so
we
hope
to
see
this
proposal
being
discussed
in
this
show,
sometimes
in
near
future
and
yeah.
Thank
you
so
much
for
sharing
all
this
information
to
be
honest
like
while
going
through
the
motivation
section
it
felt
to
me,
like
the
motivation,
is
added
for
client
teams
to
consider
this
proposal
and
somewhere
I
found
it
like.
A
A
So
if
they
have
any
charts,
so
they
can
share
it,
they
can
share
their
concerns
in
the
discussion
tool
link
and
when
we
are
ready
with
the
proposal.
The
proposal
can
be
moved
to
the
last
call
it's
time
to
wrap
up
so
on
behalf
of
the
ethereum
cathodes.
I
thank
all
of
you,
the
guest
and
the
participants
for
joining
this
call
and
discuss
eip3860.
A
Should
you
have
any
question
on
this
or
any
other
talk?
Let
us
know
in
the
comment
section
and
share
it
with
us
on
the
ethereum
cat
herders
discard
channel.
Thank
you.
Everyone
for
joining
us
today
see
you
next
week
with
another
interesting
proposal.
Another
guest
to
talk
about
something
that
is
coming
up
with
ethereum
blockchain
have
a
good
one.
Everyone
thank
you.